Bug#291939: Split System/Cpu for architecture handling
On Mon, Jan 24, 2005 at 03:26:35PM +0100, Guillem Jover wrote:
>
> Yeah I meant to criticize it, but then forgot. :> Also I was not
> aware of that proposal. Or I cannot recall you telling me every
> time I brought out the alias idea. :>
Well, it's been in the BTS since 2001. You could have had a look ;).
> Ok, I see a couple of big problems with your implementation.
>
> * Currently a real Debian architecture is composed of kernel/system +
> cpu and that's a pair of characteristics that cannot and will not
> be decoupled easily from each binary package, the archive structure
> or the tools that handle them.
Yes it can. It's just a three-step transition:
- First step is allow dpkg and friends to understand new source format.
- Second step is slowly migrating all packages (via Policy).
- Third step is making the change effective wrt DAK.
> [...]. Your current syntax does not make possible to specify that
> a binary package is available just for hurd-i386, linux-i386 and
> linux-alpha, for example. That can be done with the current syntax,
Yes, but noone has ever done it (if you think someone has, please provide an
example). The reason is quite simple: it doesn't make sense to mix two
variables that are actualy orthogonal.
> * The Build-Depends syntax is not well defined as Goswin has pointed
> out, and it have the same problem as the above point, trying to
> decouple an information that it's naturally joined.
Cpu and System is not naturaly joined. We decided to join it when starting
the Hurd port in 1998, but time has proven that this was a wrong decision
(otherwise, none of us would be looking for a fix).
It was as early as 1999 when Marcus wrote dpkg-architecture to paliate that
problem. But he didn't fix all of it. My proposal is the remaining part.
> I assume the "..." specify additional entries, so in that case what
> valid permutations would you choose, and then how would you specify
> convintations that don't include all permutations?
>
> So I see the splitting approach just over complicates things instead
> of making them easier to deal with,
Again, Cpu and System are orthogonal. And setting two variables that behave
exactly like Architecture does (but separately) is quite simple to figure out
for the maintainer.
OTOH, having to choose from a list of valid permutations is certainly not the
easiest for a maintainer to deal with.
> also the concept is
> not as disrruptive in developer minds as the split one. :>
Replacing a simple scheme with another simple (but different) scheme is more
disruptive than adding kludges to the first scheme, that is true.
However, we really need to move onto the new scheme if we want a solution that
is clean and simple in the long term.
For the new maintainer, learning about two variables is easier than learning
about one variable and a bunch of regexps, aliases or other sort of kludges.
--
.''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `' http://www.debian.org/ports/kfreebsd-gnu
`-
Reply to: