Bug#683751: gettext: Please mark gettext M-A: allowed
On Wed, Nov 28, 2012 at 05:50:38PM +0100, Santiago Vila wrote: > After careful testing of the patches, I've just uploaded gettext_0.18.1.1-10 > for unstable (with only minor changes), as I consider this split is > simple enough that it will hardly be disruptive for autobuilders. Fantastic - thank you very much! > This will likely not be accepted for wheezy, but in case we try to > convince release managers about it, I've postponed two of the changes > that we discussed: > > - Dropping Depends on the new -dev packages. > - Dropping libgettextsrc.so and libgettextlib.so. > > If you want to do them in Ubuntu, feel free. If you don't want to > deviate from Debian, those changes will be done in either case > shortly after the release of wheezy as stable. I can't think of a way that either of these changes would affect cross-building, so they don't seem pressing enough to merit divergence. Cheers, -- 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
Bug#683751: gettext: Please mark gettext M-A: allowed
Colin, Wookey: After careful testing of the patches, I've just uploaded gettext_0.18.1.1-10 for unstable (with only minor changes), as I consider this split is simple enough that it will hardly be disruptive for autobuilders. This will likely not be accepted for wheezy, but in case we try to convince release managers about it, I've postponed two of the changes that we discussed: - Dropping Depends on the new -dev packages. - Dropping libgettextsrc.so and libgettextlib.so. If you want to do them in Ubuntu, feel free. If you don't want to deviate from Debian, those changes will be done in either case shortly after the release of wheezy as stable. Thanks a lot for your help! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
On Fri, Nov 23, 2012 at 09:23:14PM +0100, Julien Cristau wrote: > On Fri, Nov 23, 2012 at 13:31:12 +, Colin Watson wrote: > > 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. > > Sounds like something for jessie, IMO. Fair enough. In that case it would be lovely to have something in experimental so that we can, well, experiment with it. 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
Bug#683751: gettext: Please mark gettext M-A: allowed
On Fri, Nov 23, 2012 at 13:31:12 +, Colin Watson wrote: > 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. > Sounds like something for jessie, IMO. Cheers, Julien signature.asc Description: Digital signature
Bug#683751: gettext: Please mark gettext M-A: allowed
On Fri, Nov 23, 2012 at 02:22:25PM +, Wookey wrote: > +++ Colin Watson [2012-11-23 13:31 +]: > > 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. > > Doesn't this problem of potentially-rebuilt text/doc/info files exist > all over the place? Not that widely. The bulk of documentation in M-A: same packages, as far as I've seen so far, is just static files, which are just fine. > I've come across it in perl docs which embed the build date, not the > doc-creation date, for example. Those clearly must not be in M-A: same packages because they will rarely if ever manage to be identical. That's a different issue from cases like this, which will generally be identical across architectures but where we might occasionally be unlucky. > Essentially any doc in an M-A same package has the issue of rebuilds > potentially changing the text. i.e. there is nothing special about > gettext here. Is texinfo version skew likely enough to break things > that we should worry. I don't like leaving timebombs around behind me. It seems like the kind of thing that my future self would be likely to curse me for doing. > One way of dealing with this is moving all docs out of M-A: same > packages, and docs are arch-independent stuff so it makes some sense. That would be drastic overkill, since many documentation files are obviously invariant across architectures. We already have a clear rule that says that things that vary across architectures must not be in M-A: same packages. This is only a difficult situation because it will only vary if we get unlucky (although it's a predictable kind of bad luck, rather than cosmic rays); but we don't need to generalise the problem further than necessary. > What we really want is QA checks on MA co-installability and > corresponding rebuilds/fixes where it's gone wrong. We should certainly have this, but I don't think it absolves us from trying to insure against predictable problems up-front. -- 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
Bug#683751: gettext: Please mark gettext M-A: allowed
+++ Colin Watson [2012-11-23 13:31 +]: > On Fri, Nov 23, 2012 at 01:31:45PM +0100, Santiago Vila wrote: > > On Fri, 23 Nov 2012, Colin Watson wrote: > > >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. Doesn't this problem of potentially-rebuilt text/doc/info files exist all over the place? I've come across it in perl docs which embed the build date, not the doc-creation date, for example. Essentially any doc in an M-A same package has the issue of rebuilds potentially changing the text. i.e. there is nothing special about gettext here. Is texinfo version skew likely enough to break things that we should worry. One way of dealing with this is moving all docs out of M-A: same packages, and docs are arch-independent stuff so it makes some sense. But it's also good to keep docs in their most relevant place. I don't know which package is really 'most relevant' here. What we really want is QA checks on MA co-installability and corresponding rebuilds/fixes where it's gone wrong. I'm happy to rely on that happening in due course, if it would be better the leave the docs in the -dev package. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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 [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
Bug#683751: gettext: Please mark gettext M-A: allowed
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. 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.) 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? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
On Wed, Nov 21, 2012 at 09:15:51PM +0100, Santiago Vila wrote:
> El 21/11/12 18:31, Colin Watson escribió:
> >I would say that only things tightly associated with libasprintf and
> >libgettextpo - so autosprintf.h / gettext-po.h respectively plus the
> >corresponding .a/.so - should go in the -dev package.
> >
> >Everything else (and in particular everything under /usr/share/aclocal/
> >and /usr/share/gettext/) should stay exactly where it is, in the main
> >gettext package; it's generally only intended for being copied into
> >people's source packages by various tools.
>
> Yes, that's what I believe as well.
Wookey sent me a new version of his patch earlier today, and I tweaked
it some more; I put /usr/share/aclocal/ back, as well as
libgettextsrc.so and libgettextlib.so. I restored the version to
0.18.1.1-10 so that it matches the Breaks/Replaces.
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 dropped the Provides in gettext as they clearly no longer belong
there.
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.)
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?
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
diff -Nru gettext-0.18.1.1/debian/changelog gettext-0.18.1.1/debian/changelog
--- gettext-0.18.1.1/debian/changelog 2012-06-07 11:08:07.0 +0100
+++ gettext-0.18.1.1/debian/changelog 2012-11-22 17:58:40.0 +
@@ -1,3 +1,11 @@
+gettext (0.18.1.1-10) UNRELEASED; urgency=low
+
+ * Split out libgettextpo-dev and libasprintf-dev for multiarch
+dependencies. Thanks to P.J McDermott for core patch. (Closes: #683751)
+ * Fix FTBFS on eglibc-2.16 (due to gets removal/outdated gnulib)
+
+ -- Wookey Thu, 15 Nov 2012 17:04:09 +
+
gettext (0.18.1.1-9) unstable; urgency=low
* Build with hardened build flags.
diff -Nru gettext-0.18.1.1/debian/control gettext-0.18.1.1/debian/control
--- gettext-0.18.1.1/debian/control 2012-06-07 11:00:00.0 +0100
+++ gettext-0.18.1.1/debian/control 2012-11-23 02:01:18.0 +
@@ -17,11 +17,11 @@
Package: gettext
Architecture: any
-Depends: ${shlibs:Depends}, libgettextpo0 (= ${binary:Version}), libasprintf0c2 (= ${binary:Version}), gettext-base, dpkg (>= 1.15.4) | install-info
+Multi-Arch: foreign
+Depends: ${shlibs:Depends}, gettext-base, dpkg (>= 1.15.4) | install-info, libasprintf-dev, libgettextpo-dev
Recommends: curl | wget | lynx-cur, autopoint
Breaks: autopoint (<= 0.17-11)
Suggests: gettext-doc
-Provides: libasprintf-dev, libgettextpo-dev
Description: GNU Internationalization utilities
Interesting for authors or maintainers of other packages or programs
which they want to see internationalized.
@@ -81,3 +81,25 @@
This package contains the libasprintf shared library which makes the
C formatted output routines (fprintf et al.) usable in C++ programs,
for use with the strings and the streams.
+
+Package: libgettextpo-dev
+Section: libdevel
+Architecture: any
+Multi-Arch: same
+Depends: libgettextpo0 (= ${binary:Version})
+Suggests: gettext-doc
+Breaks: gettext (<< 0.18.1.1-10)
+Replaces: gettext (<< 0.18.1.1-10)
+Description: GNU Internationalization library development files
+ This package contains development files for the libgettextpo library.
+
+Package: libasprintf-dev
+Section: libdevel
+Architecture: any
+Multi-Arch: same
+Depends: libasprintf0c2 (= ${binary:Version}), dpkg (>= 1.15.4) | install-info
+Suggests: gettext-doc
+Breaks: gettext (<< 0.18.1.1-10)
+Replaces: gettext (<< 0.18.1.1-10)
+Description: GNU Internationalization library development files
+ This package contains development files for the libasprintf library.
d
Bug#683751: gettext: Please mark gettext M-A: allowed
El 21/11/12 18:31, Colin Watson escribió: I would say that only things tightly associated with libasprintf and libgettextpo - so autosprintf.h / gettext-po.h respectively plus the corresponding .a/.so - should go in the -dev package. Everything else (and in particular everything under /usr/share/aclocal/ and /usr/share/gettext/) should stay exactly where it is, in the main gettext package; it's generally only intended for being copied into people's source packages by various tools. Yes, that's what I believe as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
On Wed, Nov 21, 2012 at 05:00:08PM +, Wookey wrote:
> +++ Colin Watson [2012-11-21 12:57 +]:
> > On Sun, Nov 18, 2012 at 03:08:35AM +, Wookey wrote:
> > > +Package: libgettextpo-dev
> > > +Section: libdevel
> > > +Architecture: any
> > > +Multi-Arch: same
> > > +Depends: libgettextpo0 (= ${binary:Version})
> > > +Suggests: gettext-doc
> > > +Description: GNU Internationalization library development files
> > > + This package contains development files for the libgettextpo library.
> >
> > This needs "Replaces: gettext (<< 0.18.1.1-10)", as it includes files
> > previously in gettext.
>
> good point.
It occurred to me that policy says you want a corresponding Breaks as
well. Sorry for not mentioning that before.
> > Also, the file lists of libgettextpo-dev and libasprintf-dev both look
> > rather wrong. Both of them contain both /usr/include/gettext-po.h and
> > /usr/include/autosprintf.h, but they ought to have one of those each.
> > libgettextpo-dev contains lots of stuff in /usr/share/gettext/, while
> > libasprintf-dev contains lots of stuff in /usr/share/aclocal/, and
> > neither looks right - surely these directories still belong in the
> > gettext package?
>
> This patch was 90% guesswork as I don't know what _any_ of the
> files/binaries in gettext actually do which greatly limited how much
> expertise I could apply to the problem.
>
> All that seems reasonable to me, but then almost anything would. Which
> package should /usr/share/gettext/intl live in? They looked like
> headers so I put them in the -dev package. But there is .c in there
> too. OK some reading online says that these are stuff done by
> gettextize and do not seem arch-dependent so should indeed be in
> gettext main package.
Right.
> Like I say, having no idea how this package
> works, or what the parts do, limits my ability to make intelligent
> choices.
I would say that only things tightly associated with libasprintf and
libgettextpo - so autosprintf.h / gettext-po.h respectively plus the
corresponding .a/.so - should go in the -dev package.
Everything else (and in particular everything under /usr/share/aclocal/
and /usr/share/gettext/) should stay exactly where it is, in the main
gettext package; it's generally only intended for being copied into
people's source packages by various tools.
> Cheers for checking my shoddy work - I was hoping that sending in a
> patch would prompt someone to comment on how broken it was :-)
Traditional Internet approach :-)
--
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
Bug#683751: gettext: Please mark gettext M-A: allowed
+++ Colin Watson [2012-11-21 12:57 +]:
> On Sun, Nov 18, 2012 at 03:08:35AM +, Wookey wrote:
> > OK. As I was getting very bored of marking Build-deps 'gettext:any' in
> > Ubuntu (and they'd all have to be changed back eventually anyway),
> > I've done the work to extend PJs patch to split into two libraries.
> > Not yet very carefully checked or tested, but it looks OK.
>
> > +Package: libgettextpo-dev
> > +Section: libdevel
> > +Architecture: any
> > +Multi-Arch: same
> > +Depends: libgettextpo0 (= ${binary:Version})
> > +Suggests: gettext-doc
> > +Description: GNU Internationalization library development files
> > + This package contains development files for the libgettextpo library.
>
> This needs "Replaces: gettext (<< 0.18.1.1-10)", as it includes files
> previously in gettext.
good point.
> > +Package: libasprintf-dev
> > +Section: libdevel
> > +Architecture: any
> > +Multi-Arch: same
> > +Depends: libasprintf0c2 (= ${binary:Version})
> > +Suggests: gettext-doc
> > +Description: GNU Internationalization library development files
> > + This package contains development files for the libasprintf library.
>
> Ditto. Also, this needs the same "Depends: dpkg (>= 1.15.4) |
> install-info" as gettext, since one of the info files now lives in
> libasprintf-dev.
Ah yes. Thought I checked that, but clearly not.
> Also, the file lists of libgettextpo-dev and libasprintf-dev both look
> rather wrong. Both of them contain both /usr/include/gettext-po.h and
> /usr/include/autosprintf.h, but they ought to have one of those each.
> libgettextpo-dev contains lots of stuff in /usr/share/gettext/, while
> libasprintf-dev contains lots of stuff in /usr/share/aclocal/, and
> neither looks right - surely these directories still belong in the
> gettext package?
This patch was 90% guesswork as I don't know what _any_ of the
files/binaries in gettext actually do which greatly limited how much
expertise I could apply to the problem.
All that seems reasonable to me, but then almost anything would. Which
package should /usr/share/gettext/intl live in? They looked like
headers so I put them in the -dev package. But there is .c in there
too. OK some reading online says that these are stuff done by
gettextize and do not seem arch-dependent so should indeed be in
gettext main package.
Like I say, having no idea how this package
works, or what the parts do, limits my ability to make intelligent
choices. Santiago? Is this right? Tell me what should go where and
I'll send the patches.
Cheers for checking my shoddy work - I was hoping that sending in a
patch would prompt someone to comment on how broken it was :-)
Here's an update with all that fixed. I'm about to try it and see if
it works
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
diff -Nru gettext-0.18.1.1/debian/changelog gettext-0.18.1.1/debian/changelog
--- gettext-0.18.1.1/debian/changelog 2012-06-07 10:08:07.0 +
+++ gettext-0.18.1.1/debian/changelog 2012-11-18 03:10:37.0 +
@@ -1,3 +1,11 @@
+gettext (0.18.1.1-9multiarch1) unstable; urgency=low
+
+ * Split out libgettextpo-dev and libasprintf-dev for multiarch
+dependencies. Thanks to P.J McDermott for core patch. (Closes: #683751)
+ * Fix FTBFS on eglibc-2.16 (due to gets removal/outdated gnulib)
+
+ -- Wookey Thu, 15 Nov 2012 17:04:09 +
+
gettext (0.18.1.1-9) unstable; urgency=low
* Build with hardened build flags.
diff -Nru gettext-0.18.1.1/debian/control gettext-0.18.1.1/debian/control
--- gettext-0.18.1.1/debian/control 2012-06-07 10:00:00.0 +
+++ gettext-0.18.1.1/debian/control 2012-11-21 15:16:46.0 +
@@ -17,7 +17,8 @@
Package: gettext
Architecture: any
-Depends: ${shlibs:Depends}, libgettextpo0 (= ${binary:Version}), libasprintf0c2 (= ${binary:Version}), gettext-base, dpkg (>= 1.15.4) | install-info
+Multi-Arch: foreign
+Depends: ${shlibs:Depends}, gettext-base, dpkg (>= 1.15.4) | install-info
Recommends: curl | wget | lynx-cur, autopoint
Breaks: autopoint (<= 0.17-11)
Suggests: gettext-doc
@@ -81,3 +82,23 @@
This package contains the libasprintf shared library which makes the
C formatted output routines (fprintf et al.) usable in C++ programs,
for use with the strings and the streams.
+
+Package: libgettextpo-dev
+Section: libdevel
+Architecture: any
+Multi-Arch: same
+Depends: libgettextpo0 (= ${binary:Version})
+Suggests: gettext-doc
+Replaces: gettext (<< 0.18.1.1-10)
+Description: GNU Internationalization library development files
+ This package contains development files for the libgettextpo library.
+
+Package: libasprintf-dev
+Section: libdevel
+Architecture: any
+Multi-Arch: same
+Depends: libasprintf0c2 (= ${binary:Version}), dpkg (>= 1.15.4) | install-info
+Suggests: gettext-doc
+Replaces: gettext (<< 0.18.1.1-10)
+Description: GNU Internationalization library development files
+ This package contains development files for the libasprintf library.
diff
Bug#683751: gettext: Please mark gettext M-A: allowed
On Sun, Nov 18, 2012 at 03:08:35AM +, Wookey wrote:
> OK. As I was getting very bored of marking Build-deps 'gettext:any' in
> Ubuntu (and they'd all have to be changed back eventually anyway),
> I've done the work to extend PJs patch to split into two libraries.
> Not yet very carefully checked or tested, but it looks OK.
> +Package: libgettextpo-dev
> +Section: libdevel
> +Architecture: any
> +Multi-Arch: same
> +Depends: libgettextpo0 (= ${binary:Version})
> +Suggests: gettext-doc
> +Description: GNU Internationalization library development files
> + This package contains development files for the libgettextpo library.
This needs "Replaces: gettext (<< 0.18.1.1-10)", as it includes files
previously in gettext.
> +Package: libasprintf-dev
> +Section: libdevel
> +Architecture: any
> +Multi-Arch: same
> +Depends: libasprintf0c2 (= ${binary:Version})
> +Suggests: gettext-doc
> +Description: GNU Internationalization library development files
> + This package contains development files for the libasprintf library.
Ditto. Also, this needs the same "Depends: dpkg (>= 1.15.4) |
install-info" as gettext, since one of the info files now lives in
libasprintf-dev.
Also, the file lists of libgettextpo-dev and libasprintf-dev both look
rather wrong. Both of them contain both /usr/include/gettext-po.h and
/usr/include/autosprintf.h, but they ought to have one of those each.
libgettextpo-dev contains lots of stuff in /usr/share/gettext/, while
libasprintf-dev contains lots of stuff in /usr/share/aclocal/, and
neither looks right - surely these directories still belong in the
gettext package?
--
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
Bug#683751: gettext: Please mark gettext M-A: allowed
+++ Santiago Vila [2012-09-24 18:22 +0200]:
> On Mon, 24 Sep 2012, Wookey wrote:
>
> >Santiago, have you reached an opinion on whether you'd prefer to
> >1) split the gettext package into an MA:same libgettext-dev part and
> >an MA:foreign gettext part (and change corresponding dependencies), or
> >2) mark it MA:allowed and change all the dependencies that only need the
> >build-tool part to 'gettext:any' ?
>
> I think splitting is probably the best option here, following Steve's advice:
>
> Steve Langasek wrote:
> >You could split the packages and put the issue to bed once and for all
>
>
> The thing I don't like about the proposed patch is that it creates
> a single new package which is really the combination of two
> different -dev packages.
>
> So my plan would be to split it "the right way", by creating two
> additional packages: libasprintf-dev and libgettextpo-dev.
>
> We would then drop the "Provides:" in gettext, we would not have
> to add them anywhere, and it would be clear that those names
> are the right ones to be put in a build-depends.
OK. As I was getting very bored of marking Build-deps 'gettext:any' in
Ubuntu (and they'd all have to be changed back eventually anyway),
I've done the work to extend PJs patch to split into two libraries.
Not yet very carefully checked or tested, but it looks OK.
This patch also include the eglibc-2.16 fix from #693361
I can do one without that if you prefer.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
diff -Nru gettext-0.18.1.1/debian/changelog gettext-0.18.1.1/debian/changelog
--- gettext-0.18.1.1/debian/changelog 2012-06-07 10:08:07.0 +
+++ gettext-0.18.1.1/debian/changelog 2012-11-15 18:44:38.0 +
@@ -1,3 +1,11 @@
+gettext (0.18.1.1-10) precise; urgency=low
+
+ * Split out libgettextpo-dev and libasprintf-dev for multiarch
+dependencies. Thanks to P.J McDermott for core patch. (Closes: #683751)
+ * Fix FTBFS on eglibc-2.16 (due to gets removal/outdated gnulib)
+
+ -- Wookey Thu, 15 Nov 2012 17:04:09 +
+
gettext (0.18.1.1-9) unstable; urgency=low
* Build with hardened build flags.
diff -Nru gettext-0.18.1.1/debian/control gettext-0.18.1.1/debian/control
--- gettext-0.18.1.1/debian/control 2012-06-07 10:00:00.0 +
+++ gettext-0.18.1.1/debian/control 2012-11-15 17:36:27.0 +
@@ -17,7 +17,8 @@
Package: gettext
Architecture: any
-Depends: ${shlibs:Depends}, libgettextpo0 (= ${binary:Version}), libasprintf0c2 (= ${binary:Version}), gettext-base, dpkg (>= 1.15.4) | install-info
+Multi-Arch: foreign
+Depends: ${shlibs:Depends}, gettext-base, dpkg (>= 1.15.4) | install-info
Recommends: curl | wget | lynx-cur, autopoint
Breaks: autopoint (<= 0.17-11)
Suggests: gettext-doc
@@ -81,3 +82,21 @@
This package contains the libasprintf shared library which makes the
C formatted output routines (fprintf et al.) usable in C++ programs,
for use with the strings and the streams.
+
+Package: libgettextpo-dev
+Section: libdevel
+Architecture: any
+Multi-Arch: same
+Depends: libgettextpo0 (= ${binary:Version})
+Suggests: gettext-doc
+Description: GNU Internationalization library development files
+ This package contains development files for the libgettextpo library.
+
+Package: libasprintf-dev
+Section: libdevel
+Architecture: any
+Multi-Arch: same
+Depends: libasprintf0c2 (= ${binary:Version})
+Suggests: gettext-doc
+Description: GNU Internationalization library development files
+ This package contains development files for the libasprintf library.
diff -Nru gettext-0.18.1.1/debian/gettext.lintian-overrides gettext-0.18.1.1/debian/gettext.lintian-overrides
--- gettext-0.18.1.1/debian/gettext.lintian-overrides 2012-04-28 14:45:44.0 +
+++ gettext-0.18.1.1/debian/gettext.lintian-overrides 2012-11-15 17:27:18.0 +
@@ -5,10 +5,6 @@
gettext: ldconfig-symlink-missing-for-shlib usr/lib/libgnuintl.so.8 usr/lib/preloadable_libintl.so libgnuintl.so.8
gettext: shlib-missing-in-control-file libgnuintl 8 for usr/lib/preloadable_libintl.so
#
-# gettext Provides libgettextpo-dev, so yes, it is a dev-pkg.
-#
-gettext: non-dev-pkg-with-shlib-symlink usr/lib/libgettextpo.so.0.5.1 usr/lib/libgettextpo.so
-#
# These libraries are for internal use only and should not be used by
# other programs.
#
@@ -21,3 +17,4 @@
gettext: no-shlibs-control-file usr/lib/preloadable_libintl.so
gettext: no-shlibs-control-file usr/lib/libgettextsrc-0.18.1.so
gettext: no-shlibs-control-file usr/lib/libgettextlib-0.18.1.so
+gettext: shlib-in-multi-arch-foreign-package usr/lib/preloadable_libintl.so
\ No newline at end of file
diff -Nru gettext-0.18.1.1/debian/patches/eglibc-21.6-ftbfs-nogets gettext-0.18.1.1/debian/patches/eglibc-21.6-ftbfs-nogets
--- gettext-0.18.1.1/debian/patches/eglibc-21.6-ftbfs-nogets 1970-01-01 00:00:00.0 +
+++ gettext-0.18.1.1/debian/patches/eglibc-21.6-ftbfs-nogets 2012-11-15 19:14:59.0 +
@@ -0,0 +1,
Bug#683751: gettext: Please mark gettext M-A: allowed
On Mon, 24 Sep 2012, Wookey wrote: Santiago, have you reached an opinion on whether you'd prefer to 1) split the gettext package into an MA:same libgettext-dev part and an MA:foreign gettext part (and change corresponding dependencies), or 2) mark it MA:allowed and change all the dependencies that only need the build-tool part to 'gettext:any' ? I think splitting is probably the best option here, following Steve's advice: Steve Langasek wrote: You could split the packages and put the issue to bed once and for all The thing I don't like about the proposed patch is that it creates a single new package which is really the combination of two different -dev packages. So my plan would be to split it "the right way", by creating two additional packages: libasprintf-dev and libgettextpo-dev. We would then drop the "Provides:" in gettext, we would not have to add them anywhere, and it would be clear that those names are the right ones to be put in a build-depends. [ This is what I had in mind, but since we are in a freeze I had this issue postponed. Sorry for the late reply ]. Does this help? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
Santiago, have you reached an opinion on whether you'd prefer to 1) split the gettext package into an MA:same libgettext-dev part and an MA:foreign gettext part (and change corresponding dependencies), or 2) mark it MA:allowed and change all the dependencies that only need the build-tool part to 'gettext:any' ? Ubuntu is currently doing the latter, but as there are many such depending packages (521 in unstable), if we are going to do the (arguably more correct) package split in Debian, then it makes sense not to go crazy uploading hundreds of changes to Ubuntu which will later need to be reverted. I don't (yet) have strong opinions on this, but would like to know which way we are headed, or what more research is needed in order to decide that so that I can head in that direction too, rather than the opposite one. Do you in fact need someone to test out pj's patch against some builds to see if it is indeed a good solution? Direction, or requests for help, are welcome. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
tags 683751 + patch
thanks
On 2012-08-14 17:05, Steve Langasek wrote:
> On Tue, Aug 14, 2012 at 10:52:38PM +0200, Santiago Vila wrote:
>> Now the question: Do libasprintf-dev and libgettextpo-dev really need
>> to be in a different package than gettext?
>
> I think that depends on whether there's ever a need to build against host
> and build versions of these libraries in a single build. I don't know the
> answer to that; we probably won't discover the answer for a while, until
> someone working on cross-compiling the distro runs into one that does.
>
> You could split the packages and put the issue to bed once and for all, or
> just use Multi-Arch: allowed for now and wait for complaints :)
I split out a libgettext-dev package that provides libasprintf-dev and
libgettextpo-dev. I also removed the unversioned libgettextlib.so and
libgettextsrc.so symbolic links.
I hope I've correctly split the /usr/share hierarchy between gettext and
libgettext-dev. Please let me know if something is wrong.
I've tested that src:gettext correctly builds [1] with this patch, but
I've not yet tried building other software against the resulting packages.
[1]:
http://bootstrap.pehjota.net/cross/builds/gettext/gettext_0.18.1.1-9.1_i386-20120816-2130.build
--
P. J. McDermott(_/@\_),--.
http://www.pehjota.net/ o< o o > / oo \
http://www.pehjota.net/contact.html o \ `-/| <> |.
o o o"~v/_\--/_/
diff -Nru gettext-0.18.1.1/debian/changelog gettext-0.18.1.1/debian/changelog
--- gettext-0.18.1.1/debian/changelog 2012-06-07 06:08:07.0 -0400
+++ gettext-0.18.1.1/debian/changelog 2012-08-16 21:26:05.0 -0400
@@ -1,3 +1,11 @@
+gettext (0.18.1.1-9.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Split out libgettext-dev for multiarch. Closes: #683751.
+ * Remove unversioned symlinks to internal libraries.
+
+ -- "P. J. McDermott" Thu, 16 Aug 2012 16:59:59 -0400
+
gettext (0.18.1.1-9) unstable; urgency=low
* Build with hardened build flags.
diff -Nru gettext-0.18.1.1/debian/control gettext-0.18.1.1/debian/control
--- gettext-0.18.1.1/debian/control 2012-06-07 06:00:00.0 -0400
+++ gettext-0.18.1.1/debian/control 2012-08-16 20:49:57.0 -0400
@@ -17,11 +17,11 @@
Package: gettext
Architecture: any
-Depends: ${shlibs:Depends}, libgettextpo0 (= ${binary:Version}),
libasprintf0c2 (= ${binary:Version}), gettext-base, dpkg (>= 1.15.4) |
install-info
+Multi-Arch: foreign
+Depends: ${shlibs:Depends}, gettext-base, dpkg (>= 1.15.4) | install-info
Recommends: curl | wget | lynx-cur, autopoint
Breaks: autopoint (<= 0.17-11)
Suggests: gettext-doc
-Provides: libasprintf-dev, libgettextpo-dev
Description: GNU Internationalization utilities
Interesting for authors or maintainers of other packages or programs
which they want to see internationalized.
@@ -81,3 +81,14 @@
This package contains the libasprintf shared library which makes the
C formatted output routines (fprintf et al.) usable in C++ programs,
for use with the strings and the streams.
+
+Package: libgettext-dev
+Section: libdevel
+Architecture: any
+Multi-Arch: same
+Depends: libgettextpo0 (= ${binary:Version}), libasprintf0c2 (=
${binary:Version}), dpkg (>= 1.15.4) | install-info
+Suggests: gettext-doc
+Provides: libasprintf-dev, libgettextpo-dev
+Description: GNU Internationalization library development files
+ This package contains development files for the libgettextpo and
+ libasprintf libraries.
diff -Nru gettext-0.18.1.1/debian/gettext.lintian-overrides
gettext-0.18.1.1/debian/gettext.lintian-overrides
--- gettext-0.18.1.1/debian/gettext.lintian-overrides 2012-04-28
10:45:44.0 -0400
+++ gettext-0.18.1.1/debian/gettext.lintian-overrides 2012-08-16
20:53:37.0 -0400
@@ -5,10 +5,6 @@
gettext: ldconfig-symlink-missing-for-shlib usr/lib/libgnuintl.so.8
usr/lib/preloadable_libintl.so libgnuintl.so.8
gettext: shlib-missing-in-control-file libgnuintl 8 for
usr/lib/preloadable_libintl.so
#
-# gettext Provides libgettextpo-dev, so yes, it is a dev-pkg.
-#
-gettext: non-dev-pkg-with-shlib-symlink usr/lib/libgettextpo.so.0.5.1
usr/lib/libgettextpo.so
-#
# These libraries are for internal use only and should not be used by
# other programs.
#
@@ -21,3 +17,4 @@
gettext: no-shlibs-control-file usr/lib/preloadable_libintl.so
gettext: no-shlibs-control-file usr/lib/libgettextsrc-0.18.1.so
gettext: no-shlibs-control-file usr/lib/libgettextlib-0.18.1.so
+gettext: shlib-in-multi-arch-foreign-package usr/lib/preloadable_libintl.so
diff -Nru gettext-0.18.1.1/debian/rules gettext-0.18.1.1/debian/rules
--- gettext-0.18.1.1/debian/rules 2012-06-07 06:07:34.0 -0400
+++ gettext-0.18.1.1/debian/rules 2012-08-16 21:07:10.0 -0400
@@ -56,13 +56,14 @@
rm -f `find . -name "*~"`
rm -rf debian/tmp debian/
Bug#683751: gettext: Please mark gettext M-A: allowed
On Tue, Aug 14, 2012 at 10:52:38PM +0200, Santiago Vila wrote: > On Tue, 14 Aug 2012, Steve Langasek wrote: > >against the libs, are shipped in the 'gettext' binary package; when > >cross-building a package that build-depends on gettext, we have to > >know whether they're using the tools or the libraries. > Please note that if they are using the libraries, they should build-depend > on libasprintf-dev and/or libgettextpo-dev, currently provided by gettext, > not on gettext itself. > Build-depending on gettext instead of libasprintf-dev and/or libgettextpo-dev > if the build-depends is really for the libraries should be a bug. Right... but whether it's a build-dep on a real package or on a virtual one, if the package is M-A: foreign there's no way to express that you need the version for the host architecture. > Now the question: Do libasprintf-dev and libgettextpo-dev really need > to be in a different package than gettext? I think that depends on whether there's ever a need to build against host and build versions of these libraries in a single build. I don't know the answer to that; we probably won't discover the answer for a while, until someone working on cross-compiling the distro runs into one that does. You could split the packages and put the issue to bed once and for all, or just use Multi-Arch: allowed for now and wait for complaints :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#683751: gettext: Please mark gettext M-A: allowed
On Tue, 14 Aug 2012, Steve Langasek wrote: against the libs, are shipped in the 'gettext' binary package; when cross-building a package that build-depends on gettext, we have to know whether they're using the tools or the libraries. Please note that if they are using the libraries, they should build-depend on libasprintf-dev and/or libgettextpo-dev, currently provided by gettext, not on gettext itself. Build-depending on gettext instead of libasprintf-dev and/or libgettextpo-dev if the build-depends is really for the libraries should be a bug. Now the question: Do libasprintf-dev and libgettextpo-dev really need to be in a different package than gettext? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
On Tue, 14 Aug 2012, P. J. McDermott wrote: So there appear to be three ways to make gettext capable of satisfying cross build dependencies of packages such as those Johannes listed: 1. Mark gettext Multi-Arch: allowed. All depending packages that are to be cross built will need to depend on gettext:any. 2. Split the remaining libraries out of gettext (my original proposed solution). Mark gettext Multi-Arch: foreign and the new libraries package(s) Multi-Arch: same. 3. Remove the aforementioned symbolic links and declare the libraries in gettext "for internal use only" (as is libbfd-2.22-system.so in binutils, for example). The libraries in gettext are certainly for internal use only. This is reflected by lack of shlibs files for them, and it's also "documented" in /usr/share/lintian/overrides/gettext (not that this is a good place to "document" things, but certainly it is not a "secret"). So I would go for option 3, for simplicity, at least for now. Question: In this case we should still add "Multi-Arch: foreign" to gettect, right? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
On 2012-08-14 16:08, P. J. McDermott wrote: > 2. Split the remaining libraries out of gettext (my original proposed > solution). Mark gettext Multi-Arch: foreign and the new libraries > package(s) Multi-Arch: same. > 3. Remove the aforementioned symbolic links and declare the libraries > in gettext "for internal use only" (as is libbfd-2.22-system.so in > binutils, for example). Sorry, these aren't exactly complete, as Steve notes: On 2012-08-14 16:00, Steve Langasek wrote: > libgettext-dev is the main piece that is still missing to make all relevant > bits of gettext co-installable: currently the .so symlinks for the public > runtime libraries, which are needed at build time by packages linking > against the libs, are shipped in the 'gettext' binary package; so when > cross-building a package that build-depends on gettext, we have to know > whether they're using the tools or the libraries. So if nothing else, libgettext-dev should be split out from gettext. The remaining question is whether the libraries that are still in gettext are to be used by other packages. -- P. J. McDermott(_/@\_),--. http://www.pehjota.net/ o< o o > / oo \ http://www.pehjota.net/contact.html o \ `-/| <> |. o o o"~v/_\--/_/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
On 2012-08-13 13:06, P. J. McDermott wrote: > On 2012-08-13 07:30, Santiago Vila wrote: >> Moreover, all the libraries which are meant to be used by other >> packages are already multi-arched and they are in their own package >> (the last two in the list above). > > But this is a good point, which I had failed to realize previously. No > files in Debian besides the Gettext utilities should link against the > libraries in the gettext binary package. > > [...] > > Or might it be necessary to support other packages someday linking > against gettext's internal library objects (and the cross building of > those packages)? Actually, there are two symbolic links that suggest that the libraries in gettext might be meant (by upstream) to be used by other packages: /usr/lib/libgettextsrc.so -> libgettextsrc-0.18.1.so /usr/lib/libgettextlib.so -> libgettextlib-0.18.1.so So there appear to be three ways to make gettext capable of satisfying cross build dependencies of packages such as those Johannes listed: 1. Mark gettext Multi-Arch: allowed. All depending packages that are to be cross built will need to depend on gettext:any. 2. Split the remaining libraries out of gettext (my original proposed solution). Mark gettext Multi-Arch: foreign and the new libraries package(s) Multi-Arch: same. 3. Remove the aforementioned symbolic links and declare the libraries in gettext "for internal use only" (as is libbfd-2.22-system.so in binutils, for example). I understand why it was done in Ubuntu, but IMHO, option 1 is the least favorable, as it makes dependency clarification the job of many depending packages (requiring metadata changes thereto). (And as Johannes noted, this isn't supported yet by wanna-build, though this isn't a huge blocker per se.) Option 3 would of course be simplest, but I have no strong opinions between options 2 or 3. I'm prepared to do the work and submit a patch for either. Santiago, which option do you think is best? Can we say that the use of the libraries in the gettext binary package by other packages is "not allowed", or should we support such use in the future? -- P. J. McDermott(_/@\_),--. http://www.pehjota.net/ o< o o > / oo \ http://www.pehjota.net/contact.html o \ `-/| <> |. o o o"~v/_\--/_/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
Hi there, On Mon, Aug 13, 2012 at 01:06:28PM -0400, P. J. McDermott wrote: > On 2012-08-13 09:32, Johannes Schauer wrote: > > On Mon, Aug 13, 2012 at 01:30:12PM +0200, Santiago Vila wrote: > >> So: What exactly did you mean by "split"? > > Patrick's idea was to split the gettext binary package into two > > packages: one package that would contain those parts that satisfy > > dependencies of packages of every other architecture (this package would > > be M-A: foreign) and one package that would only allow to satisfy > > dependencies of packages of the same architecture (this package would be > > M-A: same). > Indeed, I meant that the architecture-specific interfaces [1] currently > provided by the gettext binary package could be moved into one or two > new binary packages. The result would be something like: > * gettext (Multi-Arch: foreign) > * libgettext (Multi-Arch: same) > * libgettext-dev (Multi-Arch: same) > * gettext-base > * ... > 1. These include the libgettextlib, libgettextsrc, and preloadable > libintl objects and gettext Java archive, as Johannes noted. libgettext-dev is the main piece that is still missing to make all relevant bits of gettext co-installable: currently the .so symlinks for the public runtime libraries, which are needed at build time by packages linking against the libs, are shipped in the 'gettext' binary package; so when cross-building a package that build-depends on gettext, we have to know whether they're using the tools or the libraries. The other libraries that haven't been split out are: /usr/lib/libgettextlib-0.18.1.so /usr/lib/libgettextsrc-0.18.1.so if these are private and internal, that's fine and not a concern. In that case, though, the unversioned symlinks (libgettextlib.so, libgettextsrc.so) should ideally be dropped from the binary package since anything that makes use of them is by definition buggy. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#683751: gettext: Please mark gettext M-A: allowed
On 2012-08-13 09:32, Johannes Schauer wrote: > On Mon, Aug 13, 2012 at 01:30:12PM +0200, Santiago Vila wrote: >> So: What exactly did you mean by "split"? > > Patrick's idea was to split the gettext binary package into two > packages: one package that would contain those parts that satisfy > dependencies of packages of every other architecture (this package would > be M-A: foreign) and one package that would only allow to satisfy > dependencies of packages of the same architecture (this package would be > M-A: same). Indeed, I meant that the architecture-specific interfaces [1] currently provided by the gettext binary package could be moved into one or two new binary packages. The result would be something like: * gettext (Multi-Arch: foreign) * libgettext (Multi-Arch: same) * libgettext-dev (Multi-Arch: same) * gettext-base * ... 1. These include the libgettextlib, libgettextsrc, and preloadable libintl objects and gettext Java archive, as Johannes noted. On 2012-08-13 07:30, Santiago Vila wrote: > Moreover, all the libraries which are meant to be used by other > packages are already multi-arched and they are in their own package > (the last two in the list above). But this is a good point, which I had failed to realize previously. No files in Debian besides the Gettext utilities should link against the libraries in the gettext binary package. And I just verified that this rule appears to hold for all 36 packages in sid main amd64 that declare run-time dependencies on gettext. None of their ELF files are dynamically linked against the libgettextlib, libgettextsrc, or preloadable_libintl objects. So I think this means that the gettext binary package can remain as-is and simply be marked Multi-Arch: foreign (rather than splitting it or marking it Multi-Arch: allowed and adding :any to dependency lists of other packages). Or might it be necessary to support other packages someday linking against gettext's internal library objects (and the cross building of those packages)? -- P. J. McDermott(_/@\_),--. http://www.pehjota.net/ o< o o > / oo \ http://www.pehjota.net/contact.html o \ `-/| <> |. o o o"~v/_\--/_/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
Hi, On Mon, Aug 13, 2012 at 01:30:12PM +0200, Santiago Vila wrote: > On Thu, 9 Aug 2012, P. J. McDermott wrote: > > I wonder if the gettext binary package should instead be split. > > Perhaps gettext-runtime (M-A: same) should provide the libraries, > > gettext-tools (M-A: foreign) should provide the tools, and gettext > > should be a metapackage that depends on both of the former packages? > > So: What exactly did you mean by "split"? Steve made the gettext binary package M-A: allowed so that packages depending on it can choose (using the :any qualifier in their dependencies) whether they need a native version of the gettext binary package or if a foreign version will do as well. Patrick's idea was to split the gettext binary package into two packages: one package that would contain those parts that satisfy dependencies of packages of every other architecture (this package would be M-A: foreign) and one package that would only allow to satisfy dependencies of packages of the same architecture (this package would be M-A: same). Looking at the content of the gettext binary package, the following files would surely go into the M-A: same package as they differ between architectures: /usr/lib/gettext/hostname /usr/lib/gettext/urlget /usr/lib/libasprintf.a /usr/lib/libgettextlib-0.18.1.so /usr/lib/libgettextlib.so /usr/lib/libgettextpo.a /usr/lib/libgettextsrc-0.18.1.so /usr/lib/libgettextsrc.so /usr/lib/preloadable_libintl.so /usr/share/java/gettext.jar The following binaries also differ across architectures but those executables might be able to fulfill dependencies on them even for foreign architectures? /usr/bin/gettextize /usr/bin/msgattrib /usr/bin/msgcat /usr/bin/msgcmp /usr/bin/msgcomm /usr/bin/msgconv /usr/bin/msgen /usr/bin/msgexec /usr/bin/msgfilter /usr/bin/msgfmt /usr/bin/msggrep /usr/bin/msginit /usr/bin/msgmerge /usr/bin/msgunfmt /usr/bin/msguniq /usr/bin/recode-sr-latin /usr/bin/xgettext I'm not familiar with gettext so I couldnt tell which of above binaries would satisfy foreign dependencies on them and which do not. IMHO, if possible, then compared with making the gettext binary package M-A: foreign, splitting the gettext binary package into a M-A: foreign and a M-A: same package would be the preferred option. One reason for that is, that the :any qualifier is not yet allowed to be used in Debian because wanna-build doesnt understand it yet. cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
On Thu, 9 Aug 2012, P. J. McDermott wrote: > I wonder if the gettext binary package should instead be split. Perhaps > gettext-runtime (M-A: same) should provide the libraries, gettext-tools > (M-A: foreign) should provide the tools, and gettext should be a > metapackage that depends on both of the former packages? Please note that the Debian gettext source package currently in wheezy/sid generates all the following binary packages: gettext-base gettext gettext-el gettext-doc autopoint libgettextpo0 libasprintf0c2 Moreover, all the libraries which are meant to be used by other packages are already multi-arched and they are in their own package (the last two in the list above). So: What exactly did you mean by "split"? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
On Thu, Aug 09, 2012 at 05:17:03PM -0400, P. J. McDermott wrote: > I wonder if the gettext binary package should instead be split. Perhaps > gettext-runtime (M-A: same) should provide the libraries, gettext-tools > (M-A: foreign) should provide the tools, and gettext should be a > metapackage that depends on both of the former packages? > Steve, is there any particular reason you didn't go this route for Ubuntu? Primarily out of a desire to not introduce package splits in Ubuntu that were not reflected in Debian. In the long term, it seems to be preferable to split the library packages out so that they can be co-installable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#683751: gettext: Please mark gettext M-A: allowed
I wonder if the gettext binary package should instead be split. Perhaps gettext-runtime (M-A: same) should provide the libraries, gettext-tools (M-A: foreign) should provide the tools, and gettext should be a metapackage that depends on both of the former packages? Steve, is there any particular reason you didn't go this route for Ubuntu? -- P. J. McDermott(_/@\_),--. http://www.pehjota.net/ o< o o > / oo \ http://www.pehjota.net/contact.html o \ `-/| <> |. o o o"~v/_\--/_/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683751: gettext: Please mark gettext M-A: allowed
Package: gettext Version: 0.18.1.1-9 Severity: normal Hi, the gettext binary package being Multi-Arch: None prevents the following essential source packages from being cross compiled: - acl - attr - bash - binutils - coreutils - dpkg - e2fsprogs - gawk - gcc-4.7 - grep - shadow - tar - texinfo - util-linux There of course exist many more but those are the packages that must be cross compiled to be able to bootstrap Debian for a new architecture (but fail to build because of gettext being Multi-Arch: None). Ubuntu made the gettext package Multi-Arch: allowed with version 0.18.1.1-9ubuntu1 and that seems to work fine wrt cross building. Please consider marking Debian gettext Multi-Arch: allowed as well. cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
