In article <[EMAIL PROTECTED]> you write: > >Currently, the only packages that can be shared are the ones that are >placed into `all'. This is the N=1 case. > >Marcus Brinkmann's (and I believe also your) temporary solution is to >create `all-linux', and `all-hurd' as well as `all'. This is the N=K >case, for an arbitrary constant K that takes a lot of work to modify >(i.e. is hardcoded into dinstall and dpkg).
>I want to create the N=infinity case. If we have N=infinity, then >really the only proper name for the superset of all those ports is >`Debian GNU' (at least, unless we all decide to start depending on >non-free packages, in which case the only proper name for it would be >just `Debian'). Agreed. In another words, you are saying what I was proposing made a number of key assumptions that made it inflexible. If I have got this right: So instead of of having *releases* for each combination of <release>,<kernel>,<cpu> You could have a *package* depend on any number of factors (as determined important), eg <kernel>,<cpu>,<glibcversion>,<gnomeversion> Therefore, grub would only depend on <cpu>, but a gnome package might depend on all of the above (I don't use gnome, so my assumptions may be incorrect). Just a comment: In the source code for each dependancy (eg CPU) you would a specification, ie something like: - the source code MUST be recompiled. eg for another CPU. - the source code does not have to be recompiled, but still should work. eg for another library that has the same ABI. - the source code is incompatable with this dependancy. eg for kernel specific code. I am not sure what the best way would be to specify this information, I am just saying that I think this information would be required. >Why should all ports have to release at the same time? Why should we >not allow different ports to depend on different versions of the same >package? So, you want to get rid of hamm,slink,potato,etc? How would you keep track of stable vs unstable? >I believe that's just a matter of time, and so I want to plan ahead so >that the transition is easier for the Debian GNU/Hurd folks. Our >(Hurd folks') work will resemble a cross between the libc5->libc6 >transition and Great X Reorganization, all in one. Anotherwords: A major mess ;-) >With dpkg and dinstall's current notion of Architecture, I dread that >work. If my idea of generic ABI dependencies is accepted and >implemented, I'll be greatly relieved, and actually *look forward* to >it. ;) > >Now I'll begin repeating my second mantra: ``There is no such thing as >Architecture, only Dependencies.'' > >Are there any seconders? So far I agree with what you have said. I am not yet an official Debian developer though - so I probably cannot second your mantra.
