Re: binary-alpha and binary-sparc directories

[Bill Mitchell <mitchell@mdd.comm.mot.com>]

> > > The way I see this working, architecture-specific maintainers with
> > > the ability to address architecture-specific bug reports and do
> > > architecture-specific testing would feed architecture-specific
> > > fixes and patches to the primary package maintainer.  Primary
> > > package maintainers having, say, a sparc would install alpha
> > > or i386 patches blindly, relying on the testing done by the
> > > alpha and i386 maintainers, and issue a package revision update.
> > 
> > Yes.
> 
> Sounds ok to me. Architecture-specific bugs for m68k will be discussed
> in our own debian-m68k mailing list, and if a package maintainer discovers
> a real problem that is architecture-independent, he would have to cooperate
> with the primary maintainer (where I'd like to see the corresponding person
> from the x86 staff to take this over).
> 
> Comments?

I'm wondering about the nitty-gritty source and binary package versioning.

Let's say we have an 1386 package:              zeppo-1.23-4.tar.gz.
Three binary packages are produced from this:   chico-1.23-4.deb
                                                harpo-1.23-4.deb
                                                groucho-1.23-4.deb
Power-PC and Mac binary packages appear.
What are these named?

It seems to me that that they'd be named
    {chico,harpo,groucho}-1.23-4.deb
for their respective architectures if no source changes are necessary.

If source changes are necessary, it seems that coordination with the
maintainer of the multi-architecture source package would be necessary
to establish lockstep source and binary package version numbering.
perhaps, the 1386+Mac source compatability changes would be versioned
as zeppo-1.23-5.tar.gz, and the i386+Mac+PowerPC changes versioned
as zeppo-1.23-6.tar.gz.

At that point, the current package files in the distribution would be:
    zeppo-1.23-6.tar.gz              for i386+Mac+PowerPC source
    {chico,harpo,groucho}-1.23-4.deb for i386
    {chico,harpo,groucho}-1.23-5.deb for Mac
    {chico,harpo,groucho}-1.23-6.deb for PowerPC
or perhaps
    {chico,harpo,groucho}-1.23-6.deb for i386
rebuilt and uploaded along with the re-uploaded source package.

Some platform-independent changes (or at least intended as such) by the
i386 maintainer, who is the multi-platform source maintainer, would produce

    zeppo-1.23-7.tar.gz              for source
    {chico,harpo,groucho}-1.23-7.deb for i386

and, at this point, the outdated binary packages

    {chico,harpo,groucho}-1.23-5.deb for Mac
    {chico,harpo,groucho}-1.23-6.deb for PowerPC

would still be in the distribution.

That's the picture I have of how this might work in practice.

This seems shakey -- especially if we posit that the i386 maintainer
is in the U.S., the Mac maintainer in Germany, and the PowerPC maintainer
in Korea.  Also, the upstream source maintainer might be in Romania,
and might not be be interested in picking up the Mac and PowerPC
changes which our maintainers have made to his source code.

Comments?  Improvements?  Better suggestions?






, and some changes by the i386 maintainer
intended to be compatable across all supported platforms might