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

Re: architecture-specific upload issues



> I think we should keep all changes announcements on one list, and
> firm up the policy about what the Subject line should look like. We
> have too bleeping many lists to keep up with already.

Right :-)

> Personally, I hope to be uploading for three architectures at once
> (i386, alpha, sparc) for my package uploads before too much
> longer... all with one changes file. I suspect this will take a few
> iterations to get the logistics right, but that's my goal.

I already do that for my packages. I always upload them for archs
"source i386 m68k" at the same time. Unfortunately, there's no policy
yet for the filename of the *.changes file of such a multi-arch upload
(or have I missed something?) Currently I use

  <package>_<version>_i386+m68k.changes

(which works) Or should I switch to something different?

A little problem is that dpkg-genchanges always generates single-arch
(plus "source") *.changes files. Formely I merged the two files
manually, but now I use my home-cooked 'dpkg-cross' package. The
dpkg-buildpackage wrapper in there merges the newly generated
*.changes with an existing one for the same package/version, and
re-signs it. But maybe I'm the only one using dpkg-cross... :-)

> Note that there's actually a bigger problem lurking out there... our
> model assumes that we have one set of sources that compile for all
> architectures, and this is clearly the right goal. However, I
> suspect that only in the stable released tree is it ever likely that
> we can achieve total syncronization of the revisions of all the
> packages across all the architectures.

You're right. Most of the time, not all binary versions for all archs
will be at the same level as the source.

> So, one thought is should this becomes one of the goals during the
> freeze process, and a release criteria for a stable release? The
> other side of this is that in unstable, we ought to think about
> whether it's ok to only have the "latest" source packages around, or
> whether we need some way to keep multiple source revisions around to
> have the sources matching all the binary packages.

Maybe needs too much space :-( This could blow up the source
directories by factor 3 or 4 ...

And having all binaries up-to-date in stable is maybe a problem with
resources (people compiling packages), but is desireable.

> Further, common practice with the alpha port right now is to patch
> the sources as needed to build the binary package, release the
> binary package with the same rev number, and submit the patch as a
> bug report against the package. This means that since we don't have
> support for architecture-specific diffs in our upload process, the
> only binary package that is guaranteed to match the sources at a
> given revision is the binary package for the primary platform of the
> maintainer of that package. I suppose we *could* do full
> non-maintainer uploads, but this would just make more overhead for
> everyone. Anyone have any strong opinions about how we should be
> doing this?

The easy thing would be to send the patches to the maintainer, wait
for the new source version, and then build the binary package... But
this could obviously be a bit slow :-( I'd suggest non-maintainer
uploads in urgent cases, and the slow procedure above for the rest.
Non-maintainer uploads can easily disturb the work of the real
maintainer, so they should be avoided as far as possible. But,
admitted, this is not really satisfying... 

Roman


Reply to: