Re: Debian GNU [was: smarter way to differ architectures needed?]
In article <[🔎] 86yak5erac.fsf@trick.fig.org> you write:
> 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:
I think | is aready used to mean "or"? or is it "||"?
Anyway, I would use another field, eg:
Nonshared-Depends: cpu-all, os-linux | os-hurd
Depends: editor
So it would have to be recompiled for anything in "Nonshared" depends,
but wouldn't have to be recompiled for anything in depends.
Then the magically value of "any" would become obsolete; I think
it was confusing anyway.
Note: The value of cpu-all is a special value that would expand to
"cpu-i386|cpu-sparc|...". Similarly for "os-all". This might seem a bit
strange, but I don't think it is a good idea to list every possible
combination in every source file.
When the source package is compiled, the appropriate items from
the "Nonshared-depends" would get moved to "Depends".
In addition, all these depends items should be able to have
a version number, just like any existing depends. That would mean
that, for instance, you can have something like:
Nonshared-Depends: cpu-all, os-linux (<2.1.0) | os-linux (>=2.1.0)
If the package needs to be recompiled for the different linux
version. (sorry, I may have the exact syntax wrong).
These are just sample field names. Anything could be used.
I think something like "conflicts" is also needed to say that
a package requires something, conflicts with something else, and
everything else is optional.
> 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]
I agree. You would however, have to be careful that binary-all isn't
clobbered with multiple versions of the same file that don't fit
the above rules.
>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.
Me thinks this could be the messy part. I agree though, it is a low
priority right now.
Reply to: