smarter way to differ architectures needed?
Hi,
another Hurd thing is (very slowly) approaching, which will become
important for auto building.
Current situation
==================
Architecture: all
means that the same package works on all ports.
Architecture: any
means that the package works on all ports, but must be recompiled.
Architecture: arch1 arch2 ...
means that the package works on arch1, arch2, ..., but must be recompiled.
Unfortunately, because we leave Linux territory with the Hurd, this is not
enough anymore.
Counterexample
==============
Package: makedev
Architecture: all
But the Hurd needs its own version of makedev, which is in the package
"hurd" (probably, I will split the hurd package in the near future to create
a makedev package, too, but currently this is not possible, and it only
"Provides: makedev".)
Possible Solutions
==================
a) Introduce new Architecture flags, "all-linux", "all-gnu" (or all-hurd),
"any-linux", "any-gnu" (or any-hurd).
These would mean, that a package works on all or any architectures which
do not or do have "hurd-" string prepended. (i386 resp hurd-i386 etc).
b) Introduce new System: linux or gnu (or hurd) field.
This would be a cleaner solution. Compared with (a), it would mean that
all-linux correspondends to "Architecture: all" and "System: linux", while
any-gnu would be equivalent to "Architecture: any" and "System: gnu" (or
hurd).
Note that this solution would probably allow for seperating processor and
system type in the future, so you could have "Architecture: i386" and
"System: any" meaning that this works for "i386" as well as for
"i386-linux". Just to show that this can be extended in various
directions. For example for a package with some assembler code.
In solution (a), this would require mentioning both explicit in the
Architecture field.
The possible fields would be "linux", "gnu" (or hurd) and "any".
If Architecture and System are "any", the usual meaning for Architecture
any applies. If Architecture is "all", System "any", the usual meaning for
Architecture "all" applies (we could allow "System: all" as synonym for
consistency). If System is either linux or gnu (or hurd), and
Architecture is "any", then only some ports would try to compile the
package. BUT if Architecture is "all" in this case, dinstall must only
symlink from one type of ports, linux or hurd ports.
Note that both variants, (a) and (b) require some changes to the ftp site
(for support of binary all packages), namely new binary-all-linux and
binary-all-gnu (or binary-all-hurd) trees, more logic in dinstall and the
various auto builder (for support of binary any packages). Although some people
may be scared by this, we should seriously consider this solution,
especially (b), because it is the cleaner solution to this problem. Here is
another one, though:
(c) Do not change anything in the ftp archive, but solve this on a
per-package base. For example, "makedev" would have "Architecture: i386
m68k sparc powerpc arm alpha ..." and the hurd package would produce a
makedev package with architecture hurd-i386 hurd-alpha...
Note that this is absolutely necessary if we neglect (a) or (b), because
currently binary-all is shared by ALL ports.
QUESTION: Can one port have a package with the same name as a package in
binary-all? What would happen if I would upload a package "makedev" with
Architecture: hurd-i386? Would it replace only the symlnk in the Hurd
port, or would it affect other ports, too?
This solution has some obvious negative points: Itdefeats the original
idea of Architecture: all. It requires more maintenance for the package
maintainer, because he has to add architectures once in a while. It uses
up more ftp space. It has also advantages: It does not require changes
to the ftp archive.
The ideal solution depends obviously on the number of affected packages.
Unfortunately, such a number is difficult to give.
Of binary all packages, the only examples I know currently are makedev and
modconf. Just for them, (a) or (b) are not warranted, they look like overkill.
But if more packages are affected, do we want to pester the package maintainers
with suboptimal solutions like (c)? I don't know.
It is also possible to introduce different solutions for binary all and
binary any packages. The binary all packages are obviously creating more
hassles with the ftp archive, if (a) or (b) is chosen, so you may want to
use (c) for them. The binary any packages could always be handled by an
exception list for the auto builders (which is very dirty but lazy).
Note that there will be quite a number of Linux only packages.
I will be able to collect more information about the number and size of
affected packages in the next months. Please do not consider this mail as
the start of a proposal in the next time. There is no need for immediate
action. I just want to have some input on this topic, and an answer to my
question above (which implies another temporary solution (d)).
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@
Marcus Brinkmann GNU http://www.gnu.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: