* Michael Banck ([EMAIL PROTECTED]) [030626 08:20]: > On Wed, Jun 25, 2003 at 06:50:54PM +0200, Andreas Barth wrote: > > What does oppose us to make subarchitectures quite more easy than now? > > (That would also be useful for the AMD Opteron and the like that could > > use normal i386-code, but can profit from optimized code.)
> Nothing opposes it, we're just missing something: The correct patch. I would start with a proposal first before writing code. Below is a draft, comments to it? (I know it doesn't specify every detail. It is a start, not more nor less, and it should be expanded if acceptable in general. Also a list of subarchitectures must be created. I'm also willing to produce code once this or another proposal is accepted.) DRAFT - Subarchitectures for debian [0.1] Subarchitectures are an extension to a given architecture that provides optimized binaries that work only (optimized) on a part of machines of the whole architecture. For example: Code using the MMX-extensions can not work on all i386-machines. In this text I will use architecture_subarchitecture or _subarchitecture in examples if speaking of a subarchitecture (e.g. i386_i386). This text speaks only of the debian archive and the user interface at installing packages. If this proposal is adopted it must be expanded to the packaging tools of course. Goal: The addition of subarchitectures must not break the current archiving system, but enhance it. On the other hand, it must be easy to use and most transparent to the users. I assume that most packages need not to be present in an extra subarchitecture-specified version in the archive, otherwise it would be useful to make a full new architecture. control-Files: The syntax of the control-Files is extended in the following way: The field "Filename" gives the default file for this package. It must be able to run on each machine of the given architecture, as tools not knowing of subarchitectures will use this file. (Of course it might be neccassary to use the standard emulator provided by debian as discussed at the moment for i386_i386. And I didn't say "make good performance". No, it just must run. It might be really very suboptimal, e.g. using much too much emulation code as in "optimized for _i686, opcodes from _i586, running on _i386, and opcode emulation in the default linux kernel by debian".) It is possible to specify another file for subarchitectures with "Filename[+-]<subarchitecture>", e.g. Filename-i486. A '-' says: Use this file exactly for the given subarchitecture. A '+' means: For this and any 'higher' subarchitecture, unless there is a closer match. '+' has the advantage of making the control-files a bit smaller, but might be too unfocussed. So both alternatives are given, and the package maintainer can choose which one suits better in his case. Meta-Subarchitectures: Sometimes it is usefull to put some subarchitectures together again by a specific criterium like existence of a MMU. For this meta-subarchitectures can be used. Creating of new subarchitectures (and exceptions to the said): If a new subarchitecture is created there are usually no specific files for it at the beginning. But it is usually suboptimal to start at the very beginning and the lowest common denominator for the whole architecture. So at selecting the filename of an old package for a new subarchitecture the selecting tools uses instead a predefined other subarchitecture. (As a simple example just imagine Debian is running on _i286, _i386 and _i486 and we just created new _i486. If a system using _i486 is installing an old package, the selection tools just behaves as the system is _i386.) "Old" is a package that gives a Standards-Version where the given subarchitecture was not defined. Packages only for parts of the architecture: Sometimes a package is only usable on specific subarchitectures because of allowing to manipulate specific things, eg microcode updates, http://packages.debian.org/microcode.ctl. In this case the package must not specify the filename-field in the control-file. The package selection tools must show by default these packages exactly on the subarchitectures where it provide files. Such a package must make a Pre-Depend on an dpkg-Version knowing of subarchitectures and such a package must not be uploaded to woody or any older release, including security or proposed-updates. Next steps: I put this list up on http://home.arcor.de/andreas-barth/subarch.html and will update this file according to the discussion. The next steps are to get a decision whether to use subarchitectures or not, and about the above proposal. As soon as this is done the next steps are to enhance the archive tools. But step after step. 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
