Bug#291939: Split System/Cpu for architecture handling
On Mon, Jan 24, 2005 at 03:59:48PM +0100, Robert Millan wrote:
> On Mon, Jan 24, 2005 at 03:26:35PM +0100, Guillem Jover wrote:
> > 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.
That's fine.
> - Second step is slowly migrating all packages (via Policy).
With your approach, *all* packages need to migrate to the new syntax,
I think that's a bit extreme. From those almost 9k packages a big
majority use 'any' or 'all' specifiers so it's a lot of work and
uploads to finish that migration, that can take years.
With mine you only need to fix the ones that have kludges right
now, not all of them, most will be valid righ now in fact.
> - Third step is making the change effective wrt DAK.
That would imply changing the archive layout, breaking backward
compatibility, making binary package incompatible with older releases
(BTW how would you guarantee the one release upgrade if you want to
change binary package arch names?). Also the following point:
On another mail, Robert Millan wrote:
> Cpu: all / System: all == Architecture: all
> Cpu: any / System: any == Architecture: any
>
> Mixed any/all settings are syntacticaly supported, although since dpkg
> or DAK wouldn't support them, Cpu is mandatory for now:
>
> Cpu: any / System: all == Architecture: any
> (e.g. a package with pure-i386 executables like GRUB stage files)
>
> Cpu: all / System: any == Architecture: all
> (e.g. kernel sources or system-specific documentation)
>
> In the future DAK/dpkg should be able to understand these combinations,
> though.
*If* really desired that could be solved easily with my implementation,
just add any-all or all-any when DAK/dpkg can handle that as real
binary packages arches, but ...
... I think the problem is that there are not enough packages to
justify creating (n * cpu) + (n * system) arches to handle those odd
cases, although they would be not real arches as they would get
included in every arch in the same way we handle 'all' packages inside
every 'any' arch. That I suppose is something only ftpmaster can
answer, though.
> > [...]. 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.
I've not done a deep search, just something I recalled, take a look
at fdisk-udeb (alpha amd64 arm hppa i386 ia64 mips mipsel powerpc
hurd-i386 sparc), represent that in your design. (That could have
kfreebsd-i386 as well, once I submit those damn patches. O:> )
> 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.
No the only problem I see is the assumption that <cpu> == linux-<cpu>
and not any-<cpu> as would be the logic thing.
> > 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.
No, they are not orthogonal, they are bound, you cannot take a binary
from linux-i386 and install it on kfreebsd-i386, both delimit the
range the binary can apply to, they ABI to which they conform. Also that
you have a package for linux does not mean it should work on all cpus,
some linux ports don't offer the same API and you some times lack
functionality, etc.
> OTOH, having to choose from a list of valid permutations is certainly not the
> easiest for a maintainer to deal with.
It's way logical than restricting him/her to only a square matrix of
(cpu * system).
> > 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.
I don't consider my solution a kludge, I consider it the fix it needs
to get coherent.
regards,
guillem
Reply to: