Re: Counter-Proposal: Architecture Versions and Architecture Features
* Julian Mehnle (lists@mehnle.net) [030627 21:05]:
> I understand that the your proposed extensions to the Debian package system
> are based on the concepts of "sub-archs" and "meta-sub-archs" (I'd call
> these "pseudo-sub-archs" or "alias-sub-archs", though). I have already
> proposed a more genereal extension based on "arch versions" (essentially
> equivalent to sub-archs, except that an order is implicitly defined), and
> "features". I'll explain it in more detail, because I think that a more
> general approach would also be more flexible for potential future
> requirements in the Debian package system.
Thanks for your proposal. IMHO it is important that we are going to
adopt one or the other proposal rather soon, so that it could be used
in sarge.
I think both proposals have their specific advantages, and we must try to combine these.
Now to comments:
> Every base arch (alpha, i386, mips, ...) can, but isn't required to, have
> one or more explicit versions (as I said, these are equivalent to
> sub-archs). An arch version gets appended to the base arch name as
> ".<version>", the default version being 0. Thus, "i386" would be
> equivalent to "i386.0", and subsequent versions could be "i386.1",
> "i386.1foo", "i386.2", and so on.
> Arch versions are ordered
> alphabetically, with higher versions including the functionality of all
> lower versions, i.e. higher arch versions must be downwards compatible.
> Example: "i386" = "i386.0" < "i386.1" < "i386.1foo" < "i386.2".
The problem with this is: It works only if all relevant processor
makes can be seen as a chain by inclusion, i.e. there is only one heir
to each processor version. However, with AMDs Opteron on one side and
the certainly next Intel processor on the other side there will be two
"childs" with different features, so this fails. You can of course
make it with ....
> Independently, every arch can, but isn't required to, have one or more
> special features beyond what the base arch version supports. A feature
> gets appended to the arch name/version as "+<feature>". For "i386", there
> could be features like "fpu", "mmx", "sse", "sse2", etc. A single arch
> specifier can name any number of features, e.g. "i386+3dnow", or
> "i386.6+mmx+sse".
... but this has the disadvantage of being unexact. What to do if a
processor has three features, but in the special case the packages
allows only two of them at a time? Or to make it worse say processor A
supports maximum subarch 7, and feature A, but feature A can only be
used really fast in subarch 6; packages in subarch 7 must also be
built because they are faster on processors without feature A?
In your proposal one is bound to suboptimal matches in special cases,
and even a very good package maintainer can't get around. The argument
that special cases are seldom won't match here because: The whole
subarch-system is only needed in special cases. I don't believe that
vi will get substantial speed improvements because of subarch specific
versions (otherwise show me figures). ;-)
Because of this in my proposal exact matches are possible. There is
only one case where unexact must be used, and this is when a new
subarch comes to existence.
The subarch information that could be stored in your modell can be
also be stored in my modell, but also more complex information. (You
break up the subarch-info from my modell to several pieces. In my
modell there would be a subarch _i586 and _i586-mmx, and with an
unexact match packages for _i586 are also used for _i586-mmx, unless
there is a better, i.e. exact match.)
There is one obvious advantage of your proposal: The archive selection
code needs to know less of subarchs. But, as new subarchs aren't
created every day (unlike new version of ordinary packages) it's IMHO
ok to save magic code in the selection programms. It won't get real
large.
The other advantage is that it consumes less space in the Packages
file. But, as subarchs are needed on relativly few packages this is
IMHO ok because of the more mightier abilities.
> Available packages in the fictitious pool:
> (A) pool/contrib/q/quake2/quake2_0.2.1-4_i386.deb
> (B) pool/contrib/q/quake2/quake2_0.2.1-4_i386.5+mmx.deb
> (C) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+3dnow.deb
Do I see it right that the package names are nowhere noted but created
by s/<arch>/<best_match>/ on the fly? I specified the different files
on purpose in the Packages-File, as it might be useful in special
cases to use different filenames - or to use one file for different
subarchs.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Reply to: