Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs
On Wed, 30 Aug 2000, Branden Robinson wrote:
> > That is one mechanism of creating a private namespace, isn't another
> > Setting the origin to something other than Debian?
>
> Please see elsewhere in this thread for my other remarks on this subject.
>
> An Origin field is a great idea.
We have one, sorry I am so late making it be really useful - very busy you
know..
Assuming I can manage to get in the proper frame of mind this problem
should become much less troubling for most APT users.
The versioning scheme I will suggest is fairly direct:
1) If the package is derived from a debian package it should encode that
fact by using -1.storm.1, or -1.1, -0.storm.1, etc or whatever seems
appropriate.
2) If the package is not derived from a debian package it should use a
plain version, -1.storm, -1 or something
3) Libraries - All possible effort should be made to make Debian the
primary source of libraries. Period full stop. This is so important
because of what we are seeing with helix and their special library
packages now. Thus, I suggest the following:
a) If a add-on vendor needs a newer upstream library then they
can follow standard NMU procedures, using a -0.1.helix type tag.
b) If their is some critical bug in the Debian library then they
should still follow NMU type procedures and work with the
Debian library packager and upstream to make sure the next rev
is properly fixed.
c) I recommend the vendor provide a seperate section of their
FTP site specifically for libraries, and tagged with a proper
Release file. The libraries they collect there should be the
libraries they use and have modified. It would be best if most
of these files were exactly identical to what Debian ships.
Rational:
i) I expect people like helix will include woody
libraries that work on a potato system. These can use the
'usual' 1.2-0.1.woody.1 tagging scheme and probably will not
be included by Debian.
ii) I want the user to be able to say 'I want only helix gnome
but pick the newest library from the union of
debian+helix'. This is easiest if the libraries are
seperated.
iii) Libraries are truely a shared resource, we need to take
special steps to ensure apps in Debian linked to them work
and apps in Helix linked to them work - best way to that
is to only have 1 library package that everyone uses and
tests against.
Encoding the vendor tag in the version string will allow the user to know
which version has been installed. It is also important to make sure that
each vendor is creating universially unique package/version/arch triplets.
APT can handle most cases where this is not true but it is *very*
confusing to the end user and is best advoided.
Inter-origin version comparisions is probably fairly pointless - what is
newer? libgnome 1.2-1.storm.1 or libgnome 1.2-1.helix.1 ?
Selecting which origin is prefered (debian, helix, storm) is done in APT,
via a user configurable system on a per-package and 'default' sort of
basis. Vendors should not try to use weird versioning like epochs and
-storm and so on to enforce an upgrade path.
I hope there will ultimately be a nice simple command that says
'Prefer to install packages from helix' which can be placed in
installation instructions and in installation scripts.
Night,
Jason
Reply to: