7 a.m.
Just been thinking about this.
A nice solution to distributing XEmacs packages that need some kind of
helper app (eg Eicq) would be:
- The helper app gets distributed in source form only.
- On first invocation of the package some clever lisp would
configure/compile the app and install it into lib-src.
Sound like a fun hack?
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
1:23 p.m.
>>>> "Steve" == Steve Youngs
<youngs(a)xemacs.org> writes:
Steve> - The helper app gets distributed in source form only. - On
Steve> first invocation of the package some clever lisp would
Steve> configure/compile the app and install it into lib-src.
Steve> Sound like a fun hack?
Steve> -- |---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---| |
Steve> XEmacs - It's not just an editor. | | It's a way of life. |
Steve> |------------------------------------<youngs(a)xemacs.org>---|
1:45 p.m.
[Sorry for the previous garbled message. My five-month old son managed to hit
just the wrong combination of keys while I was holding down control!]
>>>> "Steve" == Steve Youngs
<youngs(a)xemacs.org> writes:
Steve> - The helper app gets distributed in source form only.
This sounds like a good start, but there would still have to binary versions
available for at least Windows, if not other architectures. Is access to a
compiler guaranteed?
Steve> - first invocation of the package some clever lisp would
Steve> configure/compile the app and install it into lib-src.
Steve> Sound like a fun hack?
Sounds like a great hack, but it wouldn't work in multi-user sites. It's very
likely that in those situations the first person to use the package would not
have write access to lib-src.
Building at installation time would be preferred, at least then you can assume
that you have write access. Better yet would be a separate source package.
It will complicate the install process, but you'll get that with the Windows
binary version anyway, so it is no extra hardship.
Malcolm Purvis
2:02 p.m.
Malcolm Purvis <malcolmpurvis(a)optushome.com.au> writes:
Steve> - The helper app gets distributed in source form only.
This sounds like a good start, but there would still have to binary versions
available for at least Windows, if not other architectures. Is access to a
compiler guaranteed?
Definitely not. Even disregarding platforms like Windows and Mac,
some commercial Unix systems ship without a working C compiler. Also,
the C compiler is not in all cases trivial to use correctly, the
libraries might be in strange places, etc. Automatic invocation of
the compiler is a very risky game.
Steve> - first invocation of the package some clever lisp would
Steve> configure/compile the app and install it into lib-src.
Steve> Sound like a fun hack?
Sounds like a great hack, but it wouldn't work in multi-user sites.
This could be fixed by installing the binary somewhere in `.xemacs/'
hierarchy. But other problems remain.
The ideal solution would IMHO be to support the concept of package
"installation" with a utility other than `tar'. Then the packages
that require the C compiler would be built from source at the time
when they are installed, preferrably by the administrator who knows
how to run his flavor of `cc'.
Building at installation time would be preferred,
Fully agreed.
4:11 p.m.
On Tue, 28 Aug 2001, Hrvoje Niksic wrote:
> Sounds like a great hack, but it wouldn't work in multi-user
sites.
This could be fixed by installing the binary somewhere in `.xemacs/'
hierarchy. But other problems remain.
Yes, such as being able to use more than OS with the same home directory.
> Building at installation time would be preferred,
Fully agreed.
IMHO it's not that clear. Today, XEmacs =users= are installing packages.
Not the administrator. So it can't be assumed that the user would be able
to baby-sit installing a binary. Even most administrators run into
problem building programs once in a while, so expecting users to handle
this hassle isn't fair.
IMHO using `rpm' or any other well-known packaging tool, that has already
went through all these problems and solved them, would be nice.
4:53 p.m.
Simon Josefsson <jas(a)extundo.com> writes:
> > Building at installation time would be preferred,
>
> Fully agreed.
IMHO it's not that clear. Today, XEmacs =users= are installing
packages. Not the administrator.
Is that your experience? From what I see, the administrators are
usually expected to set up XEmacs, which they do by downloading the
"SUMO" distribution.
The users who care to download individual packages seem to be the
minority of experts. Maybe things will be different in several years,
but that's how I see things "today."
So it can't be assumed that the user would be able to baby-sit
installing a binary.
You have a point. Still, building the binary at install-time sounds
much better than the proposed alternatives.
IMHO using `rpm' or any other well-known packaging tool, that
has
already went through all these problems and solved them, would be
nice.
Far from nice, I'm afraid. Using a generic packaging tool like RPM
wouldn't really solve the problems, it would just move them to a new
level, one I'm not sure we want to handle. Some of the problems I see
are:
* Whichever solution we choose will be unusable by many users. I, for
one, use Debian and don't want XEmacs to spawn `rpm' with its entire
infrastructure.
* Does RPM even run on Windows?
* Managers like RPM and dpkg are way too complex for what we need, and
yet are woefully inadequate when it comes to solving problems we
have. We need user-installable packages, installing packages in
different locations, support for multiple XEmacs versions on the
same machine, integration with Lisp code ("which package provides
this symbol?")
6:13 p.m.
Hrvoje Niksic <hniksic(a)arsdigita.com> writes:
>> > Building at installation time would be preferred,
>>
>> Fully agreed.
>
> IMHO it's not that clear. Today, XEmacs =users= are installing
> packages. Not the administrator.
Is that your experience? From what I see, the administrators are
usually expected to set up XEmacs, which they do by downloading the
"SUMO" distribution.
The users who care to download individual packages seem to be the
minority of experts. Maybe things will be different in several years,
but that's how I see things "today."
You're right. I think the /intention/ is for users to install the
packages though (why take up the menubar with it otherwise). If
everyone is happy with download SUMOs, why bother with packages? /I/
do think packages add a value, but maybe it takes a while until more
people realize it.
> IMHO using `rpm' or any other well-known packaging tool, that
has
> already went through all these problems and solved them, would be
> nice.
Far from nice, I'm afraid. Using a generic packaging tool like RPM
wouldn't really solve the problems, it would just move them to a new
level, one I'm not sure we want to handle.
Yup. But perhaps some other projects have the same headaches, and
will work on solving them in rpm/deb. A proprietary packaging system
takes time to maintain and wouldn't be reusable in other projects.
Also, users aren't familiar with it.
Some of the problems I see are:
* Whichever solution we choose will be unusable by many users. I, for
one, use Debian and don't want XEmacs to spawn `rpm' with its entire
infrastructure.
Maintaining both .deb and .rpm isn't impossible. I would imagine
debian/redhat people would be interested in helping maintain these as
well.
The current system has a problem on Debian/RedHat, updating any
package within XEmacs breaks the rpm/deb database.
* Does RPM even run on Windows?
Does Cygwin count as Windows? If so, yes.
But to be consistent, I would say that XEmacs should use the Windows
packaging system under Windows instead of using a proprietary system
most users aren't familiar with. OTOH, the windows packaging system
is probably even worse than deb/rpm. OTTH, must XEmacs windows users
are probably Cygwin users anyway, so they should be used to the Cygwin
installer (but perhaps that doesn't do updates..).
* Managers like RPM and dpkg are way too complex for what we need,
and
yet are woefully inadequate when it comes to solving problems we
have. We need user-installable packages, installing packages in
different locations, support for multiple XEmacs versions on the
same machine,
Rpm/deb should handle this, I think. It's just tar/cpio/whatever with
a fancy interface, you can unpack it everywhere.
Maybe we've had this discussion before though...
6:40 p.m.
Simon Josefsson <jas(a)extundo.com> writes:
> The users who care to download individual packages seem to be
the
> minority of experts. Maybe things will be different in several
> years, but that's how I see things "today."
You're right. I think the /intention/ is for users to install the
packages though (why take up the menubar with it otherwise).
You're making it sound like an either-or thing. I think the point is
that both the administrator *and* the user can choose which packages
to install. The administrator could install the packages he considers
useful to the majority of users, whereas the user could supplement
this list with her own packages of choice.
If everyone is happy with download SUMOs, why bother with packages?
/I/ do think packages add a value, but maybe it takes a while until
more people realize it.
The second sentence answers the first one. I would also add that the
current implementation makes it bothersome to deal with packages.
A proprietary packaging system takes time to maintain and
wouldn't
be reusable in other projects.
That's not necessarily a bad thing. A packaging system designed to
solve *our* problems might be easier to maintain than a generic
monster.
> * Whichever solution we choose will be unusable by many users.
I,
> for one, use Debian and don't want XEmacs to spawn `rpm' with its
> entire infrastructure.
Maintaining both .deb and .rpm isn't impossible.
Which doesn't really answer my complaint. :-(
> * Does RPM even run on Windows?
Does Cygwin count as Windows? If so, yes.
The conclusion doesn't follow from the premise. That's like saying
"Q: does X work on Windows? A: do you count Windows NT as Windows?
If so, yes."
Cygwin is a very cool toolset, but it should not be a requirement for
using XEmacs. Cygwin is not Windows and not all Windows XEmacs users
are Cygwin users.
> * Managers like RPM and dpkg are way too complex for what we
need,
> and yet are woefully inadequate when it comes to solving problems
> we have. We need user-installable packages, installing packages
> in different locations, support for multiple XEmacs versions on
> the same machine,
Rpm/deb should handle this, I think. It's just tar/cpio/whatever
with a fancy interface, you can unpack it everywhere.
This is simply false. One of my past jobs involved building the
Debian packaging system on Solaris, so I'm intimately familiar with
workings of (parts of) dpkg. It can definitely not handle the things
I listed above, including unpacking the software to a chosen location.
(Of course, I'm not talking about flags to manually unpack the package
-- you can always do that, but then the scripts aren't run, the
database is not updated, and you can generally stick to tar as well.)
9 p.m.
You make lots of good points, I only have a one comment now.
Hrvoje Niksic <hniksic(a)arsdigita.com> writes:
>> * Managers like RPM and dpkg are way too complex for what we
need,
>> and yet are woefully inadequate when it comes to solving problems
>> we have. We need user-installable packages, installing packages
>> in different locations, support for multiple XEmacs versions on
>> the same machine,
>
> Rpm/deb should handle this, I think. It's just tar/cpio/whatever
> with a fancy interface, you can unpack it everywhere.
This is simply false. One of my past jobs involved building the
Debian packaging system on Solaris, so I'm intimately familiar with
workings of (parts of) dpkg. It can definitely not handle the things
I listed above, including unpacking the software to a chosen location.
I'm only familiar with rpm, and it has --prefix that does relocation.
Really amazing that dpkg doesn't support it, I wonder how people with
more than one machine and a network filesystem survives.
9:39 p.m.
>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
I'm only familiar with rpm, and it has --prefix that does relocation.
Really amazing that dpkg doesn't support it, I wonder how people with
more than one machine and a network filesystem survives.
I wonder as well, but don't consider RPM as being helpful to solve
that problem.
Stefan
7:39 a.m.
>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
Simon> I'm only familiar with rpm, and it has --prefix that does
Simon> relocation. Really amazing that dpkg doesn't support it, I
Simon> wonder how people with more than one machine and a network
Simon> filesystem survives.
First, --prefix mostly doesn't do the job (cf Jered Floyd's post
"configure doesn't honor exec-prefix"), although --relocate might.
But not all packages are relocatable.
Second, applications make all kinds of assumptions about relative
paths or about $PATH. It would be very easy to break those apps in
unobvious ways; I bet that's why dpkg doesn't try to support this
functionality. That's a feature only someone who can afford 800
support lines could afford to support!
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
4:02 a.m.
Simon Josefsson writes:
On Tue, 28 Aug 2001, Hrvoje Niksic wrote:
> > Sounds like a great hack, but it wouldn't work in multi-user sites.
>
> This could be fixed by installing the binary somewhere in `.xemacs/'
> hierarchy. But other problems remain.
Yes, such as being able to use more than OS with the same home directory.
> > Building at installation time would be preferred,
>
> Fully agreed.
IMHO it's not that clear. Today, XEmacs =users= are installing packages.
Not the administrator. So it can't be assumed that the user would be able
to baby-sit installing a binary. Even most administrators run into
problem building programs once in a while, so expecting users to handle
this hassle isn't fair.
IMHO using `rpm' or any other well-known packaging tool, that has already
went through all these problems and solved them, would be nice.
what about those FreeBSD people who dont have a copy of rpm installed ??
on FreeBSD the linux packages compatability need to be installed
and windows people ?? does rpm run on win32 ??
you could use the pkg system for FreeBSD
its kinda like rpm in that it is a tgz that has a couple of files to
tell the pkg system what to do with them and info to put in the pkg tree
--
-------------------------------------------------------------------------
Peter (Rendhalver)
XEmacs Advocate
Perl Hacker
Apache God
FreeBSD Devote
rendhalver(a)users.sourceforge.net
There are only two things that are infinite,
the universe and human stupidity,
and i am not certain about the former
- Albert Einstein
-------------------------------------------------------------------------
8484
days inactive
8487
days old
11 comments
7 participants
participants (7)
-
Hrvoje Niksic -
Malcolm Purvis -
Peter Brown -
Simon Josefsson -
Stefan Monnier -
Stephen J. Turnbull -
Steve Youngs