[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: packaging system
From: |
David Bateman |
Subject: |
Re: packaging system |
Date: |
Wed, 22 Jun 2005 10:47:46 +0200 |
User-agent: |
Mozilla Thunderbird 0.8 (X11/20040923) |
Søren,
I think a bit more complete dependency checking code might be good idea
to get into place early to save us some pain later. At the moment you
have a line "Depends:" in the DESCRIPTION file, that contains a list of
all packages that the current package depends on. May I suggest that
each package dependency has a seperate "Depends:" line of the form
Depends: PACKAGE [<|=|>] VERSION
to take into account the possible need for a particular version of a
package or newer than, or range of versions.. For example you might have
Depends: Signal >= 1.0.0
Depends: Signal < 2.0.0
To say that the current package needs version 1.x for the package
"Signal" and not any previous or newer versions, or
Depends: StupidPackage = 1.0.1
to say that version 1.0.1 of StupidPackage is the only one that is known
to work with the new package.
There are also issues of upgrading packages and circular dependencies
that might prevent installation. The way around this is to allow the
install/uninstall scripts to accept cell-arrays that have a list of the
packages to install/uninstall. The first thing to do in that case would
be to gather all of the existing, upgraded and new DESCRIPTION files and
check that the dependencies after the install will be met, and only then
start the install/uninstall of all of the packaging in the cell array.
So a typical call might be "install ({'Comm', 'Signal'});" to allow the
installation of Comm and Signal is each depends on the other. I don't
think we want to get fancy and automatically install dependent packages
as this means that we'd need a mechanism to automatically download
packages from within octave itself, which would just add another thing
octave depends on.
As for dependency check on uninstall, I see no issues in traversing the
package tree reading all of the DESCRIPTION files. I don't believe it
will be that slow. Getting the dependency stuff right will save us a lot
of pain in the future so I see this as time well spent (though I
understand its your time and not mine).
One further point, your install scription introduces a new dependency of
octave on the external application "tar". Are there any other new
dependencies? How will this dependency be handled in a cygwin build?
What about a mingw build? This might cause issues..... However, its a
secondary point...
In any case great job, as this is something that has been needed for a
long time...
Cheers
David
--
David Bateman address@hidden
Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary
- Re: packaging system, (continued)
- Re: packaging system, Bill Denney, 2005/06/19
- Re: packaging system, Stefan van der Walt, 2005/06/20
- Re: packaging system, Søren Hauberg, 2005/06/20
- Re: packaging system, Stefan van der Walt, 2005/06/20
- Re: packaging system, Paul Kienzle, 2005/06/20
- Re: packaging system, Søren Hauberg, 2005/06/20
- Re: packaging system, Søren Hauberg, 2005/06/21
- Re: packaging system,
David Bateman <=
- Re: packaging system, Stefan van der Walt, 2005/06/22
- Re: packaging system, David Bateman, 2005/06/22
- Re: packaging system, Stefan van der Walt, 2005/06/22
- Re: packaging system, David Bateman, 2005/06/22
- Re: packaging system, Bill Denney, 2005/06/22
- Re: packaging system, Stefan van der Walt, 2005/06/22
- Re: packaging system, Stefan van der Walt, 2005/06/22
- Re: packaging system, Søren Hauberg, 2005/06/22
- Re: packaging system, David Bateman, 2005/06/22
- Re: packaging system, Søren Hauberg, 2005/06/26