|
Home > Archive > Debian Developers > July 2005 > shared library -dev package naming proposal
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
shared library -dev package naming proposal
|
|
| Junichi Uekawa 2005-07-14, 6:01 pm |
| Hi,
I'd like to propose, for new -dev packages, to
name -dev packages after their runtime library counterparts.
If the library package is named lib$NAME,
call the -dev package lib$NAME-dev.
For example,
libxxx0 will have
libxxx0-dev.
libfoobar-2.1-0 will have
libfoobar-2.1-0-dev.
This allows mechanically determining shared library
package and corresponding -dev package.
This was raised in the Shared library BOF @ Debconf5
which was held this morning.
For transition purposes, I would like this only to be
enforced on new packages, since renaming every single
-dev package would be prohibitively intrusive,
but would like to enforce this rule for new packages.
Comments?
regards,
junichi
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Metzler 2005-07-14, 6:01 pm |
| [I am stopping the cross-posting to -release, as -release is no
discussion list]
On 2005-07-14 Junichi Uekawa <dancer@netfort.gr.jp> wrote:
> I'd like to propose, for new -dev packages, to
> name -dev packages after their runtime library counterparts.
>
> If the library package is named lib$NAME,
> call the -dev package lib$NAME-dev.
[...]
Hej,
The obvious downside of this is that the name of dev-package will change
although the API did not necessarily change. This would increase
workload for stuff like the current C++ transition and makes backporting
more difficult.
cu andreas
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Frost 2005-07-14, 6:01 pm |
| * Junichi Uekawa (dancer@netfort.gr.jp) wrote:
> I'd like to propose, for new -dev packages, to
> name -dev packages after their runtime library counterparts.
Uh, no? The -dev packages have no need to match to a specific runtime
library and this just creates unnecessary work.
> This allows mechanically determining shared library
> package and corresponding -dev package.
Eh? How about you go a bit deeper into why that's necessary and how
that's not possible today? What problem are you trying to solve with
this?
> This was raised in the Shared library BOF @ Debconf5
> which was held this morning.
Clearly something's missing here 'cause you havn't provided any rational
for why this would be a good thing and honestly it certainly looks like
a bad thing(tm) to do to me.
Stephen
| |
| Philipp Kern 2005-07-14, 6:01 pm |
| On Thu, 2005-07-14 at 20:16 +0900, Junichi Uekawa wrote:
> I'd like to propose, for new -dev packages, to
> name -dev packages after their runtime library counterparts.
I personally found it very handy that the dev packages automatically
selects the most recent API compatible version. Why do you want this
switch by the way? You did not name reasons as far as I could see.
Kind regards,
Philipp Kern
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Junichi Uekawa 2005-07-14, 6:01 pm |
| Hi,
> [...]
>
> Hej,
> The obvious downside of this is that the name of dev-package will change
> although the API did not necessarily change. This would increase
> workload for stuff like the current C++ transition and makes backporting
> more difficult.
Thanks for pointing these points out.
My impression is that your point can be addressed as follows:
1. libwhateverXXX-dev can (and in most cases must) provide
(and conflict) with libwhatever-dev,
so the first point is moot.
2. However, versioned depends will suffer, but having a versioned
depends will make moot the problem with backporting and C++ transition.
There may be other showstoppers.
I would really like this 10-year old non-regulation to
go to a concensus (it is indeed rather embarassing we don't
agree on a good solution after 10 years...)
regards,
junichi
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Junichi Uekawa 2005-07-14, 6:01 pm |
| Hi,
> * Junichi Uekawa (dancer@netfort.gr.jp) wrote:
>
> Uh, no? The -dev packages have no need to match to a specific runtime
> library and this just creates unnecessary work.
Well, I will list the rationale; it might have been a bit
of an abrupt mail for those who did not attend today's talk.
1. usually -dev packages have a symlink to the shared library
contained in the runtime shared library package.
2. The information of -dev packages depending on other -dev packages
cannot be automatically determined currently;
it should be possible to obtain a minimal list by analyzing the
NEEDED field of the objdump output.
3. d-shlibs provides an infrastracture for generating devlibs:Depends
for debian/control, but it has a long sed rule for replacing -dev
package names; it shoulnd't really neeed them.
4. I'm only requesting NEW packages to come under this naming
scheme, we'll try to cover the old packages with some kind of sed
script or replacement rule.
regards,
junichi
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Frost 2005-07-14, 6:01 pm |
| * Junichi Uekawa (dancer@netfort.gr.jp) wrote:
> There may be other showstoppers.
What does doing this solve? What does it even help with?
> I would really like this 10-year old non-regulation to
> go to a concensus (it is indeed rather embarassing we don't
> agree on a good solution after 10 years...)
non-regulation? What non-regulation? What regulation? Indeed, I'm not
sure there *isn't* majority agreement- it's just that you're in the
minority... That doesn't a concensus make, but, well, you'd have to
change your mind and you don't seem too keen on doing that..
The only good solution is to not let people who don't know how to handle
API and ABI changes and understand SONAMEs and how loaders and symbols
work to write libraries.
Stephen
| |
| Goswin von Brederlow 2005-07-14, 6:01 pm |
| Junichi Uekawa <dancer@netfort.gr.jp> writes:
> Hi,
>
>
> Thanks for pointing these points out.
> My impression is that your point can be addressed as follows:
>
> 1. libwhateverXXX-dev can (and in most cases must) provide
> (and conflict) with libwhatever-dev,
> so the first point is moot.
>
> 2. However, versioned depends will suffer, but having a versioned
> depends will make moot the problem with backporting and C++ transition.
You can (and it is often done) extend an api to include more
functionality without breaking the existing api. Any program using one
of the new functions must use a versioned depend on the libfoo-dev
package introducing the function.
The API can (and will) even stay compatibly across ABI changes like
the c++ transition or changes in one of the sub libarries.
So having an unversioned provide is quite unsatisfactory and having
versioned depends on the libfoo-dev quite common. Lets do a very rough
count:
mrvn@frosties:~% grep-dctrl -F Build-Depends "dev (" /mnt/mirror/debian/dists/sid/main/source/Sources -sPackage | wc
1663 3326 31941
> There may be other showstoppers.
>
> I would really like this 10-year old non-regulation to
> go to a concensus (it is indeed rather embarassing we don't
> agree on a good solution after 10 years...)
It has worked for the last 10 years so why change it now? Till now you
seem to only show your nameing scheme isn't worse but not why it is
better.
Or can you show any problems in the current names?
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Frost 2005-07-14, 6:01 pm |
| * Junichi Uekawa (dancer@netfort.gr.jp) wrote:
>
> Well, I will list the rationale; it might have been a bit
> of an abrupt mail for those who did not attend today's talk.
>
> 1. usually -dev packages have a symlink to the shared library
> contained in the runtime shared library package.
Uhh, this isn't a reason for them to have the major SO version in the
name of the -dev package.
> 2. The information of -dev packages depending on other -dev packages
> cannot be automatically determined currently;
> it should be possible to obtain a minimal list by analyzing the
> NEEDED field of the objdump output.
Errr, -dev packages generally don't (and shouldn't) depend on other -dev
packages. If you're trying to push the idea that -dev packages should
depend on the -dev packages of libraries they depend on- don't. That's
*wrong*, it's the completely wrong approach and should *not* be taken.
> 3. d-shlibs provides an infrastracture for generating devlibs:Depends
> for debian/control, but it has a long sed rule for replacing -dev
> package names; it shoulnd't really neeed them.
This doesn't sound quite right either. Looks at 'd-shlibs', it sounds
like it's doing the *wrong* thing anyway.
> 4. I'm only requesting NEW packages to come under this naming
> scheme, we'll try to cover the old packages with some kind of sed
> script or replacement rule.
Again, not a reason to follow the proposal at all.
Stephen
| |
| Junichi Uekawa 2005-07-14, 6:01 pm |
| Hi,
>
> What does doing this solve? What does it even help with?
Hmmm... we are talking about naming
Debian development shareed library package names based on
Debian runtime shared library package names.
>
>
> non-regulation? What non-regulation? What regulation? Indeed, I'm not
> sure there *isn't* majority agreement- it's just that you're in the
> minority... That doesn't a concensus make, but, well, you'd have to
> change your mind and you don't seem too keen on doing that..
>
> The only good solution is to not let people who don't know how to handle
> API and ABI changes and understand SONAMEs and how loaders and symbols
> work to write libraries.
This is not a relevant point, since I'm talking about the
Debian packaging, not how upstream should code.
regards,
junichi
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-07-14, 6:01 pm |
| [once more, doesn't belong on -release...]
On Thu, Jul 14, 2005 at 12:11:21PM -0400, Stephen Frost wrote:
> * Junichi Uekawa (dancer@netfort.gr.jp) wrote:
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
> Uhh, this isn't a reason for them to have the major SO version in the
> name of the -dev package.
[vbcol=seagreen]
> Errr, -dev packages generally don't (and shouldn't) depend on other -dev
> packages. If you're trying to push the idea that -dev packages should
> depend on the -dev packages of libraries they depend on- don't. That's
> *wrong*, it's the completely wrong approach and should *not* be taken.
It's more or less mandatory for libtool-based packages, due to a historical
misfeature of libtool; it's the only way to ensure static libs from any
particular -dev package are in a usable state; and it's essential when use
of the -dev package depends on the availability of headers from other -dev
packages.
That's not a very strong rationale for the proposed policy, but the -dev
dependencies themselves are (unfortunately) warranted.
--=20
Steve Langasek
postmodern programmer
| |
| Will Newton 2005-07-14, 6:01 pm |
| On Thursday 14 July 2005 17:14, Junichi Uekawa wrote:
> The current recommendation I'm trying to give is:
>
> Package: libXXXNNNN-dev
> Conflicts: libXXX-dev
> Provides: libXXX-dev
>
>
> Thus, it won't contradict with your requirement to
> be able to just build-depend on libXXX-dev.
I may be wrong, but I thought it was incorrect to build-dep only on a pure
virtual package? e.g.:
Build-Depend: xlibmesa-gl-dev | libgl-dev
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Junichi Uekawa 2005-07-14, 6:01 pm |
| Hi,
>
> I personally found it very handy that the dev packages automatically
> selects the most recent API compatible version. Why do you want this
> switch by the way? You did not name reasons as far as I could see.
The current recommendation I'm trying to give is:
Package: libXXXNNNN-dev
Conflicts: libXXX-dev
Provides: libXXX-dev
Thus, it won't contradict with your requirement to
be able to just build-depend on libXXX-dev.
Having a solid naming scheme will allow me to
ldd /usr/lib/libwhatever.so to track down its
shared library dependency, and appending "-dev"
to individual package to create the list of
requisite -dev packages.
regards,
junichi
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Junichi Uekawa 2005-07-14, 6:01 pm |
| Hi,
>
> Errr, -dev packages generally don't (and shouldn't) depend on other -dev
> packages. If you're trying to push the idea that -dev packages should
> depend on the -dev packages of libraries they depend on- don't. That's
> *wrong*, it's the completely wrong approach and should *not* be taken.
Give me justifications rather than just saying *wrong*,
because you are giving me an argument that is contrary to
current practice in Debian.
-dev packages do depend on other -dev packages,
and if they don't work, they are usually filed a serious bug
for non-functionality.
regards,
junichi
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Junichi Uekawa 2005-07-14, 6:01 pm |
| Hi,
> You can (and it is often done) extend an api to include more
> functionality without breaking the existing api. Any program using one
> of the new functions must use a versioned depend on the libfoo-dev
> package introducing the function.
>
> The API can (and will) even stay compatibly across ABI changes like
> the c++ transition or changes in one of the sub libarries.
>
> So having an unversioned provide is quite unsatisfactory and having
> versioned depends on the libfoo-dev quite common. Lets do a very rough
> count:
>
> mrvn@frosties:~% grep-dctrl -F Build-Depends "dev (" /mnt/mirror/debian/dists/sid/main/source/Sources -sPackage | wc
> 1663 3326 31941
>
You have a point, that probably makes libfoo-dev being
a unversioned provides to be a problem.
>
> It has worked for the last 10 years so why change it now? Till now you
> seem to only show your nameing scheme isn't worse but not why it is
> better.
>
> Or can you show any problems in the current names?
Currently, it's unordered.
Say a shared library package has the following:
libfoo-0.1-0
The development package looks like one of the following
or another random incarnation:
1. libfoo-dev
2. libfoo-0.1-dev
3. libfoo-0.1-0-dev
1 and 2 cannot easily be deduced from the shared library package name,
and I am proposing using 3 as a means of deducing the
-dev package name.
However, the goal of "having an information to shared library package name
with development package name" can be achieved by having the
package name in the "Provides:" field, so that might be a less disruptive
approach.
BTW, having Build-Depends: libfoo-dev in
a library's build-deps, will allow the developer
to overlook a soname change in depending shared library.
Which is a bad idea in the QA standpoint.
regards,
junichi
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Frost 2005-07-14, 6:01 pm |
| * Junichi Uekawa (dancer@netfort.gr.jp) wrote:
>
> Hmmm... we are talking about naming
> Debian development shareed library package names based on
> Debian runtime shared library package names.
Errr, you still havn't said what problem you're trying to solve
with this yet.
Stephen
| |
| Stephen Frost 2005-07-14, 6:01 pm |
| * Junichi Uekawa (dancer@netfort.gr.jp) wrote:
> BTW, having Build-Depends: libfoo-dev in
> a library's build-deps, will allow the developer
> to overlook a soname change in depending shared library.
> Which is a bad idea in the QA standpoint.
Uh, no it isn't. SONAME changes are fine, the package has to be
rebuilt, but that's not an issue if the API hasn't changed. If the API
has changed then it's more than an SONAME change and people will need to
adjust code which depends on it. That's not solved by putting the
SONAME into the -dev package, you'd need an API revision number in the
-dev package to deal with that (which a number of things do, and which
is good).
Stephen
| |
| Stephen Frost 2005-07-14, 6:01 pm |
| * Junichi Uekawa (dancer@netfort.gr.jp) wrote:
> The current recommendation I'm trying to give is:
>
> Package: libXXXNNNN-dev
> Conflicts: libXXX-dev
> Provides: libXXX-dev
>
>
> Thus, it won't contradict with your requirement to
> be able to just build-depend on libXXX-dev.
Uhh, then it doesn't fix your 'QA' concern anyway...
> Having a solid naming scheme will allow me to
>
> ldd /usr/lib/libwhatever.so to track down its
> shared library dependency, and appending "-dev"
> to individual package to create the list of
> requisite -dev packages.
If this is actually necessary for libtool-using packages, then write
something which goes through all of the .la files and does this, since
that's what libtool wants to do.
Stephen
| |
| Eduard Bloch 2005-07-14, 6:01 pm |
| #include <hallo.h>
* Will Newton [Thu, Jul 14 2005, 05:36:05PM]:
>
> I may be wrong, but I thought it was incorrect to build-dep only on a pure
> virtual package? e.g.:
>
> Build-Depend: xlibmesa-gl-dev | libgl-dev
I just though the same. In addition, that proposal removes the
possibility to depend on a certain -dev package and all newer versions
(by setting a versioned dependency on libfoo-dev).
Regards,
Eduard.
--
<vicbro> ich kotz gleich. warum reichen 512mb nicht für konqueror, konsole,
kopete, kontact, ksirc, openoffice und 10 weitere programme aus?
<jjFux> kbloat, kmemeater, kleak ...
| |
| Goswin von Brederlow 2005-07-14, 6:01 pm |
| Will Newton <will@misconception.org.uk> writes:
> On Thursday 14 July 2005 17:14, Junichi Uekawa wrote:
>
>
> I may be wrong, but I thought it was incorrect to build-dep only on a pure
> virtual package? e.g.:
>
> Build-Depend: xlibmesa-gl-dev | libgl-dev
Indeed. apt-get build-dep will regulary fall over Build-Depends on
virtual packages.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-14, 6:01 pm |
| Junichi Uekawa <dancer@netfort.gr.jp> writes:
> Having a solid naming scheme will allow me to
>
> ldd /usr/lib/libwhatever.so to track down its
> shared library dependency, and appending "-dev"
> to individual package to create the list of
> requisite -dev packages.
With the current scheme it is:
ldd /usr/lib/libwhatever.so to track down its shared library
dependency, strip the soversion and appending "-dev" to individual
package to create the list of requisite -dev packages.
And, by the way, that list is just plain wrong.
Say you have:
libfoobar1 depends (only on) libfoo1, libfoo1 depends libbar1.
YOU would get:
libfoo1: Depends: libbar1-dev
libfoobar1-dev Depends: libfoo1-dev, libbar1-dev.
Now libbar2 is uploaded and libfoo1 recompiled with libbar2:
libfoobar1 depends libfoo1, libfoo1 depends libbar2.
libfoo1: Depends: libbar2-dev
libfoobar1-dev is now uninstallable for no good reason at all.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-14, 6:01 pm |
| Junichi Uekawa <dancer@netfort.gr.jp> writes:
> BTW, having Build-Depends: libfoo-dev in
> a library's build-deps, will allow the developer
> to overlook a soname change in depending shared library.
> Which is a bad idea in the QA standpoint.
Yes and no.
The programer can overlook the soname change for the source. The API
hasn't changed and nothing needs to adjust for the new soname.
The packaging system won't let the binary forget the soname change
though as that is part of the package name of the libary. Binaries
will keep using the old lib till they are recompiled.
You see, nothing breaks.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2005-07-15, 2:48 am |
| also sprach Junichi Uekawa <dancer@netfort.gr.jp> [2005.07.14.1416 +0300]:
> libfoobar-2.1-0 will have
> libfoobar-2.1-0-dev.
Please distinguish between API and ABI!
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer and author: http://debiansystem.info
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
"the liar at any rate recognises that recreation, not instruction, is
the aim of conversation, and is a far more civilised being than the
blockhead who loudly expresses his disbelief in a story which is told
simply for the amusement of the company."
-- oscar wilde
| |
| Junichi Uekawa 2005-07-15, 7:53 am |
| Hi,
>
> With the current scheme it is:
>
> ldd /usr/lib/libwhatever.so to track down its shared library
> dependency, strip the soversion and appending "-dev" to individual
> package to create the list of requisite -dev packages.
>
> And, by the way, that list is just plain wrong.
Okay, currently d-shlibs is using objdump,
and does not recursively look for dependencies.
gotom suggested to use ldd, to obtain the full path of
shared libraries, and I do see the limitation with
using ldd, as you pointed out illustratively
in your example.
regards,
junchi
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Junichi Uekawa 2005-07-15, 7:53 am |
| Hi,
Thanks for your input.
>
> If this is actually necessary for libtool-using packages, then write
> something which goes through all of the .la files and does this, since
> that's what libtool wants to do.
and
> Errr, you still havn't said what problem you're trying to solve
> with this yet.
1. To derive dependency information from libtool-using packages,
it is currently possible to derive lists of shared library packages.
2. In general, there is a leap in shared library packages and -dev package,
and it's not possible to get a -dev package which is for a given
shared library package.
I envision that it would be nice to be able to agree on some kind of
naming style so that it is possible to deduce the name of development
library in some mechanical manner. It's not just because of autogenerating
-dev dependencies, but about usability of Debian as a Development
platform :
$ objdump -p /usr/lib/libshared.so | sed -n 's/^ *SONAME *//p' | sed 's/\(0-9\)\.so\./\1/; s/\.so\.//; s/$/-dev/'
libshared0-dev
An alternate solution is to have a database for that kind of thing,
but I forsee that it requires effort to maintain and keep up-to-date.
It's rather embarassing to know that Debian isn't organized at all in this
manner.
regards,
junichi
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Francesco P. Lovergine 2005-07-15, 7:53 am |
| On Fri, Jul 15, 2005 at 09:36:47AM +0300, martin f krafft wrote:
> also sprach Junichi Uekawa <dancer@netfort.gr.jp> [2005.07.14.1416 +0300]:
>
> Please distinguish between API and ABI!
>
True. Indeed the proposed policy is already followed in case of ABI
changes. And any sane program would not compile when ever a library
change its _API_ in a way not back-compatible.
If not, well that's an upstream issue, not a debian one 
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Frost 2005-07-15, 7:53 am |
| * Francesco P. Lovergine (frankie@debian.org) wrote:
> On Fri, Jul 15, 2005 at 09:36:47AM +0300, martin f krafft wrote:
>
> True. Indeed the proposed policy is already followed in case of ABI
> changes. And any sane program would not compile when ever a library
> change its _API_ in a way not back-compatible.
> If not, well that's an upstream issue, not a debian one
Exactly! We must have a seperate tracking of API and ABI changes.
To do otherwise is madness.
Stephen
| |
| Stephen Frost 2005-07-15, 7:53 am |
| * Junichi Uekawa (dancer@netfort.gr.jp) wrote:
>
> and
>
>
> 1. To derive dependency information from libtool-using packages,
> it is currently possible to derive lists of shared library packages.
>
> 2. In general, there is a leap in shared library packages and -dev package,
> and it's not possible to get a -dev package which is for a given
> shared library package.
Shared library packages and -dev packages represent different things.
> I envision that it would be nice to be able to agree on some kind of
> naming style so that it is possible to deduce the name of development
> library in some mechanical manner. It's not just because of autogenerating
> -dev dependencies, but about usability of Debian as a Development
> platform :
>
> $ objdump -p /usr/lib/libshared.so | sed -n 's/^ *SONAME *//p' | sed 's/\(0-9\)\.so\./\1/; s/\.so\.//; s/$/-dev/'
> libshared0-dev
Having a single naming style is somewhat difficult for libraries because
different upstreams choose to represent API changes differently. An
example of this is OpenLDAP- their API hasn't ever changed in a
backwards-incompatible way (or so they tell me). They do add things to
their API over time, though I think they generally try to do those
around major releases (2.0, 2.1, 2.2, 2.3, etc). They also change the
ABI without (unfortunately) much hesitation. The ABI changes need to be
tracked using the SONAME, but technically we could have just one
'libldap-dev' since OpenLDAP 1.3. This isn't true for other upstreams,
such as glib, which, I infer from their naming scheme anyway, has API
changes generally around major releases, and those changes aren't
backwards-compatible. (ie: 1.3 to 2.0, or what have you).
Tieing the API to the SONAME is a *bad* idea, it implies changes where
there aren't any and requires changes to packages that aren't necessary.
Honestly, I think it'd be nice if we could teach the buildds to
automatically rebuild packages when the API hasn't changed. I'd think
that'd make some of these transistions that we have to go through on
occation go alot faster.
> An alternate solution is to have a database for that kind of thing,
> but I forsee that it requires effort to maintain and keep up-to-date.
> It's rather embarassing to know that Debian isn't organized at all in this
> manner.
Back to my previous comment- you've got people who aren't familiar with
SONAMES and ABIs writing libraries. I don't feel that's *Debian's*
fault, though we do try to deal with it as best we can. This suggestion
doesn't help that issue one bit though.
Stephen
| |
| Goswin von Brederlow 2005-07-15, 7:53 am |
| Junichi Uekawa <dancer@netfort.gr.jp> writes:
> Hi,
>
You could also suggest a policy for libs to have a libfoo.devname file
similar to the libfoo.shlibs file but naming the needed -dev
packages. If that is a good idea or not you have to think about. Just
a wild idea.
[vbcol=seagreen]
>
> Okay, currently d-shlibs is using objdump,
> and does not recursively look for dependencies.
>
> gotom suggested to use ldd, to obtain the full path of
> shared libraries, and I do see the limitation with
> using ldd, as you pointed out illustratively
> in your example.
You have to do both. ldd for the full path and then filter that with
objdump. That is how dpkg-shlibdeps does it if I read the code right.
> regards,
> junchi
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Daniel Kobras 2005-07-15, 6:06 pm |
| On Fri, Jul 15, 2005 at 10:44:04PM +0900, Junichi Uekawa wrote:
> Stephen's points are valid and quite useful
> considering an upstream developer's point of view,
> but for random user joe who is trying to find a development
> package, one of the following may help him find the right package
>
>
> 1. creating a system-wide list of what -dev package does what.
>
> -> centrally requires work. Already started in d-shlibs.
>
> 2. creating a devlibs file which points to what shared library
> is handled by which -dev package.
>
> -> requires manual intervention by all developers,
> and utilizes an i-node for all shared library installations.
>
> 3. creating a package policy to Provides: a symbollic name
> that can be traced from the shared library package name or
> the shared library soname.
>
> -> non-invasive if it's done gradually.
Make shared library packages Suggest: their corresponding -dev packages.
Regards,
Daniel.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Junichi Uekawa 2005-07-15, 6:06 pm |
| Hi,
Thanks for your time and feedback. I appreciate it very much.
> You could also suggest a policy for libs to have a libfoo.devname file
> similar to the libfoo.shlibs file but naming the needed -dev
> packages. If that is a good idea or not you have to think about. Just
> a wild idea.
Yes, that's basically what shlibs file is doing for shared libraries.
I was hoping that it was more practical to have a=20
Provides: field or a package name that can be linked from=20
the shared library package.
Stephen Frost has explained to me that -dev package names
apparently express their API, and their maintainers
can be beaten to whatever when they break,=20
and I kind of agree that might even be a good idea,
I would like to drop the idea of unanimously=20
requesting packages to name their -dev packages thus way.
=46rom the standpoint of a Debian user, it still stands that=20
shared library packages and -dev packages (which has a=20
symlink pointing to the shared library package) do not=20
have an explicit relationship declared in Debian,
except for the fact that they are often created from the=20
same source.
Stephen's points are valid and quite useful=20
considering an upstream developer's point of view,
but for random user joe who is trying to find a development
package, one of the following may help him find the right package
1. creating a system-wide list of what -dev package does what.
-> centrally requires work. Already started in d-shlibs.
2. creating a devlibs file which points to what shared library
is handled by which -dev package.
-> requires manual intervention by all developers,
and utilizes an i-node for all shared library installations.
3. creating a package policy to Provides: a symbollic name
that can be traced from the shared library package name or
the shared library soname.
-> non-invasive if it's done gradually.
>=20
> You have to do both. ldd for the full path and then filter that with
> objdump. That is how dpkg-shlibdeps does it if I read the code right.
Thanks for pointing that out.
This knowledge may become useful when ldd output can be converted to
a list of -dev packages.
regards,
junichi
| |
| Ondrej Sury 2005-07-15, 6:06 pm |
| > Stephen's points are valid and quite useful
> considering an upstream developer's point of view,
> but for random user joe who is trying to find a development
> package, one of the following may help him find the right package
Joe user should do:
apt-cache search libNAME dev
(or use synaptic, aptitude, etc.)
That's what do I do when I search for library.
Ondrej.
--
Ondrej Sury <ondrej@sury.org>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-07-15, 6:06 pm |
| On Fri, Jul 15, 2005 at 05:30:44PM +0900, Junichi Uekawa wrote:
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
> and
[vbcol=seagreen]
> 1. To derive dependency information from libtool-using packages,
> it is currently possible to derive lists of shared library packages.
> 2. In general, there is a leap in shared library packages and -dev package,
> and it's not possible to get a -dev package which is for a given
> shared library package.
> I envision that it would be nice to be able to agree on some kind of
> naming style so that it is possible to deduce the name of development
> library in some mechanical manner. It's not just because of autogenerating
> -dev dependencies, but about usability of Debian as a Development
> platform :
> $ objdump -p /usr/lib/libshared.so | sed -n 's/^ *SONAME *//p' | sed 's/\(0-9\)\.so\./\1/; s/\.so\.//; s/$/-dev/'
> libshared0-dev
$ apt-cache showsrc $(dpkg -S /usr/lib/libxslt.so.1 | cut -f1 -d \
| sed -n -e's/^Binary: //p' | sed -e's/,[[:space:]]\+/\n/g' | grep -- -dev \
| sort -u
libxslt1-dev
$
Can be refined to only query sources for a particular dist, etc. Can't cope
with multiple -dev packages from a single source package without recourse to
the Contents files.
OTOH, your solution just don't seem to offer much unless *all* packages
conform to the proposed scheme, and it's already been argued that there are
cases that your scheme doesn't address... and even if everyone agreed it
was a good idea, it would take a long time before developers would get the
benefits of it, because of all the conversions that would need to take
place. I just don't see the point.
> An alternate solution is to have a database for that kind of thing,
> but I forsee that it requires effort to maintain and keep up-to-date.
Like the database I just queried above?
> It's rather embarassing to know that Debian isn't organized at all in this
> manner.
You seem to be embarrassed easily. If this is such a problem for using
Debian as a development platform, why is this the first time I've seen the
subject discussed on debian-devel?
I'm not convinced that the problem you're trying to solve is of sufficiently
general interest to outweigh all of the other problems it introduces (such
as the ones that have been pointed out in this thread).
--
Steve Langasek
postmodern programmer
| |
| Michael K. Edwards 2005-07-15, 6:06 pm |
| On 7/15/05, Steve Langasek <vorlon@debian.org> wrote:
> On Fri, Jul 15, 2005 at 05:30:44PM +0900, Junichi Uekawa wrote:
>=20
> Like the database I just queried above?
There's an even better one called "Google". If you're adding a
library dependency to a package that you plan to maintain for the
benefit of a large number of users, you might want to know a little
more about the library, its upstream, and its packager than just what
the relationship is between foo.sf.net, foo-X.X.tgz, and the binary
package names.
Automated tools, on the other hand, can and should be primed with
data, not heuristics. Test suites _should_ be fragile so that if
something changes in a remotely questionable way you _spot_ it. Then
you use a heuristic, if available, to update the priming data and
touch it up manually where necessary. Automate where it helps, not
where it hurts.
his[vbcol=seagreen]
Organization is overrated. While good code is, in the long run, an
aesthetic criterion as much as anything else, some aesthetic instincts
can be misleading. Cathedral / bazaar, and all that. (Though I
personally prefer cathedrals, and if you've read about how they were
actually built, you will see that the Linux, glibc, GCC, perl, python,
etc. development process looks much more like cathedral building than
like the Kasbah.)
[vbcol=seagreen]
> You seem to be embarrassed easily. If this is such a problem for using
> Debian as a development platform, why is this the first time I've seen th=
e
> subject discussed on debian-devel?
There may well be useful tools that are made harder to write by the
indiscriminate naming of packages. For an example where the global
aesthetic criterion does tend to win, at the expense of some use
cases, consider the prejudice against splitting off "micro-packages"
to slim down the dependencies of the main binary package. tetex-bin
comes to mind -- and don't tell me that tetex-base is the main
package, because it's tetex-bin that is needed when building X11 (last
time I checked; still true of xfree86 in unstable; apparently also
true of xorg).
Perhaps it's not worth splitting out xpdf as a separate source package
to break the circular build-depends -- although it would avoid
gratuitous security updates to the rest of tetex. But I for one
really don't like having to have the binary packages from an old
xfree86 build installed in order to do a new build. Yeah, you can
build your own tetex-bin with xpdf excluded, or just force-install
tetex-bin without the X libs in a chroot -- but it's ugly.
I know that the package count is getting to be a scalability problem
and that people are working on ways of dealing with that, and in the
meantime there is some rational pressure not to split packages
needlessly. I'm not blaming the TeTeX team for weighing the factors
and deciding not to split. I'm just giving an example of a warning
sign that too many meanings are being overloaded onto one technical
distinction -- in this case, the boundaries of a .deb. Another
example would be localization packages; I hope I don't need to spell
that one out.
> I'm not convinced that the problem you're trying to solve is of sufficien=
tly
> general interest to outweigh all of the other problems it introduces (suc=
h
> as the ones that have been pointed out in this thread).
IMHO the problem is real, the solution is wrong. Don't try to
organize the underlying data; add enough metadata markup that you can
present better organized views for various purposes. Don't rush to
add that metadata to debian/control; sketch out a heuristic using
existing metadata that leaves you with a relatively small number of
manual overrides, write real applications that use it, and then decide
if it's OK to keep the manual overrides as detached metadata or if
they belong in debian/control.
Cheers,
- Michael
| |
| Kurt Roeckx 2005-07-16, 2:48 am |
| Junichi Uekawa <dancer@netfort.gr.jp> wrote:
>
> Give me justifications rather than just saying *wrong*,
> because you are giving me an argument that is contrary to
> current practice in Debian.
>
> -dev packages do depend on other -dev packages,
> and if they don't work, they are usually filed a serious bug
> for non-functionality.
Reasons why you need you need to add a build-dependency on libfoo-dev
package:
- You're linking to it
- You're using include files from it.
Simular, if your package is libbar, your lib libbar-dev package needs to
depends on the libfoo-dev packages if:
- Your include files include libfoo's include files. This is ussually
something you want to avoid.
- You have a static lib, and people will need to link libfoo if they're
linking to your package. I think static libs should be avoided in
most cases.
An other reason why it's currently done is that some packages link to
packages that only "use" your libbar lib, but also link to libfoo, which
isn't needed. Isn't not needed because libbar already depends on
libfoo. This can for instance be the case when using libtool. The
version of libtool in the archive shouldn't be doing this.
The correct way to fix this is by updating the libtool package, or
whatever that's being used, and not by having -dev packages depend on
other/more -dev packages. It's just easier to fix this in the short
time, because it only requires one -dev package to be fixed while else
all packages build-depending on it need to be fixed.
Kurt
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|