Re: Upstream sources in future uploads of gnat-4.8
Am 02.06.2013 12:06, schrieb Ludovic Brenta:
> Hello,
>
> I have decided to include the upstream sources in future uploads of
> gnat-4.8, staring with 4.8.1-1 in a couple of weeks (if all goes well).
> Merging gnat-4.8 into the gcc-4.8 source package is also an option but I
> prefer to keep the two separate because I have too little time available
> for Debian to keep up with the rapid pace of uploads of gcc-x.y
why would that be a problem? gnat usually gets not broken with updates from the
branches, and the packaging for 4.8 should be fairly stable now.
> and because subversion, where the Debian packaging is kept, is not well
> equipped to handle parallel branches of development especially merging.
well, monotone isn't an option for me either.
> It occurred to me that maybe the best thing to do would be to turn
> gnat-4.8 into a proper 3.0 (quilt) source package where the .orig.tar.gz
> would contain the already-unpacked upstream sources (i.e. not a tarball
> inside a tarball) and the debian/patches/series file would be maintained
> directly unser source control, rather than generated by "debian/rules
> patch".
>
> I understand that generating debian/patches/series is currently
> necessary to distinguish between native and cross-compilers. I think it
> would be acceptable to have a "fixed" set of patches in
> debian/patches/series plus a "variable" set of patches, applied on top
> of the "fixed" set, for cross-compilers. The "fixed" set would be
> applied directly by dpkg-source and the "variable" set would be
> constructed & applied later by debian/rules patch. What do you think of
> this? (The contents of debian/patches/series should not depend on the
> language front-ends being compiled, either).
>
> Ideally we could get rid of "debian/rules unpack" entirely and simplify
> the code base of Debian packaging. The fixed set of patches,
> i.e. debian/patches/series, would also simplify debian/rules.patch quite
> a bit.
well, ideally the patches should be written to be applied unconditionally. So a
good idea would be to start with the Ada patches ;-)
- #671368 is such a candidate, showing that your patches blindly
assume zcx exception support, which isn't available on some archs.
- I didn't check if ada-nobiarch-check is still necessary.
and I bunch of patches really should be forwarded upstream. Why are the kFreeBSD
and Hurd patches not upstream?
Same for the ada-libgnatvsn and ada-libgnatprj patches. Was there an attempt
made to get these into upstream, or do we have to carry these forever? These are
usually the ones which require the most work when updating to a new major release.
> Ideas, objections?
well, maybe not for 4.8, but definitely for 4.9 I would like to get rid of the
extra patches to add support for a language in the driver, which is not built.
So then you won't have the option anymore to get ada files processed with the
gcc driver.
So to summarize a patch is applied conditionally,
- if it's written too lazy. Most of the patches fall into that category.
- if it touches GFDL documentation with cover texts. I do want to have
these patches still in the archive.
- patches which are only applied for one architecture. Currently
aarch64 is built from the linaro branch in 4.8, and I don't want to
build every architecture from that branch.
- if a patch comes in late during the release cycle, isn't found
upstream, etc. See for some m68k patches in 4.6.
So please start fixing the ada patches to be applied unconditionally or get them
forwarded and accepted upstream. Feel free to start working on the other
patches too.
Matthias
Reply to: