On Fri, 17 Dec 2010 14:45:06 +0100, Matthias Klose <doko@debian.org> wrote:
> On 11.12.2010 17:40, Stephen Kitt wrote:
> > I imagine this could mean that the gcj and gnats builds don't use the
> > patches in the gcc-4.x-source package, and only use the tarball which
> > won't change from one Debian version to another (e.g. 4.5.1-1 to 4.5.1-2
> > etc.)...
>
> yes.
>
> > That
> > seems a shame to me since the patches are useful, and it still leaves the
> > problem of having a package build using gcc-4.5-source 4.5-1 for example,
> > and then gcc-4.5-source being replaced with version 4.5.1-1 with a new
> > tarball.
>
> no, the tarball doesn't change. it's in the .orig.tar.gz. all other
> patches/packging are synced with the gcc-4.5 package. Nothing is lost, all
> patches are applied.
I must be misunderstanding something here then:
% dpkg-deb -c gcc-4.5-source_4.5.0-10_all.deb|grep tar
-rw-r--r-- root/root 52023076 2010-04-14 13:56 ./usr/src/gcc-4.5/gcc-4.5.0-dfsg.tar.xz
% dpkg-deb -c gcc-4.5-source_4.5.1-1_all.deb|grep tar
-rw-r--r-- root/root 52073572 2010-07-31 16:20 ./usr/src/gcc-4.5/gcc-4.5.1-dfsg.tar.xz
% dpkg-deb -c gcc-4.5-source_4.5.1-12_all.deb|grep tar
-rw-r--r-- root/root 52073572 2010-07-31 16:20 ./usr/src/gcc-4.5/gcc-4.5.1-dfsg.tar.xz
% dpkg-deb -c gcc-4.5-source_4.5.2-1_all.deb|grep tar
-rw-r--r-- root/root 52182428 2010-12-18 13:38 ./usr/src/gcc-4.5/gcc-4.5.2-dfsg.tar.xz
Surely depending on when something build-depending on gcc-4.5-source is
built, it might be built using gcc-4.5.0-dfsg.tar.xz, but not necessarily
rebuilt with one of the later tarballs? Once gcc-4.5-source_4.5.1-1_all.deb
is uploaded and gcc-4.5-source_4.5.0-10_all.deb disappears from the archive,
it would require a binNMU at least to make sure the depending packages use
the source available in Debian, wouldn't it?
> > The other solution based on Marcin's work, which is also readily
> > supported by the existing -source packages, requires that the target
> > architecture be understood by dpkg (as pointed out by Dmitrijs); that may
> > be a worthwhile goal, notably since it solves the problem of how to
> > provide build packages for the various libraries people find useful, but
> > it's a much longer-term goal as far as I can see...
>
> otoh, this approach breaks more often with updates on patches and
> packaging. Manageable however.
Yup, as long as the downstream maintainers are on the ball, it should be OK!
The nice thing for you of course is that it means the gcc packaging gets even
more tests.
Regards,
Stephen