Re: Debian GNU [was: smarter way to differ architectures needed?]
>>>>> Brian May writes:
BM> If I have got this right:
BM> So instead of of having *releases* for each combination of
BM> <release>,<kernel>,<cpu>
BM> You could have a *package* depend on any number of factors (as
BM> determined important), eg
BM> <kernel>,<cpu>,<glibcversion>,<gnomeversion>
BM> Therefore, grub would only depend on <cpu>, but a gnome package
BM> might depend on all of the above.
Exactly.
BM> Just a comment: In the source code for each dependancy (eg CPU)
BM> you would have a specification, ie something like:
BM> - the source code MUST be recompiled. eg for another CPU.
BM> - the source code does not have to be recompiled, but still
BM> should work. eg for another library that has the same ABI.
BM> - the source code is incompatable with this dependancy. eg for
BM> kernel specific code.
BM> I am not sure what the best way would be to specify this
BM> information, I am just saying that I think this information would
BM> be required.
Here is a possible way of specifying the information:
Anything that has a `|' in its dependencies means that there is more
than one kind of binary package, so, say the binary packages were
different depending on the kernel you had installed:
Depends: linux|hurd
If they were different also depending on the architecture, you would
say:
Depends: linux|hurd, hwarch-i386|hwarch-m68k
which would leave room for 4 different binary packages.
If the package also requires an editor, but it doesn't matter what
kind, then it would simply say:
Depends: linux|hurd, hwarch-i386|hwarch-m68k, editor
which still leaves room for only 4 different binary packages.
>> 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?
BM> So, you want to get rid of hamm,slink,potato,etc? How would you
BM> keep track of stable vs unstable?
I have utterly no idea. First let's change the dpkg technology. The
archive organization should come later.
Until there is a more elegant solution, we can just have dinstall map
certain dependencies into certain locations:
binary-i386: linux, hwarch-i386
binary-m68k: linux, hwarch-m68k
binary-alpha: linux, hwarch-alpha
binary-sparc: linux, hwarch-sparc
binary-arm: linux, hwarch-arm
binary-hurd-i386: hurd, hwarch-i386
binary-linux-all: linux
binary-hurd-all: hurd
binary-all: [default]
It would be nice to change dinstall so that we can create new distros
on the fly, but I think that's asking too much for an initial
proposal.
Seconders?
--
Gordon Matzigkeit <gord@fig.org> //\ I'm a FIG (http://www.fig.org/)
Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
Reply to: