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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
