* Julian Mehnle ([EMAIL PROTECTED]) [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