RE: Counter-Proposal: Architecture Versions and Architecture Features
Andreas Barth wrote:
> * Julian Mehnle (lists@mehnle.net) [030627 21:05]:
> > [...]
>
> 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 agree.
> 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). [...] 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.
>
> ... 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?
No package is required to support any arch features at all. If a package
just supports (i.e. requires) two arch features, while the actual arch
supports (i.e. provides) these plus an additional feature, one feature just
isn't going to be used by the package -- so what? The package might not be
running as fast as possible, but it will work. Just in case it wasn't
clear: it's up to the package maintainer to decide which arch version/
feature combos to build the package for.
> 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?
Are you implying that feature A will run slower on arch version 7 than on
arch version 6? Even if that were the case, the package maintainer could
just build one binary package for arch.6+A and one for arch.7 (no A
feature). It would then be up to the arch.7 system's administrator to
disallow the installation of +A packages by specifying his system to be
arch.7 only instead of arch.7+A (and this could as well be the global
default for arch.7+A systems).
I fear I don't entirely understand the scenarios you are portraying here.
I think there is no special-build case that can be handled by your proposal
but not by mine. If you know one, please name it, maybe I'm just to tired
to see it.
> In your proposal one is bound to suboptimal matches in special cases,
Which ones? Following my proposal, you are never forced to build any binary
packages beyond the base arch (e.g. plain "i386") package, but you may build
binary packages for any or all possible arch version/feature combos if you
want.
> 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). ;-)
My proposal doesn't force the building of any special-build binary packages
beyond the base arch package, and most packages (e.g. vi) will just have
this one base arch package. I'm certainly not preaching that vi would
benefit substantially from specialized builds. ;-)
> 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.
I don't see how. In fact, I think our models are equivalent regarding the
representable set of (sub-)architectures, but my model is more structured.
You are suggesting opaque, black-box-like (from the user's point of view)
sub-arch tags which apt and dpkg would be required knowing how to handle.
So you'd need to provide some data structures that explain to apt and dpkg
how, for instance, i386_i586 differs from i386_i586-mmx so they know that a
i386_i586 binary package would be an acceptable fallback for a i386_i586-mmx
system, but not the other way round.
My proposal does part of that work by breaking down the opaqueness into arch
versions and features. Every special-build case allowed by your proposal
could be represented by the "arch features" aspect of my proposal alone. I
only added the "arch versions" aspect due to its implicit ordering feature,
which makes life immensely easier for apt and dpkg (since most real-world
cases will be represantable solely through the use of arch versions).
Still, anything that can't be handled with arch versions can definitely be
handled with arch features.
As a proof to my point, just consider the set of special-build cases
(sub-arches) allowed by your proposal (take {i386, i386_i486, i386_i586,
i386_i586-mmx, i386_i686, i386_i686-mmx} as an example). That set of
special-build cases can be represented within my proposal by arch features
of the same names (minus [\._+-] differences) (the set being
{i386, i386+i486, i386+i586, i386+i586-mmx, i386+i686, i386+i686-mmx}).
That would be a gross abuse of my proposal (although it would work), and of
course using arch versions this should more cleverly be represented as
{x86.3, x86.4, x86.5, x86.5+mmx, x86.6, x86.6+mmx}, which would require the
base arch {x86}, the arch versions {3, 4, 5, 6}, and the arch feature {mmx}.
Much more modular approach, if you ask me, and much more graspable for apt
and dpkg as well.
> 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.
Next to what I said above, another point to my proposal is that it wouldn't
be necessary to explicitly "create" every combination of arch versions/
features beforehand (i.e. before specialized binary packages are built).
You'd just need to create the versions and features separately, and leave it
up to the maintainers which combinations to support.
> 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.
>
> Do I see it right that the package names are nowhere noted but created
> by s/<arch>/<best_match>/ on the fly?
Indeed.
> 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.
Can you name examples?
I doubt that it would make sense to give a binary package a different base
name (file name without arch specifier) just because it requires more or
less CPU/architecture features without having other differences from the
base arch package.
And why would you ever want to *explicitly* use one binary package file for
multiple sub-archs (some kind of symlink/hardlink concept?)? The arch
specifier of any given binary package describes exactly the minimum arch
version and minimum set of arch features it requires to run, so it can be
*implicitly* used for multiple sub-architectures already. IMO it makes
little sense to allow hard-coding of package file names here.
Julian.
Reply to: