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 [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
