Comments: Draft spec and package format/naming
The current spec reads:
The current "plan-of-record" is to specify RPM as the file format. It is
supported either directly, or indirectly by the widest number of
distributions, and so far, no one has pointed out any deficiencies.
I would suggest that while the actual format of the package is possibly
retained, it would be wise to change the actual extension from .rpm to .lsb
(for example). This will avoid confusion with the legacy packages that are
inevitably going to remain on the net.
With regard to naming, most programs are identified by a triplet of numbers,
like the Linux kernel, this should be incorporated in to the name.
Additionally since this has to cope with binary and source packages it is
necessary to incorporate an architecture format into the name. My suggestions
are that a package is named as:
name-XX.YY.ZZ.ARCH.lsb
Where
name is the package name, eg fileutils
XX, YY, ZZ are the version triplet XX is the most significant, ZZ the
least ARCH is the supported architecture for binary packages
i386 - general x86 version
i586 - version optimised for Pentium class
i686 - version optimised for Pentium Pro/II/III class
sparc
sparc64
alpha
mips
etc, etc
src - the package is source
And finally the .lsb extension to indicate an LSB compliant package.
Additionally, since many packages are now using the ./configure method to
configure themselves, it would be nice to know how the current version of the
package was installed. This should be in the form of a queriable database, so
I can ask, for example, "how was the last version of mico configured" and it
would reply "mico: ./configure --with-ssl --prefix=/usr" or similar. This
helps when there aren't packages available since it reduces possibilities of
multiple copies of the binary/libs in /usr and /usr/local which would cause no
end of hassle. In the cases of a package not using ./configure, a database of
options set in build configuration files would be nice, but more difficult to
maintain.
Queries on the installed package database should be version insensitive, eg if
I query fileutils it will return fileutils-3.0.4 or whatever. Filename
queries should also return the full version.
Package dependencies should be specified in the package by saying this package
relies on > qt-2.0.0 or > qt-2.0 In the second case the least significant
version is missing, meaning that it can be ignored. Dependencies should be
witten using a standard set of comparisons, ie > < >= <= == (!=), && || etc so
that specific versions or ranges can be specified.
eg (>= qt-2 && < qt-3) && != qt-2.0.5
This is qt version must be 2 or above, but less than 3, but don't use 2.0.5
because it is seriously broken (just an example :-).
How these dependencies are actually managed is up to the management tool. ie
one distro may choose to just report them, another may fail to install until
deps are resolved (probs with circular deps) and another may choose to
automatically download packages and install them for the user.
It would also be useful to allow the user to say package XXX is installed,
even if it isn't. For example Qmail provides the functionality of sendmail.
My database entry says I have Qmail-1.0.3 installed but a package I install
says it needs sendmail-8.1.3. Either the qmail package makes the necessary
sendmail entry or the package I'm installing has to say requires "sendmail or
qmail or smail or ..."
It would be nice to just insert into the database ignore dependencies on
sendmail.
If this doesn't happen and an auto download/installer mechanism is in use then
it could mean that parts of my Qmail installation get clobbered, therefore a
journalling installation would be nice so I can easily undo a failed/broken
installation so my system is returned to the same state as before. This
means making backups of programs either in the filesystem, ie I upgrade
/usr/sbin/sendmail and it saves the old version as /usr/sbin/sendmail.old (and
disables execution of old binary -> give it mode 0400), or puts the file in
/tmp/old/sendmail which is out of the path.
How this is implemented depends on the distro, but sensibly it would have a
backend library to perform the operations and check deps etc, and then the
front end is written on top of this by the distributor, either in the form of
an CLI/ncurses/X/kde/gnome etc interface.
I'm sure some of the things I've suggested are already present in current
package management systems (ie .rpm and .deb) but in order to avoid flame
wars, a distro independent format is nicer!
Regards,
James
Sorry about the long post :-)
Reply to: