[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#291939: Split System/Cpu for architecture handling



On Mon, Jan 24, 2005 at 05:45:23PM +0100, Guillem Jover wrote:
> >   - Second step is slowly migrating all packages (via Policy).
> 
> With your approach, *all* packages need to migrate to the new syntax,

No, not all.  We could maintain backwards compatibility by detecting the old
Architecture field like we do now but in the opposite direction.

> 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.

There's no hurry.  Debian releases typicaly take years anyway. =)

> >   - Third step is making the change effective wrt DAK.
> 
> That would imply changing the archive layout,

Yes.  But we don't need to do this untill the change is firmly stablished in
the source packages.

> breaking backward
> compatibility, making binary package incompatible with older releases

Not necessarily.  dpkg can maintain backwards compatibility and accept the
old format.

> (BTW how would you guarantee the one release upgrade if you want to
> change binary package arch names?). Also the following point:

First, get a dpkg that supports the new format in stable.  At this point we
can start deprecating the old format for the next release.

> ... 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.

I don't think it's important to discuss this now.  The DAK transition is a
really long-term thing.  I wouldn't expect it to happen before a kfreebsd-gnu
release or some such.

> 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:> )

Set it up to a list of all cpus it supports and a list of all systems it
supports.  There are no exceptions in the list.

> > 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.

Quoting from my last mail (which you probably didn't recieve yet):

"This was already proposed (in bug #263743).  Scott James and Martin Michlmayr
objected to it, and both suggested a split of the "Architecture" field, which
happens to be what I proposed back in #118910."

> > 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 insist on this but I can't see an example that proves they're not
orthogonal.  The fdisk example can be supported with a full cpu x system
matrix.

OTOH, the binary could also be a pure i386 executable with no syscalls or
shared library dependencies (e.g. GRUB stage files).  In the future, we'll be
able to use this combination to represent that:

  Cpu: i386
  System: all

> 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.

Indeed.  We represent that with a different System field.  My current proposal
is only for source but when it applies to binary, the System field determines
which libc did we link with, which kernel headers did we include, etc.

> 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.

You restrict that with the Cpu field.

> > 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.

Ok, but do you seriously think it's simpler?  Maintainer needs to know about
aliases and their syntax.  I prefer a clean scheme that new maintainers have
zero difficulty to understand and existing maintainers can migrate to, than
a tainted scheme that needs to cope with stuff that can't be changed (even
if we need to) in order to not confuse existing maintainers.

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'    http://www.debian.org/ports/kfreebsd-gnu
  `-



Reply to: