Re: Bug#683751: gettext: Please mark gettext M-A: allowed
On Fri, Nov 23, 2012 at 01:31:45PM +0100, Santiago Vila wrote:
> On Fri, 23 Nov 2012, Colin Watson wrote:
> >It also occurred to me that gettext should depend on libasprintf-dev and
> >libgettextpo-dev, otherwise anything that Build-Depends on gettext
> >expecting to be able to use one of those libraries will immediately
> >FTBFS. Perhaps it will be possible to get rid of this dependency later
> >after a migration period, as in some ways it's a bit odd for gettext to
> >suck in development libraries.
>
> I also thought about that, but the names of the new packages have been in
> gettext Provides for a long time, which means any package which fails to build
> properly because of this split was already buggy in the first place.
>
> Moreover, somebody in this same thread, if I remember will, did a check
> and found that there were no packages affected, so my preference would be
> to not add those Depends if they are not necessary for our own packages.
OK, makes sense.
Looking back through the thread: do you still want to remove
libgettextlib.so and libgettextsrc.so? The most recent version of
Wookey's patch removed those; I restored them in my revision, thinking
that a mistake, but I just noticed discussion earlier in this bug to the
effect that those symlinks should be removed since the libraries are
only for internal use by gettext, so I may have been wrong to restore
these symlinks.
> >I've confirmed that these -dev packages are multiarch-coinstallable,
> >which is good. There is one remaining niggle here: while
> >/usr/share/info/autosprintf.info.gz is currently identical across
> >architectures, it starts with a line containing "produced by makeinfo
> >version 4.13". That means that if gettext ever happens to be built when
> >texinfo is at different upstream versions on different architectures,
> >the results will not be multiarch-coinstallable. I think this is a bit
> >of a timebomb and we should avoid it. Perhaps it would make sense to
> >leave that info documentation in the gettext package, and add a
> >"Suggests: gettext" in libasprintf-dev? (We could move it to
> >gettext-doc instead, but that seems like fairly pointless
> >deckchair-rearrangement to me.)
Do you have an opinion on this part? If not, I think my default would
be for the next version of this patch to move autosprintf.info.gz back
to gettext, for safety.
> >I'd like to get this into Ubuntu as soon as possible to replace our
> >current "Multi-Arch: allowed" hack in sufficient time to undo all the
> >build-dependencies we've accumulated on "gettext:any". Do you think it
> >might be possible to have this patch applied in experimental, or should
> >we apply it ourselves once we've agreed on package names and contents?
>
> Perhaps we should probably do the split in Debian unstable, as
> multiarch is a release goal for wheezy. Are splits already forbidden
> in unstable?
Well, on the one hand, multiarch is a release goal, but it can't
realistically be an open-ended one - we have to stop somewhere. It's
not as if there aren't plenty of other cross-building issues. On the
other hand, it's true that this particular piece of it is more important
than your average multiarch fix since it blocks cross-building of many
other packages, and I don't actually think it's all that invasive.
http://release.debian.org/wheezy/freeze_policy.html allows "changes for
release goals, if they are not invasive". I think we would need to ask
the release team for their opinion here; CCing debian-release.
(Background for those not following this long bug: we would like to
split libasprintf-dev and libgettextpo-dev out of gettext, in order to
permit marking gettext as Multi-Arch: foreign, the lack of which blocks
500-odd potentially cross-buildable packages and considerably obscures
our view of how much of even the core of Debian is cross-buildable. The
earlier proposal reflected in the bug title was to leave these in the
one package and use "Multi-Arch: allowed", but that involves changing
lots of build-dependencies to "gettext:any" and I think everyone
involved is now agreed that this is a less desirable option.)
Thanks,
--
Colin Watson [cjwatson@ubuntu.com]
Reply to: