10:24 p.m.
Hi
I admit I rarely have used the package system other than from time to
time download a new Sumo tarball.
Private packages I maintain in the old way, ie downloading in a
private dir, compiling, and then setting the path appropriately. It
leads to huge home directory and I would like to change.
Now I tried to use the package-tools to maintain 3d party products.
X-symbol for example already can be downloaded in package form.
After reading the FAQS the README.packages
and
http://www.xemacs.org/Documentation/beta/html/xemacs_25.html#SEC261
The following questions remain.
1. I want to download a new (let's say even a official) package to a
temporary directory and install/update it from there. So I thought
(pui-add-install-directory "~/tmp") would do the job, in the sense
that pui-list-package would list my all the package contained in
this directory and flag them as uninstall. This was not the case.
2. I want to list 3 party packages via pui-list-packages, which can be in
prefix/xemacs/site-packages
or in
~/.xemacs/xemacs-packages
so I was looking for a variable, like
pui-3-party-global-dir
pui-3-party-local-dir
did not find any, so I played with
pui-add-install-directory
but as I understand this is for setting an additional directory for
Installation. I presume I miss something fundamental. Maybe 3d party
package are not meant to be controlled by pui? If so I consider this
as a severe disadvantage!
3. Version numbers: couldn't the package numbers coincide with the
version numbers of the maintainer? vm now does :), but auctex and
others do not. Yes pressing I will give this information, but
anyhow the convenience would be greater if the numbers coincided.
4. May be that has been asked already, but are there plans to write a
tool, which allows to convert an already compiled package to to the
xemacs package standard?. I am thinking of something equivalent to
ALIEN for tgz2rpm.
Uwe Brauer
12:36 a.m.
On Thu, 16 May 2002, Uwe Brauer said:
3. Version numbers: couldn't the package numbers coincide with
the
version numbers of the maintainer? vm now does :), but auctex and
others do not. Yes pressing I will give this information, but
anyhow the convenience would be greater if the numbers coincided.
This is not always possible. The package number in XEmacs must always be
a valid number: this means that it cannot represent upstream versions
like 4.3.22 or 4.3a or 4.3p6 properly. Worse, since it always has to be
a number, if we ever had to upload a package at a time not synched to an
upstream release, we'd break hard:
upstream xemacs
4.2 4.2
4.3 4.3
4.4 (xemacs package change)
4.4 4.5 (whoops, out of synch)
I hear there's a new package system a-brewing that will allow more
flexibility in version numbers, but I don't know how far along in
development this is.
4. May be that has been asked already, but are there plans to write
a
tool, which allows to convert an already compiled package to to the
xemacs package standard?. I am thinking of something equivalent to
ALIEN for tgz2rpm.
(aside: I'd hope you don't need that for preview-latex :) If it's not
package-standard-compliant after `make install', tell me and I'll fix
it. It's meant to be.)
--
`There are not words enough to describe how fucked up imake is.'
--- Peter da Silva
4:13 a.m.
More on question 1 & 2 later, or maybe somebody else can answer.
While this is not "official" policy, here's my understanding on 3 and
4.
>>>> "Uwe" == Uwe Brauer
<oub(a)ucmail.ucm.es> writes:
Uwe> 3. Version numbers: couldn't the package numbers coincide
Uwe> with the version numbers of the maintainer? vm now does :),
Uwe> but auctex and others do not.
No, they can't _coincide_, in general. VM's author primarily uses
XEmacs, and a working XEmacs is the main priority for him. He
distributes VM as an XEmacs package. However, packages such as
AUC-TeX often need modifications to work with XEmacs. These typically
get coordinated with new versions upstream, but in the meantime XEmacs
distributes something different from the upstream version. And it
often takes a couple of XEmacs releases to get it right.
What should be done is to use an "upstream version + XEmacs release"
system, but this would require rewriting all the PUI tools. An
upgrade path and some degree of backward compatility make this look
kind of annoying to write. Someday....
Uwe> 4. May be that has been asked already, but are there plans to
Uwe> write a tool, which allows to convert an already compiled
Uwe> package to to the xemacs package standard?. I am thinking of
Uwe> something equivalent to ALIEN for tgz2rpm.
No. It's a bad idea to simply install a precompiled package from
somewhere. If the packager is going to take enough care to ensure
that the package is going to work right, it's really no more work to
checkout the package dependencies, write a very simple Makefile, and
build the package as Steve Youngs, the package release engineer, does.
The process could be made a lot easier, but we plan to rearrange the
package hierarchy so that each package has its own subdirectory under
the package hierarchy root with lisp, etc, man, and so on
subsubdirectories, instead of the current layout with lisp and other
subdirectories under the package root, with package-specific
subsubdirectories. That would require rewriting any such tools
completely. So this will have to wait for a while.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
1:15 p.m.
>>>> "Uwe" == Uwe Brauer
<oub(a)ucmail.ucm.es> writes:
Uwe> That goes together with my question 1+2, that is the
Uwe> philosophy is that pui does not support 3rd party packages??.
I'm pretty sure that is _not_ the _philosophy_. But it might be true
in practice. :-( I need to do some research on that (I manage my
local packages essentially by hand, that is, I put them in the main
package tree).
The packages _do_ have to be in XEmacs *-pkg.tar.gz format, of course,
as VM is.
Uwe> Please if you find the time tell me the answer to these
Uwe> questions or point me a url or something. Thanks
Any answers you get here will become the URL we point future
questioners to. ;-)
Hoping somebody will come up with something more, but one of these
days I'll take a closer look at it.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
3:03 p.m.
I hear there's a new package system a-brewing that will allow
more
flexibility in version numbers, but I don't know how far along in
development this is.
ok
> 4. May be that has been asked already, but are there plans to write a
> tool, which allows to convert an already compiled package to to the
> xemacs package standard?. I am thinking of something equivalent to
> ALIEN for tgz2rpm.
(aside: I'd hope you don't need that for preview-latex :) If it's not
package-standard-compliant after `make install', tell me and I'll fix
it. It's meant to be.)
Nope, I thought after all about autex: offical package is still 10.g
(at least some weeks ago). Preview recommends 11.11 (well 10.g also
worked, but I changed to
11.11 just in case)
3:09 p.m.
Stephen J. Turnbull writes:
> Uwe> 4. May be that has been asked already, but are there plans to
> Uwe> write a tool, which allows to convert an already compiled
> Uwe> package to to the xemacs package standard?. I am thinking of
> Uwe> something equivalent to ALIEN for tgz2rpm.
> No. It's a bad idea to simply install a precompiled
package from
> somewhere.
That goes together with my question 1+2, that is the philosophy is
that pui does not support 3rd party packages??.
Please if you find the time tell me the answer to these questions or
point me a url or something. Thanks
> The process could be made a lot easier, but we plan to
rearrange the
> package hierarchy so that each package has its own subdirectory under
> the package hierarchy root with lisp, etc, man, and so on
> subsubdirectories, instead of the current layout with lisp and other
> subdirectories under the package root, with package-specific
> subsubdirectories. That would require rewriting any such tools
> completely. So this will have to wait for a while.
That looks for me the right thing to do. To have all in the same
subdirectory looks somehow freighting to me.
More on question 1 & 2 later, or maybe somebody else can answer.
While this is not "official" policy, here's my understanding on 3 and
4.
No, they can't _coincide_, in general.
ok
7:55 p.m.
On 20 May 2002, Stephen J. Turnbull mused:
>>>>> "Uwe" == Uwe Brauer
<oub(a)ucmail.ucm.es> writes:
Uwe> That goes together with my question 1+2, that is the
Uwe> philosophy is that pui does not support 3rd party packages??.
I'm pretty sure that is _not_ the _philosophy_. But it might be true
in practice. :-( I need to do some research on that
Look at emacs-w3m: it has a nice package installation system. (I copied
much of preview-latex's xemacs package installer from it.)
The w3m people don't create a _pkg.el file or pkginfo file, though:
preview-latex does that as well. (The package version number used is the
date of release, like `2002.0521' --- that should give ample flexibility
for additional updates, unless we want to do more than one release a
day!)
The packages _do_ have to be in XEmacs *-pkg.tar.gz format, of
course,
as VM is.
(I don't know whether preview-latex gets that right. I shall check.
I know `make install' puts the site-lisp in the right place, is all.)
--
`There are not words enough to describe how fucked up imake is.'
--- Peter da Silva
8:48 p.m.
>>>> "nix" == nix
<nix(a)esperi.demon.co.uk> writes:
nix> On 20 May 2002, Stephen J. Turnbull mused:
>>>>>> "Uwe" == Uwe Brauer
<oub(a)ucmail.ucm.es> writes:
>
Uwe> That goes together with my question 1+2, that is the
Uwe> philosophy is that pui does not support 3rd party packages??.
>
> I'm pretty sure that is _not_ the _philosophy_. But it might be true
> in practice. :-( I need to do some research on that
nix> Look at emacs-w3m: it has a nice package installation
nix> system. (I copied much of preview-latex's xemacs package
nix> installer from it.)
nix> The w3m people don't create a _pkg.el file or pkginfo file,
nix> though: preview-latex does that as well. (The package version
nix> number used is the date of release, like `2002.0521' --- that
nix> should give ample flexibility for additional updates, unless
nix> we want to do more than one release a day!)
Two issues:
o When things go wrong, a second release may be required the same day
to get out a good release.
o If we use some date to release mapping I would suggest to base it on
UTC date/time, not localtime, to put Australia and California and
Europe on the same plate.
> The packages _do_ have to be in XEmacs *-pkg.tar.gz format, of
course,
> as VM is.
nix> (I don't know whether preview-latex gets that right. I shall
nix> check.
nix> I know `make install' puts the site-lisp in the right place,
nix> is all.)
nix> --
nix> `There are not words enough to describe how fucked up imake is.'
nix> --- Peter da Silva
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
9:38 p.m.
Now that there seems to be some discussion about the future of the
package system, I'll throw in some ideas. This is not directly related
to the thread [1], so I'm replying to the list only (as well as
xemacs-design).
Versioned requirements could be useful, especially for packages. We do
know that package A needs version x.xx of package B to work properly, so
PUI could handle these for the user, like "If you're installing this,
you will also need to upgrade that." A simple
"greater-than-or-equal-to" dependency would probably be enough, at least
to begin with.
This would be useful for core (XEmacs) versions too, so PUI could tell
"You can install this only if you have XEmacs x.x.xx." or maybe would
not show these packages to the user at all. But this could be difficult
to implement due to different supported generations, eg. 21.1.xx,
21.4.xx and 21.5.xx... IMO, the package system version check would not
be good enough.
Also, the syntax should not break backwards compatibility. Something
like RPM [2] does, like "REQUIRES = my-package >= 1.23, your-package >
2.02 ..." might be good, or whatever make will grok. But this must not
break older XEmacsen, at least for the package installation part. Maybe
it would be possible to sacrifice the ability to _build_ these packages
with older versions?
Another idea; when package A does not _require_ package B, but having B
around would bring in some extra goodies to A's functionality; a
RECOMMENDS feature could help. Again, maybe versioned as said above.
There's already some discussion about this in [3]. Oh, and then a
(versioned?) CONFLICTS relation between packages that don't coexist
nicely...
[1] <http://list-archive.xemacs.org/xemacs-beta/200205/msg00353.html>
[2] <http://www.rpm.org/max-rpm/ch-rpm-depend.html>
[3] <http://list-archive.xemacs.org/xemacs-design/200203/msg00001.html>
Cheers,
--
Ville Skyttä
ville.skytta(a)xemacs.org
9:55 p.m.
>>>> "ville" == Ville Skytt <Ville>
writes:
ville> Another idea; when package A does not _require_ package B, but having B
ville> around would bring in some extra goodies to A's functionality; a
ville> RECOMMENDS feature could help. Again, maybe versioned as said above.
ville> There's already some discussion about this in [3]. Oh, and then a
ville> (versioned?) CONFLICTS relation between packages that don't coexist
ville> nicely...
Up to here sounds good. However, CONFLICTS is tricky. What one would
desire is for CONFLICT to prevent or warn about packages being
required w/o others being unloaded, or some to that effect, since
different peopls could want different sets of packages (or same user,
at different times under different tasks).
best,
-tony
--
A.J. Rossini Rsrch. Asst. Prof. of Biostatistics
U. of Washington Biostatistics rossini(a)u.washington.edu
FHCRC/SCHARP/HIV Vaccine Trials Net rossini(a)scharp.org
-------------- http://software.biostat.washington.edu/ ----------------
FHCRC: M-W: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email
UW: Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX
(my friday location is usually completely unpredictable.)
10:04 p.m.
On Tue, 21 May 2002 23:38:06 +0300, Ville =?ISO-8859-1?Q?Skytt=E4?= said:
Versioned requirements could be useful, especially for packages. We
do
know that package A needs version x.xx of package B to work properly, so
PUI could handle these for the user, like "If you're installing this,
you will also need to upgrade that." A simple
"greater-than-or-equal-to" dependency would probably be enough, at least
to begin with.
Remember to allow for "blocking" releases as well, so you can express things
like:
"If you're installing Frobozz 1.13 or later, you also need Moby-Grape 1.3.4
or later, but *NOT* Moby-Grape 2.0".
/Valdis (who has gotten burnt when Foo 2.0 got installed because it was "later"
than Foo 1.4, but the changed API was Just Not The Same ;)
10:15 p.m.
On Tue, 2002-05-21 at 23:55, A.J. Rossini wrote:
ville> Another idea; when package A does not _require_ package
B, but having B
ville> around would bring in some extra goodies to A's functionality; a
ville> RECOMMENDS feature could help. Again, maybe versioned as said above.
ville> There's already some discussion about this in [3]. Oh, and then a
ville> (versioned?) CONFLICTS relation between packages that don't coexist
ville> nicely...
Up to here sounds good. However, CONFLICTS is tricky. What one would
desire is for CONFLICT to prevent or warn about packages being
required w/o others being unloaded, or some to that effect, since
different peopls could want different sets of packages (or same user,
at different times under different tasks).
Yes, at least CONFLICTS should be handled with care. An example case
would be packages "skk" (the one we have) and "ddskk" [1]. I
don't
really know anything about these except that Red Hat is replacing the
official XEmacs skk package with ddskk in their RPMs. Maybe these two
would really conflict?
[1] <http://openlab.ring.gr.jp/skk/>
--
Ville Skyttä
ville.skytta(a)xemacs.org
10:23 p.m.
On Wed, 2002-05-22 at 00:04, Valdis.Kletnieks(a)vt.edu wrote:
> Versioned requirements could be useful, especially for packages.
We do
> know that package A needs version x.xx of package B to work properly, so
> PUI could handle these for the user, like "If you're installing this,
> you will also need to upgrade that." A simple
> "greater-than-or-equal-to" dependency would probably be enough, at least
> to begin with.
Remember to allow for "blocking" releases as well, so you can express things
like:
"If you're installing Frobozz 1.13 or later, you also need Moby-Grape 1.3.4
or later, but *NOT* Moby-Grape 2.0".
Hmm, something like these in Frobozz 1.13 Makefile:
REQUIRES = Moby-Grape >= 1.3.4, Moby-Grape < 2.0
REQUIRES = 1.3.4 <= Moby-Grape < 2.0
REQUIRES = Moby-Grape >= 1.3.4
CONFLICTS = Moby-Grape >= 2.0
/Valdis (who has gotten burnt when Foo 2.0 got installed because it
was "later"
than Foo 1.4, but the changed API was Just Not The Same ;)
Been there too...
Cheers,
--
Ville Skyttä
ville.skytta(a)xemacs.org
12:15 a.m.
On 21 May 2002, Adrian Aichner stated:
o When things go wrong, a second release may be required the same
day
to get out a good release.
Fixable by a sub-day number, viz
2002.040500 (01, 02, 03...)
I'll make that change to preview-latex now. ;)
o If we use some date to release mapping I would suggest to base it
on
UTC date/time, not localtime, to put Australia and California and
Europe on the same plate.
Of course. (I tend to mean `UTC' when I say `time' or `date' anyway;
count it up to .uk provincialism... ;) )
--
`There are not words enough to describe how fucked up imake is.'
--- Peter da Silva
12:17 a.m.
Maybe we should all move to apt-get...
Alex.
--
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html
1:36 a.m.
>>>> "Alex" == Alex Schroeder
<alex(a)emacswiki.org> writes:
Alex> Maybe we should all move to apt-get...
No Debian Perl please. Even Perl core developers admit that Debian
makes all Perl look bad. :-P
So here's the rub: who's going to create that database (and later keep
it up-to-date)? I don't want that job, thank you. Steve Youngs is
already working flat-out. Remember, a substantial minority, perhaps a
majority, of our packages are orphans without an external maintainer.
How are we going to make sure that packages with version dependencies
can actually fulfill them? (I wanted to try some Debian package the
other day, but it wouldn't install because the dependency was == and
the installed dependency library was too recent. This happens a _lot_
with GTK libraries.)
What do we do about packages like JDE that not only depend on
pre-release versions of other packages, but install them?
Wouldn't this effort be better directed at the 800-pound gorilla of
dependencies, GNU vs XEmacs? And maybe on disciplining Ben Wing and
other people who are creating APIs willy-nilly. And doing APEL right?
Is this really that big a deal? I don't see lots of problems in user
land (c.e.x and xemacs-beta) that really look like dependency issues.
Instead, most of the time people need to upgrade for out-and-out bug
fixes.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
3:14 a.m.
On Wed, 22 May 2002 00:23:56 +0300, Ville =?ISO-8859-1?Q?Skytt=E4?= said:
REQUIRES = Moby-Grape >= 1.3.4, Moby-Grape < 2.0
REQUIRES = 1.3.4 <= Moby-Grape < 2.0
REQUIRES = Moby-Grape >= 1.3.4
CONFLICTS = Moby-Grape >= 2.0
IBM's AIX also has the concept of an 'ifreq' - *IF* another package is
is installed, it must be at level X.Y.Z or later for the current package
to install - but if the package is not installed at all, that's OK too.
Actual 'installp' prereq file I used to package EXHM for AIX:
*prereq fw_tk.rte.bin 8.3.2.0
*prereq fw_metamail.rte 2.7.0.0
*prereq fw_nmh.rte 1.0.4.0
*ifreq fw_img.rte 1.2.3.0
*ifreq fw_netscape_remote.rte 1.2.0.0
*ifreq fw_pgp2.rte 2.6.2.0
*ifreq fw_pgp6.rte 6.5.8.0
*ifreq fw_procmail.rte 3.14.0.0
Meaning that you WILL NOT get it to install unless Tk, metamail, and nhm
are at the specified level (and the tk package then pre-reqs tcl itself),
and if Img, netscape_remote, pgp2, pgp6, or procmail are installed, they
have to be at that level or later.
And they support "group prerequisites" too, which is mind-bogglingly
useful for versioning to fit an operating system release. From 'lsof':
0 {
1 {
*prereq bos.rte v=4 r=3 m=2
*prereq fw_lsof.aix432.rte 4.54.0.0
}
1 {
*prereq bos.rte v=4 r=3 m=3
*prereq fw_lsof.aix433.rte 4.54.0.0
}
1 {
*prereq bos.rte 5.0.0.0
*prereq fw_lsof.aix5.rte 4.54.0.0
}
}
Meaning: to install, more than zero of the sub-groups must be satisfied. The
first subgroup requires more than 1 of (bos.rte at *exactly* 4.3.2 and the
lsof.aix432 binary), and similarly for the other two. The IBM compiler runtime
libs for C++ do an insane amount of this - they'll version on the opsys level,
say stuff like "at least 2 of the following 4 (and 3 of the choices are *ifreq
choices)", etc etc....
Of course, IBM AIX support stole the *ifreq stuff from the old MVS 'SMP4'
(right down to the '*' ;) so this is stuff they've been doing since OS/360
literally 38 years ago now.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
8:06 a.m.
>>>> "nix" == nix
<nix(a)esperi.demon.co.uk> writes:
nix> On 21 May 2002, Adrian Aichner stated:
> o When things go wrong, a second release may be required the same
day
> to get out a good release.
nix> Fixable by a sub-day number, viz
nix> 2002.040500 (01, 02, 03...)
Looks like a date to me, why not make it one?
How about ISO8601 compliant 20020405Z1432 (released at 1432 UTC).
nix> I'll make that change to preview-latex now. ;)
> o If we use some date to release mapping I would suggest to base
it on
> UTC date/time, not localtime, to put Australia and California and
> Europe on the same plate.
nix> Of course. (I tend to mean `UTC' when I say `time' or `date'
anyway;
nix> count it up to .uk provincialism... ;) )
Make sure not to switch to summertime, then! :-)
nix> --
nix> `There are not words enough to describe how fucked up imake is.'
nix> --- Peter da Silva
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
8:16 a.m.
On 22 May 2002, Adrian Aichner mused:
>>>>> "nix" == nix
<nix(a)esperi.demon.co.uk> writes:
nix> 2002.040500 (01, 02, 03...)
Looks like a date to me, why not make it one?
Because it's a version number for the packaging system. :)
How about ISO8601 compliant 20020405Z1432 (released at 1432 UTC).
Because the version numbers must be a number (possibly floating-point),
and that's not a number.
I'm trying to deform the date and time into numeric form; elsewhere,
preview-latex has either a datestamp (for CVS stuff) or a conventional
version number (for releases), like 0.7.2.
(But we can't give the XEmacs package that version because it's not a
number. In fact, any version number that long will tend to fall victim
to rounding anyway, I'd have thought :( )
nix> Of course. (I tend to mean `UTC' when I say
`time' or `date' anyway;
nix> count it up to .uk provincialism... ;) )
Make sure not to switch to summertime, then! :-)
Bah, summertime is for humans :)
--
`There are not words enough to describe how fucked up imake is.'
--- Peter da Silva
1:24 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
So here's the rub: who's going to create that database (and
later
keep it up-to-date)? I don't want that job, thank you.
Is it really so difficult? I'd guess the package maintainers know
which versions are required. So they could put that in the Makefile.
kai
--
Silence is foo!
3:25 p.m.
On Wed, 22 May 2002 14:24:17 +0200, Kai =?iso-8859-15?q?Gro=DFjohann?= said:
Is it really so difficult? I'd guess the package maintainers
know
which versions are required. So they could put that in the Makefile.
The hypothetical maintainer of foo.el may know that foo-1.3 need bar-1.6,
and that foo-1.4 needs bar-1.6.5, but may not know that installing bar-1.7
screws his code up gloriously (usually because he departed after foo-1.3
was released).
And we can't rely on the owner of bar-1.7 to add a "SCREWS(foo < 1.5)"
to
his Makefile either...
/Valdis
4:15 p.m.
(I did not sent this to the list but only to Stephen, sorry)
Stephen J. Turnbull writes:
I'm pretty sure that is _not_ the _philosophy_. But it might be
true
in practice. :-( I need to do some research on that (I manage my
local packages essentially by hand, that is, I put them in the main
package tree).
So did I, but now since I know what the pui is or should be capable
off I am curious.
The packages _do_ have to be in XEmacs *-pkg.tar.gz format, of course,
as VM is.
As is x-symbol for example
Now to another point:
I am using xemacs-21.1.14 (I know I should upgrade) but the Sumo
package from late march: now when calling
(pui-list-packages)
I see:
Latest Installed
Package name Vers. Vers. Description
===============================================================================
- Sun 1.12 ----- Support for Sparcworks.
ada 1.09 1.10 Ada language support.
apel 1.19 1.21 A Portable Emacs Library.
auctex 1.22 1.30 Basic TeX/LaTeX support.
That looks a little odd, but ok I have to downloaded via xemacs the
upgrade of the packages. What is strange that
pui-display-info
display the info of the latest but not of the installed package! So in
this case it tells me auctex version: 9.9p etc (1.22)
but I have 10.g installed (1.30)
if this is not a bug but intended I consider it as a misbehavior.
Uwe Brauer
9:07 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Is this really that big a deal? I don't see lots of problems in
user
land (c.e.x and xemacs-beta) that really look like dependency issues.
Instead, most of the time people need to upgrade for out-and-out bug
fixes.
I agree. And for what it's worth, there are not many users
complaining in g.e.help about a missing package system...
Alex.
--
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html
10:24 p.m.
On Wed, 22 May 2002, Alex Schroeder uttered the following:
I agree. And for what it's worth, there are not many users
complaining in g.e.help about a missing package system...
If GNU Emacs had as many packages as XEmacs, that might change.
(How many people download the sumos rather than the individual
packages? Anyone know?)
--
`There are not words enough to describe how fucked up imake is.'
--- Peter da Silva
11:01 p.m.
On Thu, 2002-05-23 at 00:24, Nix wrote:
> I agree. And for what it's worth, there are not many users
> complaining in g.e.help about a missing package system...
If GNU Emacs had as many packages as XEmacs, that might change.
(How many people download the sumos rather than the individual
packages? Anyone know?)
...and if I've understood correctly, the Sumos shouldn't really exist
(no references available as of now, but I know I've seen some comments
against them somewhere).
I think that a big Sumo tarball gives
users/admins/distro-makers/those-who-don't-use-pui a strong hint like
"These packages have been tested to interoperate well, install this and
don't worry about the dependencies." Well, at least stronger than N
different packages in the same dir, even though the dir is for stable
packages. IMHO, this kind of limits the power of the package system.
I also think that a more comprehensive and more enforced dependency
system could have a positive effect on this; still assuming that Sumos
are not considered a good thing. Versioned dependencies wouldn't hurt
here, I guess...
Cheers,
--
Ville Skyttä
ville.skytta(a)xemacs.org
1:05 a.m.
|--==> "UB" == Uwe Brauer <oub(a)ucmail.ucm.es> writes:
UB> 1. I want to download a new (let's say even a official) package to a
UB> temporary directory and install/update it from there. So I thought
UB> (pui-add-install-directory "~/tmp") would do the job, in the sense
UB> that pui-list-package would list my all the package contained in
UB> this directory and flag them as uninstall. This was not the case.
For that to work you also needed to download the
'package-index.LATEST.pgp' (.gpg if using XEmacs 21.5) as well. And
then you could:
M-x pui-add-install-directory RET ~/tmp/ RET
M-x package-get-update-base RET /path/to/package-index.LATEST.pgp RET
M-x pui-list-packages RET
Iff the packages in ~/tmp/ are listed in 'package-index.LATEST.pgp'
they will show up in 'pui-list-packages'. The central part of the
whole package system is the package-index file. Without that, you've
got nothing.
UB> 2. I want to list 3 party packages via pui-list-packages
[...]
UB> Maybe 3d party package are not meant to be controlled by pui? If
UB> so I consider this as a severe disadvantage!
At present, the XEmacs package system doesn't support 3rd party
packages (those not distributed by us). And I agree with you, it is a
huge disadvantage.
If it's any consolation, implementing support for 3rd party packages
is on my todo list. I'm not sure when I'll get it done, at this point
it is just a few random thoughts floating around the dark recesses of
my mind. :-)
UB> 3. Version numbers: couldn't the package numbers coincide with the
UB> version numbers of the maintainer? vm now does :), but auctex and
UB> others do not. Yes pressing I will give this information, but
UB> anyhow the convenience would be greater if the numbers coincided.
There are two problems with trying to keep the version numbers in
sync...
1) Sometimes we'll make a change to a package that'll force
our version number up before the upstream maintainer
releases a new version.
2) Quite often the upstream version number is incompatible
with our version numbers. Ours are "x.xx" of type float,
and as you could imagine, there are almost as many
variations of a version number/string as there are
packages.
Besides, version numbers are such an arbitrary thing anyway.
UB> 4. May be that has been asked already, but are there plans to write a
UB> tool, which allows to convert an already compiled package to to the
UB> xemacs package standard?. I am thinking of something equivalent to
UB> ALIEN for tgz2rpm.
Not that I'm aware of. I have talked about just such a tool with
someone, but I don't think it ever got past the "wouldn't it be neat
if..." stage.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
3:08 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> On Thu, 2002-05-23 at 00:24, Nix wrote:
[Alec Schroeder, I think]
> > I agree. And for what it's worth, there are not many
users
> > complaining in g.e.help about a missing package system...
Emacs is sufficiently full-featured that they probably don't know what
they're missing. XEmacs users, on the other hand, regularly post "the
package system is really helpful! if only it would ...".
> If GNU Emacs had as many packages as XEmacs, that might change.
> (How many people download the sumos rather than the individual
> packages? Anyone know?)
I think most Unix people download the sumos for initial install; use
pui for upgrades later.
This probably is not true for netinstaller customers, since they can
select packages from the same UI as they select XEmacs binaries. But
I think most of them use PUI not netinstaller for upgrades.
Ville> ...and if I've understood correctly, the Sumos shouldn't
Ville> really exist (no references available as of now, but I know
Ville> I've seen some comments against them somewhere).
True, but possibly not in the sense you mean. The main complaint
against the SUMO is that we don't distribute new releases of XEmacs as
xemacs-21.4.8+sumo-20011219+mule-sumo-20011219.tar.gz.
Ville> I think that a big Sumo tarball gives
Ville> users/admins/distro-makers/those-who-don't-use-pui a strong
Ville> hint like "These packages have been tested to interoperate
Ville> well, install this and don't worry about the dependencies."
Ville> Well, at least stronger than N different packages in the
Ville> same dir, even though the dir is for stable packages.
Ville> IMHO, this kind of limits the power of the package system.
This is possible, but I've seen no evidence (in the form of questions
on xemacs-beta or c.e.x) to indicate that it is true. On the
contrary, Adrian posts (often 3 or 4 times a day) "Update to net-utils
1.43" and people Just Do It, nobody ever asks how. The basic use is
_there_, it does what typical users want it to do: give them Emacs
capabilities they need (or we ask them to install!) without muss or fuss.
The limits to the power of the package system from my point of view
are:
o no help for build from source people -- we should support them better
o the pui internals were architected by Motie watchmakers, no rhyme
or reason but some how they work
o Red Hat (SuSE, et al) hoses us every so often with gratuitous
changes to their FTP clients, and we're stuck with an annoying EFS
bootstrap problem; Mike Sperber's conservatism about updating EFS
doesn't help with this
Ville> I also think that a more comprehensive and more enforced
Ville> dependency system could have a positive effect on this;
Ville> still assuming that Sumos are not considered a good thing.
Ville> Versioned dependencies wouldn't hurt here, I guess...
Actually, I think the only noticable effects of versioned dependencies
would be slightly fewer bug reports to package maintainers, and
massively increased complaints about the package system not doing its
job correctly.
I think it's worth worrying about dependency issues for the future, we
may get to the point where dependencies recurse as much as ten layers
deep as in Debian. But right now we rarely see recursion deeper than
2, and most packages are chock-full of compatibility cruft---it will
take massive effort to increase that depth by moving compatibility and
sub-package functionality to separate packages.
Eg consider Gnus, which has mml, message, the various backends, etc
all split out into nominal subpackages. Does anybody use them? No.
Could we really split them into separate packages? I doubt it.
On the other hand, consider JDE, which is the only substantial user of
eieio and semantic, and thus we distribute whatever version JDE
requires.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
4:23 a.m.
|--==> "UB" == Uwe Brauer <oub(a)ucmail.ucm.es> writes:
UB> pui-display-info
UB> display the info of the latest but not of the installed package! So in
UB> this case it tells me auctex version: 9.9p etc (1.22)
UB> but I have 10.g installed (1.30)
UB> if this is not a bug but intended I consider it as a misbehavior.
Looks like a bug to me. It'll be fixed in 21.5 CVS shortly, and I'll
give Steve T a patch for 21.4 as well.
Interestingly, if you 'pui-toggle-verbosity-redisplay' ('v') to turn
off verbose display, and then do 'pui-display-info' ('i') you get both
installed *and* latest versions.
Thanks very much for finding this, Uwe.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
10:48 a.m.
You should look at the design draft I did back in 1999. It handles
(would handle :-( ) most of what you suggest.
http://list-archive.xemacs.org/xemacs-beta/199907/msg00143.html
One of these days, I'll get with it, really ...
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
5:55 p.m.
>>>> Stephen J Turnbull writes:
This probably is not true for netinstaller customers, since they can
select packages from the same UI as they select XEmacs binaries.
But I think most of them use PUI not netinstaller for upgrades.
I've always used netinstaller -- it's really simple (thanks Andy). If
only the netinstaller downloaded the new versions of itself when they
came out. Perhaps it too should be treated as a package like the
XEmacs binaries. :-)
--
David Masterson David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer Synopsys, Inc.
Software Engineering Sunnyvale, CA
9:37 p.m.
>>>> "david" == David Masterson
<dmaster(a)synopsys.com> writes:
>>>> Stephen J Turnbull writes:
> This probably is not true for netinstaller customers, since they can
> select packages from the same UI as they select XEmacs binaries.
> But I think most of them use PUI not netinstaller for upgrades.
david> I've always used netinstaller -- it's really simple (thanks Andy).
If
david> only the netinstaller downloaded the new versions of itself when they
david> came out. Perhaps it too should be treated as a package like the
david> XEmacs binaries. :-)
The Cygwin installer does this now (updated a system last night),
so...
best,
-tony
--
A.J. Rossini Rsrch. Asst. Prof. of Biostatistics
U. of Washington Biostatistics rossini(a)u.washington.edu
FHCRC/SCHARP/HIV Vaccine Trials Net rossini(a)scharp.org
-------------- http://software.biostat.washington.edu/ ----------------
FHCRC: M-W: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email
UW: Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX
(my friday location is usually completely unpredictable.)
3:33 p.m.
Steve Youngs writes:
|--==> "UB" == Uwe Brauer <oub(a)ucmail.ucm.es>
writes:
UB> 1. I want to download a new (let's say even a official) package to a
UB> temporary directory and install/update it from there. So I thought
UB> (pui-add-install-directory "~/tmp") would do the job, in the sense
UB> that pui-list-package would list my all the package contained in
UB> this directory and flag them as uninstall. This was not the case.
For that to work you also needed to download the
'package-index.LATEST.pgp' (.gpg if using XEmacs 21.5) as well. And
then you could:
Ah this was it. I think this information about downloading the
package-index.LATEST.pgp file in order to make an Installation from a
local directory, should be included in the manual and in the FAQ where
I cannot find it.
UB> 2. I want to list 3 party packages via pui-list-packages
[...]
UB> Maybe 3d party package are not meant to be controlled by pui? If
UB> so I consider this as a severe disadvantage!
At present, the XEmacs package system doesn't support 3rd party
packages (those not distributed by us). And I agree with you, it is a
huge disadvantage.
If it's any consolation, implementing support for 3rd party packages
is on my todo list. I'm not sure when I'll get it done, at this point
it is just a few random thoughts floating around the dark recesses of
my mind. :-)
Would it be helpful to have a hack which just would manage 3rd party
packages in .xemacs or .xemacs/xemacs-packages and then later try to
merge it into the 'main' package tool?
Uwe
4:50 p.m.
Valdis.Kletnieks(a)vt.edu writes:
On Wed, 22 May 2002 14:24:17 +0200, Kai
=?iso-8859-15?q?Gro=DFjohann?= said:
> Is it really so difficult? I'd guess the package maintainers know
> which versions are required. So they could put that in the Makefile.
The hypothetical maintainer of foo.el may know that foo-1.3 need bar-1.6,
and that foo-1.4 needs bar-1.6.5, but may not know that installing bar-1.7
screws his code up gloriously (usually because he departed after foo-1.3
was released).
Well, and then somebody (Alice) sends a bug report. And somebody else
(Bob) finds out about this conflict. Bob tells Alice about it.
In the future, Bob just needs to frob foo's Makefile, too.
Of course, this might not be practical. Instead, some other
maintainer will read the whole exchange and then frob foo's Makefile.
(In the end, foo should be fixed to cope with bar-1.7, anyway.)
kai
--
Silence is foo!
5:21 p.m.
Kai.Grossjohann(a)cs.uni-dortmund.de (Kai writes:
Nix <nix(a)esperi.demon.co.uk> writes:
> (How many people download the sumos rather than the individual
> packages? Anyone know?)
[...gross bogosity elided...]
What I meant is that it happened from time to time that people were
complaining that package X didn't work. It was clear from the error
message that some package was missing. I then mentioned about the
Sumo tarball (which seemed to me an easy way to install the missing
packages without having to do trial and error).
It took a while to explain what Sumo is, but after that I think they
were happy.
The implication is that the Sumo tarball isn't advertised enough, I
think.
kai
--
Silence is foo!
11:29 p.m.
|--==> "n" == nix <nix(a)esperi.demon.co.uk> writes:
n> (How many people download the sumos rather than the individual
n> packages? Anyone know?)
I don't know for sure, but I'd guess that the number is pretty high.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
12:15 a.m.
|--==> "VS" == Ville Skytt <Ville> writes:
VS> ...and if I've understood correctly, the Sumos shouldn't really exist
Even though they are a pain for me [1] I wouldn't ever stop releasing
them. They give new users an easy way to get hold of all of the
packages they are ever likely to need.
Remember too, that most of these type of users aren't familiar with
pui yet.
VS> I think that a big Sumo tarball gives
VS> users/admins/distro-makers/those-who-don't-use-pui a strong hint like
VS> "These packages have been tested to interoperate well, install this and
VS> don't worry about the dependencies."
It is supposed to convey: "...so you want to get a complete set of
packages? Download this monster Sumo tarball..."
VS> IMHO, this kind of limits the power of the package system.
I don't see how. Can you elaborate?
VS> I also think that a more comprehensive and more enforced dependency
VS> system could have a positive effect on this; still assuming that Sumos
VS> are not considered a good thing.
But they (Sumos) are a good thing. And besides, dependency related
problems reported to xemacs-beta or c.e.x are *VERY* rare [2]. I
think we would be better off fixing the package bootstrap problem.
What I'm talking about here is the problem of having to install some
packages manually before you can use the package system.
Footnotes:
[1] Uploading 50+ Mb over a 56K dialup takes a bloody long time.
[2] I don't think I have *ever* seen one.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
2:21 a.m.
|--==> "UB" == Uwe Brauer <oub(a)ucmail.ucm.es> writes:
UB> Steve Youngs writes:
>For that to work you also needed to download the
>'package-index.LATEST.pgp' (.gpg if using XEmacs 21.5) as well. And
>then you could:
UB> Ah this was it. I think this information about downloading the
UB> package-index.LATEST.pgp file in order to make an Installation from a
UB> local directory, should be included in the manual and in the FAQ where
UB> I cannot find it.
Patches to the docs would be greatly appreciated. :-)
UB> Maybe 3d party package are not meant to be controlled by pui? If
UB> so I consider this as a severe disadvantage!
>If it's any consolation, implementing support for 3rd party
packages
>is on my todo list. I'm not sure when I'll get it done, at this point
>it is just a few random thoughts floating around the dark recesses of
>my mind. :-)
UB> Would it be helpful to have a hack which just would manage 3rd party
UB> packages in .xemacs or .xemacs/xemacs-packages and then later try to
UB> merge it into the 'main' package tool?
It could be. But 3rd party packages should go into:
$prefix/lib/xemacs/site-packages/
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
8:52 a.m.
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
SY> But they (Sumos) are a good thing. And besides, dependency
SY> related problems reported to xemacs-beta or c.e.x are *VERY*
SY> rare [2].
Typically they're not recognized as such until they're in the upstream
maintainer's hands. Guess who all the people who are pushing for
better dependencies are. ;-)
SY> [2] I don't think I have *ever* seen one.
Search on JDE+semantic+eieio.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
12:01 p.m.
On Sun, 2002-05-26 at 02:15, Steve Youngs wrote:
VS> I think that a big Sumo tarball gives
VS> users/admins/distro-makers/those-who-don't-use-pui a strong hint like
VS> "These packages have been tested to interoperate well, install this and
VS> don't worry about the dependencies."
It is supposed to convey: "...so you want to get a complete set of
packages? Download this monster Sumo tarball..."
VS> IMHO, this kind of limits the power of the package system.
I don't see how. Can you elaborate?
The "power" was a bad word choice, maybe "usefulness" would have been
better. Anyway, what I am looking after is that XEmacs has a nice
package system, why don't the majority of users (just a guess...) use it
but download sumos instead? It would probably be less work and easier
for everyone if we had (only) One Easy and Working Way to handle
packages.
But they (Sumos) are a good thing. And besides, dependency related
problems reported to xemacs-beta or c.e.x are *VERY* rare [2]. I
think we would be better off fixing the package bootstrap problem.
What I'm talking about here is the problem of having to install some
packages manually before you can use the package system.
Ah, I wasn't even aware of that (hmm, efs?). Agreed, this should be
fixed somehow.
Cheers,
--
Ville Skyttä
ville.skytta(a)xemacs.org
1:43 p.m.
On Sun, 26 May 2002, youngs(a)xemacs.org wrote:
What I'm talking about here is the problem of having to install
some
packages manually before you can use the package system.
The problem as I see it is that you are taking the developers'
distinction of CORE vs PACKAGE and moving that into the users' space.
Create a new idea called a DISTRIBUTION, where it is the CORE plus
the bootstrapping packages.
-Mark
2:28 p.m.
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
SY> |--==> "n" == nix <nix(a)esperi.demon.co.uk> writes:
n> (How many people download the sumos rather than the individual
n> packages? Anyone know?)
SY> I don't know for sure, but I'd guess that the number is pretty high.
Here is actual data suggesting that individual package downloads (via
ftp at least) are more common than sumo downloads via ftp:
http://www.tux.org/wusage/usage_200205.html#TOPURLS
SY> --
SY> |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
SY> | XEmacs - It's not just an editor. |
SY> | It's a way of life. |
SY> |------------------------------------<youngs(a)xemacs.org>---|
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
2:56 p.m.
>>>> "stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
SY> But they (Sumos) are a good thing. And
besides, dependency
SY> related problems reported to xemacs-beta or c.e.x are *VERY*
SY> rare [2].
stephen> Typically they're not recognized as such until they're in the
upstream
stephen> maintainer's hands. Guess who all the people who are pushing for
stephen> better dependencies are. ;-)
SY> [2] I don't think I have *ever* seen one.
stephen> Search on JDE+semantic+eieio.
or other sets of CEDET + external combos....
(it's the only part of my setup that I've given up on both debian and
xemacs packaging schemes and doing it by hand, since ecb + jde are semi
critical for my work).
best,
-tony
--
A.J. Rossini Rsrch. Asst. Prof. of Biostatistics
U. of Washington Biostatistics rossini(a)u.washington.edu
FHCRC/SCHARP/HIV Vaccine Trials Net rossini(a)scharp.org
-------------- http://software.biostat.washington.edu/ ----------------
FHCRC: M-W: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email
UW: Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX
(my friday location is usually completely unpredictable.)
4:20 p.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> Anyway, what I am looking after is that XEmacs has a nice
Ville> package system, why don't the majority of users (just a
Ville> guess...) use it but download sumos instead? It would
Ville> probably be less work and easier for everyone if we had
Ville> (only) One Easy and Working Way to handle packages.
A SUMO is basically an installed tree, tarred up.
The SUMOs and the individual packages have separate purposes. I would
imagine that most Unix users do start by installing a SUMO, but then
use the pui to update.
Ville> Ah, I wasn't even aware of that (hmm, efs?). Agreed, this
Ville> should be fixed somehow.
Yes, but it's not as easy as it looks.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
5:57 p.m.
On Sun, 26 May 2002 15:28:14 +0200, Adrian Aichner <adrian(a)xemacs.org> said:
Here is actual data suggesting that individual package downloads
(via
ftp at least) are more common than sumo downloads via ftp:
http://www.tux.org/wusage/usage_200205.html#TOPURLS
Two other things that stuck out from this data:
1) Of the "Top 20 Usernames", 'xemacs-setup＠' is number 1 with 49,729
hits,
and IEUser＠ is number 2 with 19,624 hits. This smells like most of the hits
being done courtesy of canned code...
2) 'windows/setup.ini' is number 1 in the "top 30 URLS", and
"installshield/README"
is number 3. package-index is in between.
If the windows-installer code downloads packages, it's quite possible that
"initial install by windows" is swamping the data to the point where
"people
who later upgrade via SUMO" and "people who later upgrade via pui" are
both
lost in the noise.
Anybody else surprised that "bbdb" is number 5 on the list and
"mailcrypt" is
number 25, but *NONE* of gnus/mh-e/rmail/vm are in the top 30? I have to wonder
how many things are being sucked down as not-REALLY-prereqs (mailcrypt?? I
doubt that there's THAT many people using PGP - that's almost certainly a
case of something being a "prereq" when it should be a
"recommended"....
/Valdis
10:43 p.m.
SY> I don't know for sure, but I'd guess that the
number is
pretty high.
Here is actual data suggesting that individual package downloads (via
ftp at least) are more common than sumo downloads via ftp:
http://www.tux.org/wusage/usage_200205.html#TOPURLS
I'm almost certain these stats are skewed by the netinstaller which does
individual package downloads. I'm intrigued that setup.ini is top. I guess
this is because it does not change name whereas the tarballs do.
Someone needs to update the installshield dist - it obviously is quite
popular.
andy
3:07 p.m.
Steve Youngs writes:
Footnotes:
[1] Uploading 50+ Mb over a 56K dialup takes a bloody long time.
well, also uploading calc or gnus it's a bloody long time,
especially if the fixes are three lines of code as is usual with
calc...
what i'd _really_ like would be the option of accessing an
_installed_ tree of packages transparently using cvs+emacs
6:09 p.m.
>>>> "giacomo" == giacomo boffi
<giacomo.boffi(a)polimi.it> writes:
giacomo> what i'd _really_ like would be the option of
giacomo> accessing an _installed_ tree of packages transparently
giacomo> using cvs+emacs
Would rsync do?
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
7:26 p.m.
Stephen J. Turnbull writes:
>>>>> "giacomo" == giacomo boffi
<giacomo.boffi(a)polimi.it> writes:
giacomo> what i'd _really_ like would be the option of
giacomo> accessing an _installed_ tree of packages transparently
giacomo> using cvs+emacs
Would rsync do?
as i'm a naive user of cvs, i'd happily be a naive user of rsync...
rsync/cvs difference it's about downloading whole changed files
instead of diffs, isn't it?
and would you (xemacs.org, i mean) set up a rsync server? i hope
so, as it will be a BIG gain for 56k downloaders,,,
ciao
8:12 p.m.
>>>> "giacomo" == giacomo boffi
<giacomo.boffi(a)polimi.it> writes:
giacomo> Stephen J. Turnbull writes:
>> >>>> "giacomo" ==
giacomo boffi <giacomo.boffi(a)polimi.it> writes:
>>
giacomo> what i'd _really_ like would be the option of
giacomo> accessing an _installed_ tree of packages transparently
giacomo> using cvs+emacs
>
> Would rsync do?
giacomo> as i'm a naive user of cvs, i'd happily be a naive user of
rsync...
giacomo> rsync/cvs difference it's about downloading whole changed files
giacomo> instead of diffs, isn't it?
giacomo> and would you (xemacs.org, i mean) set up a rsync server? i hope
giacomo> so, as it will be a BIG gain for 56k downloaders,,,
Hi Giacomo,
you'll be glad to hear that the XEmacs CVS repository is already
available via rsync, even though we have not documented the fact yet.
Try
rsync -auvz --delete sunsite.dk::xemacscvs DESTDIR
I even maintain a mirror on my Windows laptop, which I update every
evening from home, where I have a fast network connection :-)
Caio,
Adrian
giacomo> ciao
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
8:30 p.m.
>>>> "apa" == Adrian Aichner
<adrian(a)xemacs.org> writes:
>>>> "giacomo" == giacomo boffi <giacomo.boffi(a)polimi.it>
writes:
giacomo> Stephen J. Turnbull writes:
>> >>>>> "giacomo" == giacomo boffi
<giacomo.boffi(a)polimi.it> writes:
>>
giacomo> what i'd _really_ like would be the option of
giacomo> accessing an _installed_ tree of packages transparently
giacomo> using cvs+emacs
>>
>> Would rsync do?
giacomo> as i'm a naive user of cvs, i'd happily be a naive user of
rsync...
giacomo> rsync/cvs difference it's about downloading whole changed files
giacomo> instead of diffs, isn't it?
giacomo> and would you (xemacs.org, i mean) set up a rsync server? i hope
giacomo> so, as it will be a BIG gain for 56k downloaders,,,
apa> Hi Giacomo,
apa> you'll be glad to hear that the XEmacs CVS repository is already
apa> available via rsync, even though we have not documented the fact yet.
apa> Try
apa> rsync -auvz --delete sunsite.dk::xemacscvs DESTDIR
apa> I even maintain a mirror on my Windows laptop, which I update every
apa> evening from home, where I have a fast network connection :-)
But this won't help with having packages INSTALLED IN PLACE, will it?
(i.e. I thought you couldn't work right out of a copy of a checkout of
the packages CVS repository, though I'd be really happy to be wrong
:-).
best,
-tony
--
A.J. Rossini Rsrch. Asst. Prof. of Biostatistics
U. of Washington Biostatistics rossini(a)u.washington.edu
FHCRC/SCHARP/HIV Vaccine Trials Net rossini(a)scharp.org
-------------- http://software.biostat.washington.edu/ ----------------
FHCRC: M-W: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email
UW: Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX
(my friday location is usually completely unpredictable.)
8:40 p.m.
>>>> "A" == A J Rossini
<rossini(a)blindglobe.net> writes:
>>>> "apa" == Adrian Aichner
<adrian(a)xemacs.org> writes:
>>>> "giacomo" == giacomo boffi <giacomo.boffi(a)polimi.it>
writes:
giacomo> Stephen J. Turnbull writes:
>>> >>>>> "giacomo" == giacomo boffi
<giacomo.boffi(a)polimi.it> writes:
>>>
giacomo> what i'd _really_ like would be the option of
giacomo> accessing an _installed_ tree of packages transparently
giacomo> using cvs+emacs
>>>
>>> Would rsync do?
giacomo> as i'm a naive user of cvs, i'd happily be a naive user of
rsync...
giacomo> rsync/cvs difference it's about downloading whole changed files
giacomo> instead of diffs, isn't it?
giacomo> and would you (xemacs.org, i mean) set up a rsync server? i hope
giacomo> so, as it will be a BIG gain for 56k downloaders,,,
apa> Hi Giacomo,
apa> you'll be glad to hear that the XEmacs CVS repository is already
apa> available via rsync, even though we have not documented the fact yet.
apa> Try
apa> rsync -auvz --delete sunsite.dk::xemacscvs DESTDIR
apa> I even maintain a mirror on my Windows laptop, which I update every
apa> evening from home, where I have a fast network connection :-)
A> But this won't help with having packages INSTALLED IN PLACE,
A> will it? (i.e. I thought you couldn't work right out of a copy
No. We don't have a installed package hierarchy available by rsync or
other means.
A> of a checkout of the packages CVS repository, though I'd be
A> really happy to be wrong :-).
Sorry to disappoint you, but you're right :-)
A> best,
A> -tony
A> --
A> A.J. Rossini Rsrch. Asst. Prof. of Biostatistics
A> U. of Washington Biostatistics rossini(a)u.washington.edu
A> FHCRC/SCHARP/HIV Vaccine Trials Net rossini(a)scharp.org
A> -------------- http://software.biostat.washington.edu/ ----------------
A> FHCRC: M-W: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email
A> UW: Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX
A> (my friday location is usually completely unpredictable.)
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
8:45 p.m.
Adrian Aichner writes:
Hi Giacomo,
you'll be glad to hear that the XEmacs CVS repository is already
available via rsync, even though we have not documented the fact yet.
thank you, it's good news indeed! (well, not a complete surprise, as
stephen's reply to my 1st post seemed to hint such an occurrence...)
Try
rsync -auvz --delete sunsite.dk::xemacscvs DESTDIR
won't that copy the whole cvs repository? isn't it a bit too much for
a test or am i wrong?
while we're at it, what i'd like to do is keep in sync only [a part
of] the installed packages: do you think it's currently possible or i
have to keep the whole source tree on my disk and to do the package
builds by myself?
well, it's time to go reading rsync(1)
ciao
8:52 p.m.
Adrian Aichner writes:
>>>>> "A" == A J Rossini
<rossini(a)blindglobe.net> writes:
A> But this won't help with having packages INSTALLED IN PLACE,
A> will it? (i.e. I thought you couldn't work right out of a copy
No. We don't have a installed package hierarchy available by rsync or
other means.
ok, this answers what i asked one minute ago...
but what do you think about the option of keeping an installed
package hierarchy on sunsite.dk?
i'd just love to be able to get a few kbytes of mutated files
instead of a some large tar.gz!
11:19 p.m.
Steve Youngs writes:
|--==> "UB" == Uwe Brauer <oub(a)ucmail.ucm.es>
writes:
UB> Steve Youngs writes:
>>For that to work you also needed to download the
>>'package-index.LATEST.pgp' (.gpg if using XEmacs 21.5) as well. And
>>then you could:
UB> Ah this was it. I think this information about downloading the
UB> package-index.LATEST.pgp file in order to make an Installation from a
UB> local directory, should be included in the manual and in the FAQ where
UB> I cannot find it.
Patches to the docs would be greatly appreciated. :-)
OK, but this leads me to a general question: shouldn't docs written by
native English speakers?
UB> Maybe 3d party package are not meant to be controlled by pui? If
UB> so I consider this as a severe disadvantage!
>>If it's any consolation, implementing support for 3rd party packages
>>is on my todo list. I'm not sure when I'll get it done, at this point
>>it is just a few random thoughts floating around the dark recesses of
>>my mind. :-)
UB> Would it be helpful to have a hack which just would manage 3rd party
UB> packages in .xemacs or .xemacs/xemacs-packages and then later try to
UB> merge it into the 'main' package tool?
It could be. But 3rd party packages should go into:
$prefix/lib/xemacs/site-packages/
Ups well, if you have root access. However on your own Linux/BSD
whatsoever PC this is obvious but I guess there are guys out, on say
Solaris workstations. So they can't install there (yes I know they
cannot upgrade the packages neither)
I thought that is what .xemacs is for?
3:59 a.m.
>>>> "Uwe" == Uwe Brauer
<oub(a)ucmail.ucm.es> writes:
Uwe> OK, but this leads me to a general question: shouldn't docs
Uwe> written by native English speakers?
I see no need for that. Basically, if you're willing to write docs
for code you didn't write, then your English is almost surely good
enough. Otherwise it would be too painful for you.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
1:42 p.m.
|--==> "MT" == Mark Thomas <swoon(a)bellatlantic.net> writes:
MT> On Sun, 26 May 2002, youngs(a)xemacs.org wrote:
>What I'm talking about here is the problem of having to
install some
>packages manually before you can use the package system.
MT> The problem as I see it is that you are taking the developers'
MT> distinction of CORE vs PACKAGE and moving that into the users' space.
MT> Create a new idea called a DISTRIBUTION, where it is the CORE plus
MT> the bootstrapping packages.
This is something that we are considering. I'm not sure how far along
things are though.
Steve T: What's the status on this? If you like I can channel some
of my time towards getting something working.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
1:49 p.m.
|--==> "AJR" == A J Rossini <rossini(a)blindglobe.net> writes:
AJR> But this won't help with having packages INSTALLED IN PLACE, will it?
AJR> (i.e. I thought you couldn't work right out of a copy of a checkout of
AJR> the packages CVS repository, though I'd be really happy to be wrong
AJR> :-).
No, you are correct, you can't run packages "in place". But you can
get close (at least on a Unix platform)...
In 'Local.rules' if you set:
symlink = t
XEMACS_STAGING = /usr/local/lib/xemacs/xemacs-packages
MULE_STAGING = /usr/local/lib/xemacs/mule-packages
And then do a 'make install', you'll get a symlinked package tree.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
3:09 p.m.
|--==> "gb" == giacomo boffi <giacomo.boffi(a)polimi.it> writes:
gb> but what do you think about the option of keeping an installed
gb> package hierarchy on sunsite.dk?
And available via rsync... I really like the sound of that. I wonder
how workable it would be, and how hard would it be to set up and
maintain? Definitely food for thought.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
3:21 p.m.
|--==> "UB" == Uwe Brauer <oub(a)ucmail.ucm.es> writes:
UB> Steve Youngs writes:
>It could be. But 3rd party packages should go into:
>$prefix/lib/xemacs/site-packages/
UB> Ups well, if you have root access. However on your own Linux/BSD
UB> whatsoever PC this is obvious but I guess there are guys out, on say
UB> Solaris workstations. So they can't install there (yes I know they
UB> cannot upgrade the packages neither)
UB> I thought that is what .xemacs is for?
You could put them into ~/.xemacs/site-packages/ also.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
4:06 a.m.
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
MT> Create a new idea called a DISTRIBUTION, where it is the CORE
MT> plus the bootstrapping packages.
SY> This is something that we are considering. I'm not sure how
SY> far along things are though.
SY> Steve T: What's the status on this? If you like I can channel
SY> some of my time towards getting something working.
I probably would not work on it for a couple months, I guess, but I
would certainly help if somebody else takes the lead.
The basic idea is simple: put a tarball of xemacs-base+EFS,
alternatively the current SUMOs, in $srcdir/etc. Write a Lisp program
to put the contents in "the expected place" using the path-finding
routines Michael has designed. Add makefile targets for invoking the
Lisp program to unpack the bootstrap package or the SUMO(s), and
probably some routines to drop the admin directly into PUI (this makes
sense even if you install the SUMO(s)).
Some of the stuff you would have to vet anyway: the bootstrap package
should be automatically generated, I think, and maybe kept as a
separate module in CVS. Building it probably would require something
in your build scripts similar to the SUMO but only for the minimal
set. Possibly there need to be changes to PUI (mostly sanity-checking
where the package-base file goes and stuff).
I think it would be trivial to add the code to my script to roll these
into the xemacs tarballs. The bootstrap package would become part of
the standard xemacs-$version.tar.gz and xemacs-$version-src.tar.gz,
both the regular and Mule SUMOs would be in a new tarball
xemacs-$version-sumo.tar.gz. (Or maybe I should do as Martin always
advocated and the +SUMO tarball would be xemacs-$version.tar.gz, the
bootstrap tarball would be xemacs-$version-bootstrap.tar.gz.)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
4:10 a.m.
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
> --==> "AJR" == A J Rossini
<rossini(a)blindglobe.net> writes:
AJR> But this won't help with
having packages INSTALLED IN PLACE,
AJR> will it? (i.e. I thought you couldn't work right out of a
AJR> copy of a checkout of the packages CVS repository, though I'd
AJR> be really happy to be wrong :-).
SY> No, you are correct, you can't run packages "in place".
However, this may change; Michael has mentioned moving to a
$package/{etc,lib-src,lisp,info,man,...} organization from the current
{etc,lib-src,lisp,info,man,...}/$package setup. Further changes might
be required to make run-in-place work, but that is the main barrier at
the moment AFAIK.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
3:41 p.m.
Steve Youngs writes:
|--==> "gb" == giacomo boffi
<giacomo.boffi(a)polimi.it> writes:
gb> but what do you think about the option of keeping an
gb> installed package hierarchy on sunsite.dk?
And available via rsync...
you perfectly got the point...
I really like the sound of that. I
yes, it _sounds_ like a pretty good idea (devil hides in the details)
wonder how workable it would be, and how hard would it be to set up
and maintain?
probably it's not harder than typing
"rsync installedtree sunsite.dk:installedtree"
when you have a) rsynch access to sunsite.dk and b) an installed
package tree on your local machine...
4:22 p.m.
>>>> Stephen J Turnbull writes:
>>>> "SY" == Steve Youngs <youngs(a)xemacs.org> writes:
>> --==> "AJR" == A J Rossini <rossini(a)blindglobe.net> writes:
AJR> But this won't help with having packages INSTALLED IN PLACE,
AJR> will it? (i.e. I thought you couldn't work right out of a
AJR> copy of a checkout of the packages CVS repository, though I'd
AJR> be really happy to be wrong :-).
SY> No, you are correct, you can't run packages "in place".
However, this may change; Michael has mentioned moving to a
$package/{etc,lib-src,lisp,info,man,...} organization from the current
{etc,lib-src,lisp,info,man,...}/$package setup. Further changes might
be required to make run-in-place work, but that is the main barrier at
the moment AFAIK.
Won't that tend to vastly increase the size of load-path (etc.) and,
thus, slow down finding things?
--
David Masterson David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer Synopsys, Inc.
Software Engineering Sunnyvale, CA
5:32 p.m.
David Masterson writes:
>>>>> Stephen J Turnbull writes:
> However, this may change; Michael has mentioned moving to a
> $package/{etc,lib-src,lisp,info,man,...} organization from the
> current {etc,lib-src,lisp,info,man,...}/$package setup. Further
> changes might be required to make run-in-place work, but that is
> the main barrier at the moment AFAIK.
Won't that tend to vastly increase the size of load-path (etc.)
no, every pakage has already an entry in load-path...
(insert (pp load-path))
("/home/gb/lib/emacs/test"
"/home/gb/lib/emacs"
"/usr/local/lib/xemacs/site-lisp/"
"/usr/local/lib/xemacs/site-lisp/edb/"
"/usr/local/lib/xemacs/xemacs-packages/lisp/"
"/usr/local/lib/xemacs/xemacs-packages/lisp/apel/"
"/usr/local/lib/xemacs/xemacs-packages/lisp/auctex/"
"/usr/local/lib/xemacs/xemacs-packages/lisp/bbdb/"
"/usr/local/lib/xemacs/xemacs-packages/lisp/build/"
...
"/usr/local/lib/xemacs/xemacs-packages/lisp/xemacs-base/"
"/usr/local/lib/xemacs/xemacs-packages/lisp/xemacs-devel/"
"/usr/local/lib/xemacs-21.5-b6/lisp/")
7:02 a.m.
>>>> "David" == David Masterson
<dmaster(a)synopsys.com> writes:
> However, this may change; Michael has mentioned moving to a
> $package/{etc,lib-src,lisp,info,man,...} organization from the
> current {etc,lib-src,lisp,info,man,...}/$package setup.
> Further changes might be required to make run-in-place work,
> but that is the main barrier at the moment AFAIK.
David> Won't that tend to vastly increase the size of load-path
David> (etc.) and, thus, slow down finding things?
Actually, it will be exactly the same size. One of the things that
slows down XEmacs startup is that we walk the Lisp hierarchies, and
eliminate anything from load-path that does not contain Lisp. This
actually is costless, because besides looking for flowers, we also
collect autoloads. The autoloads are absolute paths, so very fast.
There is a further optimization that has been proposed, which is to
collect the autoloads into a single library found in a fixed place.
But the gains to that are small unless you restart XEmacs a lot, which
is deprecated practice anyway.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
10:17 p.m.
|--==> "DM" == David Masterson <dmaster(a)synopsys.com> writes:
>>>>>Stephen J Turnbull writes:
>>>>>"SY" == Steve Youngs <youngs(a)xemacs.org> writes:
SY> No, you are correct, you can't run packages "in place".
>However, this may change; Michael has mentioned moving to a
>$package/{etc,lib-src,lisp,info,man,...} organization from the current
>{etc,lib-src,lisp,info,man,...}/$package setup. Further changes might
>be required to make run-in-place work, but that is the main barrier at
>the moment AFAIK.
DM> Won't that tend to vastly increase the size of load-path (etc.) and,
DM> thus, slow down finding things?
No, the load-path will still be the same size because nothing is
getting added (or removed), just moved.
However, the exec-path will grow a bit, and the search path for info
docs will get astronomical. This is because in the current setup we
only have a single 'lib-src' and 'info' directory for all the
packages. [1] Changing to the suggested structure will mean that there
will be a 'lib-src' and 'info' directory for each package that needs
them.
Footnotes:
[1] mule-packages have their own lib-src and info as well.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
10:23 p.m.
|--==> "gb" == giacomo boffi <giacomo.boffi(a)polimi.it> writes:
gb> Steve Youngs writes:
>|--==> "gb" == giacomo boffi
<giacomo.boffi(a)polimi.it> writes:
>
gb> but what do you think about the option of keeping an
gb> installed package hierarchy on sunsite.dk?
>
>And available via rsync...
>wonder how workable it would be, and how hard would it be to set
up
>and maintain?
gb> probably it's not harder than typing
gb> "rsync installedtree sunsite.dk:installedtree"
gb> when you have a) rsynch access to sunsite.dk and b) an installed
gb> package tree on your local machine...
I meant from my point of view (the server side).
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
5:33 a.m.
>>>> Steve Youngs writes:
|--==> "DM" == David Masterson <dmaster(a)synopsys.com> writes:
>>>>>> Stephen J Turnbull writes:
>>>>>> "SY" == Steve Youngs <youngs(a)xemacs.org> writes:
SY> No, you are correct, you can't run packages "in place".
>> However, this may change; Michael has mentioned moving to a
>> $package/{etc,lib-src,lisp,info,man,...} organization from the current
>> {etc,lib-src,lisp,info,man,...}/$package setup. Further changes might
>> be required to make run-in-place work, but that is the main barrier at
>> the moment AFAIK.
DM> Won't that tend to vastly increase the size of load-path (etc.) and,
DM> thus, slow down finding things?
No, the load-path will still be the same size because nothing is
getting added (or removed), just moved.
However, the exec-path will grow a bit, and the search path for info
docs will get astronomical. This is because in the current setup we
only have a single 'lib-src' and 'info' directory for all the
packages. [1] Changing to the suggested structure will mean that
there will be a 'lib-src' and 'info' directory for each package that
needs them.
I actually think this is a good thing as it will make each package
much easier to control. I think I suggested this style of setup to
Steve Baur just before the packaging system took shape. I never went
into detailed design, so, when the directory model got flipped to what
it is now, I assumed it was for performance reasons to keep the paths
from getting too big (along with other reasons I didn't know).
Ultimately, I think this new model will make it much easier for people
to experiment with different versions of a package. Large companies
using XEmacs, for instance, might not want to update their packages
until they've tested the new stuff out for awhile. They could
maintain a stable and a beta package area (or even a combination),
then allow their users to choose by simply loading a file that sets up
the appropriate "paths".
Footnotes:
[1] mule-packages have their own lib-src and info as well.
Hmmm. Speaking of multi-language packages, is there going to be a
need to allow for multiple versions of an info (etc.) file that is
chosen by $LANG (what's the equivalent in XEmacs)? Sure, you need
someone to do the translations, but that's a different issue. ;-)
--
David Masterson
dsm(a)rawbw.com
7997
days inactive
8015
days old
69 comments
17 participants
participants (17)
-
A.J. Rossini -
Adrian Aichner -
Alex Schroeder -
Andy Piper -
David Masterson -
David Masterson -
Giacomo Boffi -
Kai Großjohann -
Mark Thomas -
Michael Sperber -
Nix -
Norbert Koch -
Stephen J. Turnbull -
Steve Youngs -
Uwe Brauer -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks -
Ville Skyttä