Re: Package system improvements!?
Just throwing out an idea that is in between what has been suggested.
Less automatic...
Right now you install a tar.gz for source,
(compile...)
and then 2 tar.gz's are installed to bootstrap the package system.
What if there was a 2 pronged approach:
1. put code in (a function that runs before current code that the menu
points to starts running) to make the error message helpful, and to
say
" we looked in /<wherever> for <filenames>
it looks like you do not have the files installed to start the pkg
system,
do these steps to install ....
then give examples with the actual paths expected for installing on
this system.
(that they can download and copy and paste),
and an option to manually change the paths that XEmacs looks in,
for special cases.
2. Optionally, combine in a tar.gz both efs and xemacs-base and enough
of an installer
to search out the paths needed, and perform them, maybe showing
what it found
and allowing the user to change them manually before proceeding.
the idea is to get meaningful error handling, and reporting details
about the failure,
then give directions for their system (with option to change).
---------------------
I was trying to imagine the entirety of the use cases here.
When I searched Google for the error, I find 1-2 cases about 2 years apart
(that somebody had this error and went so far to report it)
going back around 7-8 years.
I don't have empirical data, but the people who get it seem to be:
-nobody in windows
-nobody who does the sumo option
-nobody who installs from .rpm, etc. that include the package system.
-somebody who installs from source.
If those observations are anywhere close (I'm not sure how close they
are) maybe the effort
of working on the FFI and libcurl is more than the solution needs?
Since most users (that we
know of) seem to get it installed someway, maybe the above 1 or 2 steps
might help
people get past this.
I would like the FFI from SXEmacs and libcurl, don't get get me wrong
there, but maybe this would
fit available manpower now?
Just a suggestion. Think about it and please point out the problems you
see.
Steve Mitchell
On 12/6/2011 1:34 AM, Mats Lidell wrote:
>>>>> Stephen J Turnbull<stephen(a)xemacs.org>
writes:
... part two [Include download support in core]
> I've thought about that, and came to the conclusion that it doesn't
> work on most distros, as there's no guarantee that the devel
> packages are installed. It's better to use ftp, wget, and/or curl
> commands for basic download support.
In the use case where user builds from sources yes but not in the use
case where the binary is part of a distro or installer.
[...]
> Note that I don't know how practical it is to use libcurl on
> Windows; [...]
We can, or have to, ship the dll with the installer.
> at least you'd need to deal with Cygwin and non-Cygwin, [...]
In cygwin we would depend on libcurl. For non-cygwin, native!?, I
guess it is the same as with the other libraries like jpeg, tiff
etc. You need to have the library installed. If not there, well there
will be no package support.
> OTOH, as long as we have volunteers producing Windows installers,
> this is pretty much a non-issue for Windows.
Yes. If we don't consider the use case where a user would like to
update the packages without downloading a new installer.
I think it would be nice if the package system worked a lot like how
package systems works in other software like firefox, chrome etc.
Yours
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta