Re: arch: lines, for not-just-linux debian. (was Re: Hurd and architecture)
On Sat, Mar 31, 2001 at 05:05:00AM -1000, Brian Russo wrote:
> > What's become of the idea of using dependencies for
> > architectures? That scheme could even be extended to
> > subarchitectures or hardware features (ie Depends: i386, mmx,
> > libc6)
There are some touchy issues, but it would be easy to emulate the current
setup (by having only Debian architectures as virtual names), and transit
slowly as time and implementation allows.
> interesting idea, but i dont like the idea of doing it directly with Depends:
>
> theres already what, 4000 packages? 5000? i forget.
> you're working with an already limited namespace
>
> throwing more stuff in there is a Bad Idea (tm)
I don't think there are any problems with using the existing fields. The
actual set of (mostly virtual) architecture dependency names would be quite
small (initially as much as Debian ports, and ideally probably about a few
dozens), so this is nothing compared with the real packages.
The other reason is that you also need HW-Provides for systems capable to
run other systems binaries (like sparc32 vs 64, or binary compatibily
provided on BSD and later Hurd systems to run Linux binaries). So you also
want HW-Provides, and proably HW-Conflicts, too. And after some time, you
realize that some HW is virtual, and some is not, and you have created an
artificial difference between those types of dependencies.
> on the other hand.. maybe doing it with a HW-Depends: isnt such a bad idea..
> but, are there really that many programs out there that *need* mmx, etc?
There are many more reasons to seriously consider this approach. The right
answer to your question is probably: Maybe not, but to properly *allow*
programs to use mmx we need a finer distinction between architectures.
The flexibility you gain is not much if you just consider the mmx programs.
But if I tell you that the Hurd will provide binary compatibility for linux
executables, you can imagine that we would benefit from such a setup,
because we would not need to recompile a couple of thousands packages
(because we would just use the linux binary package for this cpu).
> consider, a sound card is needed for playing audio files (under typical
> conditions). so should my package depend on a sound card? i dont think so..
No. Which interfaces exactly should be specified depends on how fine a
seperation you actually want and which interfaces are used. Most packages
depend on libraries to do their job. So they get a library dependency.
A seperation at a linux kernel module level would not immediately be useful
(maybe at some later time, I don't know).
> how does my OS know i have a sound card? it checks for working /dev/dsp at
> install time or something? what if i dont have the module loaded..
> havent recompiled the kernel..etc
This is actually a very interesting question, and it is much more difficult
to solve than the issue I am concerned with. I would want to limit this
topic to "hard" interfaces like processor etc, which don't change often
usually.
> i dont think the packaging system should try to do everything..
I concur. But using depends for architeture handling at a very rough level
(not sound card, but just processor and important kernel interfaces like
procfs) is immediatley useful and can save a lot of man power (by
eliminating the need to recompile 3000 packages, for example).
However, I realize that Debian is probably not ready for this yet, and I
would already be satisfied to be able to say: this is linux-all, hurd-all,
linux-any, hurd-any. I think everybody can agree to that ;)
I wrote something about arch depends in more detail:
http://master.debian.org/~brinkmd/arch-handling.txt
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: