Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: [Debian-med-packaging] Upcoming libgd2-{xpm, noxpm}-dev -> libgd2-dev transition
29 views
Skip to first unread message
Charles Plessy
May 14, 2013, 4:00:02 AM5/14/13
to
Le Mon, May 13, 2013 at 10:34:36PM +0200, Ondřej Surý a écrit :
>
> 1. I have dropped the {xpm,noxpm} dichotomy and there's only
> libgd2-dev now. There are transitional packages which are ment
> to help with the move to libgd2-dev, so you don't have to make
> any changes right now - the binNMUs should work.
Dear Ondřej,
let me repeat in public: you are my hero ! Unable to prepare a patch myself, I
had waited for that day since many release cycles !
Cheers,
--
Charles
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2013051407...@falafel.plessy.net
>
> 1. I have dropped the {xpm,noxpm} dichotomy and there's only
> libgd2-dev now. There are transitional packages which are ment
> to help with the move to libgd2-dev, so you don't have to make
> any changes right now - the binNMUs should work.
Dear Ondřej,
let me repeat in public: you are my hero ! Unable to prepare a patch myself, I
had waited for that day since many release cycles !
Cheers,
--
Charles
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2013051407...@falafel.plessy.net
Guillem Jover
May 15, 2013, 2:00:02 AM5/15/13
to
Hi!
On Mon, 2013-05-13 at 22:34:36 +0200, Ondřej Surý wrote:
> Two things has happened with GD Library:
of other packages FTBFS, a new versioned libgdN-dev package can always
be introduced; otherwise unversioned ones in case of say just ABI bumps
are more correct and cause less painful transitions.
> 2. The upstream, which I accidentaly became part of, has released
> libgd-2.1.0-alpha1 today. This release has merged most of the code
> from PHP fork of the library (only some custom antialiasing stuff
> was not merged). But beware not, the API was kept backwards
> compatible.
>
> The ABI has remained same as well, but I have decided to bump the
> SONAME to 3, because I have implemented the GCC visibility magick,
> so only symbols, which were ment to be exposed, are exposed now.
If the SOVERSION is now 3, then the shared library package would need
to be called libgd3 (and libgd3-dev or as mentioned above ideally
libgd-dev), or did I misunderstood something in the above?
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2013051505...@gaara.hadrons.org
On Mon, 2013-05-13 at 22:34:36 +0200, Ondřej Surý wrote:
> Two things has happened with GD Library:
>
> 1. I have dropped the {xpm,noxpm} dichotomy and there's only
> libgd2-dev now. There are transitional packages which are ment
> to help with the move to libgd2-dev, so you don't have to make
> any changes right now - the binNMUs should work.
Might I suggest libgd-dev instead? If a later API revision makes lots
> 1. I have dropped the {xpm,noxpm} dichotomy and there's only
> libgd2-dev now. There are transitional packages which are ment
> to help with the move to libgd2-dev, so you don't have to make
> any changes right now - the binNMUs should work.
of other packages FTBFS, a new versioned libgdN-dev package can always
be introduced; otherwise unversioned ones in case of say just ABI bumps
are more correct and cause less painful transitions.
> 2. The upstream, which I accidentaly became part of, has released
> libgd-2.1.0-alpha1 today. This release has merged most of the code
> from PHP fork of the library (only some custom antialiasing stuff
> was not merged). But beware not, the API was kept backwards
> compatible.
>
> The ABI has remained same as well, but I have decided to bump the
> SONAME to 3, because I have implemented the GCC visibility magick,
> so only symbols, which were ment to be exposed, are exposed now.
If the SOVERSION is now 3, then the shared library package would need
to be called libgd3 (and libgd3-dev or as mentioned above ideally
libgd-dev), or did I misunderstood something in the above?
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ondřej Surý
May 15, 2013, 4:00:03 AM5/15/13
to
On Wed, May 15, 2013 at 7:55 AM, Guillem Jover <gui...@debian.org> wrote:
> Hi!
>
> On Mon, 2013-05-13 at 22:34:36 +0200, Ondřej Surý wrote:
>> Two things has happened with GD Library:
>>
>> 1. I have dropped the {xpm,noxpm} dichotomy and there's only
>> libgd2-dev now. There are transitional packages which are ment
>> to help with the move to libgd2-dev, so you don't have to make
>> any changes right now - the binNMUs should work.
>
> Might I suggest libgd-dev instead? If a later API revision makes lots
> of other packages FTBFS, a new versioned libgdN-dev package can always
> be introduced; otherwise unversioned ones in case of say just ABI bumps
> are more correct and cause less painful transitions.
The upstream position is that MAJOR release will break API. (But who
> Hi!
>
> On Mon, 2013-05-13 at 22:34:36 +0200, Ondřej Surý wrote:
>> Two things has happened with GD Library:
>>
>> 1. I have dropped the {xpm,noxpm} dichotomy and there's only
>> libgd2-dev now. There are transitional packages which are ment
>> to help with the move to libgd2-dev, so you don't have to make
>> any changes right now - the binNMUs should work.
>
> Might I suggest libgd-dev instead? If a later API revision makes lots
> of other packages FTBFS, a new versioned libgdN-dev package can always
> be introduced; otherwise unversioned ones in case of say just ABI bumps
> are more correct and cause less painful transitions.
knows if that ever happens). So I think the libgd2-dev actually
reflects the reality pretty well.
I might however add "Provides: libgd-dev" to libgd2-dev package, but
nothing depends on libgd-dev now, so I don't really see a need for it.
>> 2. The upstream, which I accidentaly became part of, has released
>> libgd-2.1.0-alpha1 today. This release has merged most of the code
>> from PHP fork of the library (only some custom antialiasing stuff
>> was not merged). But beware not, the API was kept backwards
>> compatible.
>>
>> The ABI has remained same as well, but I have decided to bump the
>> SONAME to 3, because I have implemented the GCC visibility magick,
>> so only symbols, which were ment to be exposed, are exposed now.
>
> If the SOVERSION is now 3, then the shared library package would need
> to be called libgd3 (and libgd3-dev or as mentioned above ideally
> libgd-dev), or did I misunderstood something in the above?
reflect the API version (1 vs 2).
I was thinking about renaming the shared package to libgd3, but it
would be quite confusing to have libgd2-dev to go with libgd3.
Ondrej
--
Ondřej Surý <ond...@sury.org>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andreas Beckmann
May 15, 2013, 5:00:04 AM5/15/13
to
Hi,
On 2013-05-15 09:58, Ondřej Surý wrote:
> On Wed, May 15, 2013 at 7:55 AM, Guillem Jover <gui...@debian.org> wrote:
>> Might I suggest libgd-dev instead? If a later API revision makes lots
the source packages since there are compatiblity packages), you can move
to a proper name now.
And worry about possible transitions for gd-3.x (libgd4, libgd4-dev)
later ...
> I might however add "Provides: libgd-dev" to libgd2-dev package, but
> nothing depends on libgd-dev now, so I don't really see a need for it.
violates Policy Chapter 8. libgd2-3 would be acceptable, an acceptable
-dev package would probably be libgd2-3 dev.
[Another interesting case where SOVERSION does not match VERSION is the
(correctly named) package pair libtiff4 and libtiff5, built from
tiff3 (3.x) and tiff (4.x)]
> I was thinking about renaming the shared package to libgd3, but it
But this would be the right thing to do.
> would be quite confusing to have libgd2-dev to go with libgd3.
But paring libgd-dev with libgd3 sounds fine.
Andreas
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/519348E5...@debian.org
On 2013-05-15 09:58, Ondřej Surý wrote:
> On Wed, May 15, 2013 at 7:55 AM, Guillem Jover <gui...@debian.org> wrote:
>> Might I suggest libgd-dev instead? If a later API revision makes lots
> The upstream position is that MAJOR release will break API. (But who
> knows if that ever happens). So I think the libgd2-dev actually
> reflects the reality pretty well.
Since you are doing a transition anyway (currently optional to change
> knows if that ever happens). So I think the libgd2-dev actually
> reflects the reality pretty well.
the source packages since there are compatiblity packages), you can move
to a proper name now.
And worry about possible transitions for gd-3.x (libgd4, libgd4-dev)
later ...
> I might however add "Provides: libgd-dev" to libgd2-dev package, but
> nothing depends on libgd-dev now, so I don't really see a need for it.
>>> The ABI has remained same as well, but I have decided to bump the
>>> SONAME to 3, because I have implemented the GCC visibility magick,
>>> so only symbols, which were ment to be exposed, are exposed now.
>>
>> If the SOVERSION is now 3, then the shared library package would need
>> to be called libgd3 (and libgd3-dev or as mentioned above ideally
>> libgd-dev), or did I misunderstood something in the above?
>
> The '2' in libgd2-dev is from 2.x.x, and not from the SONAME to
> reflect the API version (1 vs 2).
Which is, at least, confusing, as it is different elsewhere. And
>>> SONAME to 3, because I have implemented the GCC visibility magick,
>>> so only symbols, which were ment to be exposed, are exposed now.
>>
>> If the SOVERSION is now 3, then the shared library package would need
>> to be called libgd3 (and libgd3-dev or as mentioned above ideally
>> libgd-dev), or did I misunderstood something in the above?
>
> The '2' in libgd2-dev is from 2.x.x, and not from the SONAME to
> reflect the API version (1 vs 2).
violates Policy Chapter 8. libgd2-3 would be acceptable, an acceptable
-dev package would probably be libgd2-3 dev.
[Another interesting case where SOVERSION does not match VERSION is the
(correctly named) package pair libtiff4 and libtiff5, built from
tiff3 (3.x) and tiff (4.x)]
> I was thinking about renaming the shared package to libgd3, but it
> would be quite confusing to have libgd2-dev to go with libgd3.
Andreas
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
May 15, 2013, 1:00:03 PM5/15/13
to
Andreas Beckmann <an...@debian.org> writes:
> On 2013-05-15 09:58, Ondřej Surý wrote:
>> The '2' in libgd2-dev is from 2.x.x, and not from the SONAME to reflect
>> the API version (1 vs 2).
> Which is, at least, confusing, as it is different elsewhere. And
> violates Policy Chapter 8.
Policy is wrong here.
> On 2013-05-15 09:58, Ondřej Surý wrote:
>> The '2' in libgd2-dev is from 2.x.x, and not from the SONAME to reflect
>> the API version (1 vs 2).
> Which is, at least, confusing, as it is different elsewhere. And
> violates Policy Chapter 8.
If there are development files associated with a shared library, the
source package needs to generate a binary development package named
librarynamesoversion-dev, or if you prefer only to support one
development version at a time, libraryname-dev.
As written, this requires one to either use a non-versioned -dev package
or to change the -dev package name with every SONAME change. We do not
want developers to do the latter. It results in a bunch of unnecessary
transitions. The -dev package name should only be changed when the API
actually changes in significant ways and multiple co-installable -dev
packages are desirable.
I wonder if this Policy wording is what's caused several ill-advised -dev
package renamings.
I'll file a bug against Policy.
I'm not sure what we *do* want to say. I'm inclined to say that the
version in the -dev package name should be some meaningful version chosen
by the packager (possibly based on the upstream version) that will change
when the API changes in such a way as to make multiple -dev packages
desirable. But we can talk it over in the Policy bug.
> libgd2-3 would be acceptable, an acceptable -dev package would probably
> be libgd2-3 dev.
name is libgd and the SONAME is libgd.so.3, so the package name should be
libgd3. See Policy 8.1 on the naming syntax.
> [Another interesting case where SOVERSION does not match VERSION is the
> (correctly named) package pair libtiff4 and libtiff5, built from tiff3
> (3.x) and tiff (4.x)]
believe that naming wrong, although I could be convinced otherwise.
>> I was thinking about renaming the shared package to libgd3, but it
> But this would be the right thing to do.
>> would be quite confusing to have libgd2-dev to go with libgd3.
> But paring libgd-dev with libgd3 sounds fine.
> Andreas
> --
> To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/519348E5...@debian.org
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Guillem Jover
May 17, 2013, 1:00:02 AM5/17/13
to
Hi!
[ Just saw while drafting this, that you filed the bug on policy, so
sending a copy there too, let's continue the discussion there then. ]
On Wed, 2013-05-15 at 09:51:23 -0700, Russ Allbery wrote:
> Andreas Beckmann <an...@debian.org> writes:
> > On 2013-05-15 09:58, Ondřej Surý wrote:
> >> The '2' in libgd2-dev is from 2.x.x, and not from the SONAME to reflect
> >> the API version (1 vs 2).
>
> > Which is, at least, confusing, as it is different elsewhere. And
> > violates Policy Chapter 8.
>
> Policy is wrong here.
>
> If there are development files associated with a shared library, the
> source package needs to generate a binary development package named
> librarynamesoversion-dev, or if you prefer only to support one
> development version at a time, libraryname-dev.
>
> As written, this requires one to either use a non-versioned -dev package
> or to change the -dev package name with every SONAME change. We do not
> want developers to do the latter. It results in a bunch of unnecessary
> transitions. The -dev package name should only be changed when the API
> actually changes in significant ways and multiple co-installable -dev
> packages are desirable.
Right (and apologies for the bogus advice to rename to libgd3-dev, even if
made as a side comment and regardless of the package needing to be renamed
anyway :), I agree in theory that'd be ideal, but in practice the problem
with this is that it depends on lots of factors that can make the package
names very confusing or generic advice difficult.
Selecting the package name for the shared library just depends on the
present ABI, and it always needs to be changed (on SONAME bumps) to avoid
run-time breakage, and we already do have problems with people getting
that wrong (witness this thread), which is the important one, because it
can make programs not work. Choosing a suboptimal -dev package name might
imply FTBFS, and as such more work, but I'd posit that's better than a
broken run-time; also the -dev package name depends on fuzzy stuff like:
* are the API changes small enough that they do not warrant a different
name to avoid breaking non-switched packages, or what it breaks
deserves to be broken anyway (ex. hidden gets() from latest glibc).
* are there many reverse-dependencies, that an API change regardless
of size might render lots of packages unbuildable.
* does upstream have a sane project versioning so that the -dev package
can use that as a base, or would the packager need to invent something
completely unrelated (which might also be confusing for API users),
or use something unwieldy like the full version because upstream
breaks API on minor revisions. Lots of projects conflate the API and
ABI with a single version, some others might not even have a version
that denotes the API of a shared library that might be a tiny part of
a bigger project with many components.
* are API changes so common, that we might end up with shared
libraries and -dev packages sharing the same version but being
unrelated on the archive, which can be quite confusing?
Say liba1-dev → liba3 and liba3-dev → liba5.
* if API breakage is pretty uncommon and we don't foresee big future
changes then unversioned -dev is usually best, but we might get
suddenly surprised; altought we can always switch to version the
-dev, this might be difficult to predict.
* possibly others...
> I wonder if this Policy wording is what's caused several ill-advised -dev
> package renamings.
Perhaps, but I think we just lack better documentation and advice when
it comes to shared library handling in general.
There was an attempt by Junichi Uekawa (CCed) some time ago [L], but
AFAIR some people shunned it because supposedly it contained inaccuracies
or suboptimal advice (I've to confess I never reviewed it). IMO these
should have been corrected instead of trying to banish it from Debian.
I think something like that should be revived, reviewed and subsumed
into the policy manual or the devref.
[L] <http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html>
> I'll file a bug against Policy.
That'd be wonderful (ok seen now :).
> I'm not sure what we *do* want to say. I'm inclined to say that the
> version in the -dev package name should be some meaningful version chosen
> by the packager (possibly based on the upstream version) that will change
> when the API changes in such a way as to make multiple -dev packages
> desirable. But we can talk it over in the Policy bug.
The advantage of “either libNAME-dev or libNAMESOVER-dev” is that it's
pretty straightforward and simple, so less error prone, and I guess if
most upstreams usually break API when breaking ABI, it tends to be more
“correct” than not, it can still be suboptimal though if using the
libNAMESOVER-dev form unnecessarily. (I think breaking API w/o breaking
ABI is pretty rare, possibly restricted mostly to projects using full
versioned symbols support, like glibc.)
Of course a project can break ABI w/o breaking API; in C for example
by shuffling struct members, or changing variable types, etc, but is
that as common as breaking both?
> > [Another interesting case where SOVERSION does not match VERSION is the
> > (correctly named) package pair libtiff4 and libtiff5, built from tiff3
> > (3.x) and tiff (4.x)]
>
> I have another pair myself (libsaml2-dev and libsaml7), and I don't
> believe that naming wrong, although I could be convinced otherwise.
Nah, I think that's actually a very good example of proper version
handling, because the project version is 2.x.y, and the API seems to be
pretty well defined with a spec versioned as 2.0. I'm not sure that's
common though?
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
[ Just saw while drafting this, that you filed the bug on policy, so
sending a copy there too, let's continue the discussion there then. ]
On Wed, 2013-05-15 at 09:51:23 -0700, Russ Allbery wrote:
> Andreas Beckmann <an...@debian.org> writes:
> > On 2013-05-15 09:58, Ondřej Surý wrote:
> >> The '2' in libgd2-dev is from 2.x.x, and not from the SONAME to reflect
> >> the API version (1 vs 2).
>
> > Which is, at least, confusing, as it is different elsewhere. And
> > violates Policy Chapter 8.
>
> Policy is wrong here.
>
> If there are development files associated with a shared library, the
> source package needs to generate a binary development package named
> librarynamesoversion-dev, or if you prefer only to support one
> development version at a time, libraryname-dev.
>
> As written, this requires one to either use a non-versioned -dev package
> or to change the -dev package name with every SONAME change. We do not
> want developers to do the latter. It results in a bunch of unnecessary
> transitions. The -dev package name should only be changed when the API
> actually changes in significant ways and multiple co-installable -dev
> packages are desirable.
made as a side comment and regardless of the package needing to be renamed
anyway :), I agree in theory that'd be ideal, but in practice the problem
with this is that it depends on lots of factors that can make the package
names very confusing or generic advice difficult.
Selecting the package name for the shared library just depends on the
present ABI, and it always needs to be changed (on SONAME bumps) to avoid
run-time breakage, and we already do have problems with people getting
that wrong (witness this thread), which is the important one, because it
can make programs not work. Choosing a suboptimal -dev package name might
imply FTBFS, and as such more work, but I'd posit that's better than a
broken run-time; also the -dev package name depends on fuzzy stuff like:
* are the API changes small enough that they do not warrant a different
name to avoid breaking non-switched packages, or what it breaks
deserves to be broken anyway (ex. hidden gets() from latest glibc).
* are there many reverse-dependencies, that an API change regardless
of size might render lots of packages unbuildable.
* does upstream have a sane project versioning so that the -dev package
can use that as a base, or would the packager need to invent something
completely unrelated (which might also be confusing for API users),
or use something unwieldy like the full version because upstream
breaks API on minor revisions. Lots of projects conflate the API and
ABI with a single version, some others might not even have a version
that denotes the API of a shared library that might be a tiny part of
a bigger project with many components.
* are API changes so common, that we might end up with shared
libraries and -dev packages sharing the same version but being
unrelated on the archive, which can be quite confusing?
Say liba1-dev → liba3 and liba3-dev → liba5.
* if API breakage is pretty uncommon and we don't foresee big future
changes then unversioned -dev is usually best, but we might get
suddenly surprised; altought we can always switch to version the
-dev, this might be difficult to predict.
* possibly others...
> I wonder if this Policy wording is what's caused several ill-advised -dev
> package renamings.
it comes to shared library handling in general.
There was an attempt by Junichi Uekawa (CCed) some time ago [L], but
AFAIR some people shunned it because supposedly it contained inaccuracies
or suboptimal advice (I've to confess I never reviewed it). IMO these
should have been corrected instead of trying to banish it from Debian.
I think something like that should be revived, reviewed and subsumed
into the policy manual or the devref.
[L] <http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html>
> I'll file a bug against Policy.
> I'm not sure what we *do* want to say. I'm inclined to say that the
> version in the -dev package name should be some meaningful version chosen
> by the packager (possibly based on the upstream version) that will change
> when the API changes in such a way as to make multiple -dev packages
> desirable. But we can talk it over in the Policy bug.
pretty straightforward and simple, so less error prone, and I guess if
most upstreams usually break API when breaking ABI, it tends to be more
“correct” than not, it can still be suboptimal though if using the
libNAMESOVER-dev form unnecessarily. (I think breaking API w/o breaking
ABI is pretty rare, possibly restricted mostly to projects using full
versioned symbols support, like glibc.)
Of course a project can break ABI w/o breaking API; in C for example
by shuffling struct members, or changing variable types, etc, but is
that as common as breaking both?
> > [Another interesting case where SOVERSION does not match VERSION is the
> > (correctly named) package pair libtiff4 and libtiff5, built from tiff3
> > (3.x) and tiff (4.x)]
>
> I have another pair myself (libsaml2-dev and libsaml7), and I don't
> believe that naming wrong, although I could be convinced otherwise.
handling, because the project version is 2.x.y, and the API seems to be
pretty well defined with a spec versioned as 2.0. I'm not sure that's
common though?
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
Russ Allbery
May 20, 2013, 10:40:02 PM5/20/13
to
Guillem Jover <gui...@debian.org> writes:
> Perhaps, but I think we just lack better documentation and advice when
> it comes to shared library handling in general.
> There was an attempt by Junichi Uekawa (CCed) some time ago [L], but
> AFAIR some people shunned it because supposedly it contained inaccuracies
> or suboptimal advice (I've to confess I never reviewed it). IMO these
> should have been corrected instead of trying to banish it from Debian.
> I think something like that should be revived, reviewed and subsumed
> into the policy manual or the devref.
> [L] <http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html>
I'm wholeheartedly in favor of this, and even had some thoughts from time
> Perhaps, but I think we just lack better documentation and advice when
> it comes to shared library handling in general.
> There was an attempt by Junichi Uekawa (CCed) some time ago [L], but
> AFAIR some people shunned it because supposedly it contained inaccuracies
> or suboptimal advice (I've to confess I never reviewed it). IMO these
> should have been corrected instead of trying to banish it from Debian.
> I think something like that should be revived, reviewed and subsumed
> into the policy manual or the devref.
> [L] <http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html>
to time about helping with (or adopting) that guide and rolling it into
Policy. But I haven't been doing a very good job finding time for Debian
things lately. I'd love to see someone take this on.
Andreas Tille
May 21, 2013, 3:00:02 AM5/21/13
to
Hi,
On Mon, May 20, 2013 at 07:33:43PM -0700, Russ Allbery wrote:
> Guillem Jover <gui...@debian.org> writes:
>
> > Perhaps, but I think we just lack better documentation and advice when
> > it comes to shared library handling in general.
>
> > There was an attempt by Junichi Uekawa (CCed) some time ago [L], but
> > AFAIR some people shunned it because supposedly it contained inaccuracies
> > or suboptimal advice (I've to confess I never reviewed it). IMO these
> > should have been corrected instead of trying to banish it from Debian.
> > I think something like that should be revived, reviewed and subsumed
> > into the policy manual or the devref.
>
> > [L] <http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html>
>
> I'm wholeheartedly in favor of this, and even had some thoughts from time
> to time about helping with (or adopting) that guide and rolling it into
> Policy. But I haven't been doing a very good job finding time for Debian
> things lately. I'd love to see someone take this on.
I admit I do not feel qualified for this job but separation between
policy and library packaging guide made never any sense to me. I'd like
to add that the use of d-shlibs (which implements library packaging
guide) is way less frequently than it should be IMHO.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
On Mon, May 20, 2013 at 07:33:43PM -0700, Russ Allbery wrote:
> Guillem Jover <gui...@debian.org> writes:
>
> > Perhaps, but I think we just lack better documentation and advice when
> > it comes to shared library handling in general.
>
> > There was an attempt by Junichi Uekawa (CCed) some time ago [L], but
> > AFAIR some people shunned it because supposedly it contained inaccuracies
> > or suboptimal advice (I've to confess I never reviewed it). IMO these
> > should have been corrected instead of trying to banish it from Debian.
> > I think something like that should be revived, reviewed and subsumed
> > into the policy manual or the devref.
>
> > [L] <http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html>
>
> I'm wholeheartedly in favor of this, and even had some thoughts from time
> to time about helping with (or adopting) that guide and rolling it into
> Policy. But I haven't been doing a very good job finding time for Debian
> things lately. I'd love to see someone take this on.
policy and library packaging guide made never any sense to me. I'd like
to add that the use of d-shlibs (which implements library packaging
guide) is way less frequently than it should be IMHO.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20130521065...@an3as.eu
Junichi Uekawa
Jun 3, 2013, 5:40:02 AM6/3/13
to
Hi,
At Mon, 20 May 2013 19:33:43 -0700,
then has been that binary-only uploads are much easier
infrastructure-wise than before that there's less reason to rename a
-dev package than when this was authored about 8 years ago.
The last time I seriously worked on this document was 2006 and in the
hindsight, I was learning this stuff as I wrote this document, there
must be inaccuracies. But I lack the motivation to revise this
document now.
At Mon, 20 May 2013 19:33:43 -0700,
Russ Allbery wrote:
>
> Guillem Jover <gui...@debian.org> writes:
>
> > Perhaps, but I think we just lack better documentation and advice when
> > it comes to shared library handling in general.
>
> > There was an attempt by Junichi Uekawa (CCed) some time ago [L], but
> > AFAIR some people shunned it because supposedly it contained inaccuracies
> > or suboptimal advice (I've to confess I never reviewed it). IMO these
> > should have been corrected instead of trying to banish it from Debian.
> > I think something like that should be revived, reviewed and subsumed
> > into the policy manual or the devref.
>
> > [L] <http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html>
>
> I'm wholeheartedly in favor of this, and even had some thoughts from time
> to time about helping with (or adopting) that guide and rolling it into
> Policy. But I haven't been doing a very good job finding time for Debian
> things lately. I'd love to see someone take this on.
Some preconditions from that time has changed, and major change since
>
> Guillem Jover <gui...@debian.org> writes:
>
> > Perhaps, but I think we just lack better documentation and advice when
> > it comes to shared library handling in general.
>
> > There was an attempt by Junichi Uekawa (CCed) some time ago [L], but
> > AFAIR some people shunned it because supposedly it contained inaccuracies
> > or suboptimal advice (I've to confess I never reviewed it). IMO these
> > should have been corrected instead of trying to banish it from Debian.
> > I think something like that should be revived, reviewed and subsumed
> > into the policy manual or the devref.
>
> > [L] <http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html>
>
> I'm wholeheartedly in favor of this, and even had some thoughts from time
> to time about helping with (or adopting) that guide and rolling it into
> Policy. But I haven't been doing a very good job finding time for Debian
> things lately. I'd love to see someone take this on.
then has been that binary-only uploads are much easier
infrastructure-wise than before that there's less reason to rename a
-dev package than when this was authored about 8 years ago.
The last time I seriously worked on this document was 2006 and in the
hindsight, I was learning this stuff as I wrote this document, there
must be inaccuracies. But I lack the motivation to revise this
document now.
0 new messages