You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Oden Eriksson <od...@kvikkjokk.net> on 2002/11/06 18:31:50 UTC
The *.so files
Hi.
I have packaged subversion v0.14.5 r3578 for Mandrake Linux 9.0/Cooker, but
stumbled upon an issue. The common practise in Mandrake Linux is to package
the "*.so" files in a devel subpackage.
Now, this doesn't seem to work with subpackage since for example the client
won't work without these "*.so" files. What should I do, any suggestions
besides "breaking" the Mandrake way of doing things?
My rpm packages are using parts and are based on the provided rpm spec file,
but provides these binary packages:
libsubversion0-0.14.5-0.r3578.2mdk
libsubversion0-devel-0.14.5-0.r3578.2mdk
libsubversion0-static-devel-0.14.5-0.r3578.2mdk
subversion-client-common-0.14.5-0.r3578.2mdk
subversion-client-dav-0.14.5-0.r3578.2mdk
subversion-client-local-0.14.5-0.r3578.2mdk
subversion-repos-0.14.5-0.r3578.2mdk
apache2-mod_dav_svn-2.0.43_0.14.5-0.r3578.2mdk
--
Regards // Oden Eriksson, Deserve-IT Networks
Check the "Modules For Apache2" status page at:
http://www.deserve-it.com/modules_for_apache2.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The *.so files
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Nov 07, 2002 at 01:13:24AM +0000, Colin Watson wrote:
>...
> There's one very good reason for it: if you put the plain .so symlink in
> the non-development package, then you cannot simultaneously install two
> different versions of a library
In general, yes. But note that SVN libraries all have [major] version
numbers encoded in the library name. Thus, we can simultaneously install two
versions of the library.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The *.so files
Posted by Colin Watson <cj...@flatline.org.uk>.
On Wed, Nov 06, 2002 at 03:09:20PM -0500, Eric Gillespie wrote:
> That said, let me state that i abhor this practice. When a user
> on such a system installs package 'foo' they later discover they
> have only random chunks of package 'foo', not all of it. That's
> a disservice both to the users and the authors of the software.
>
> I can't tell you how many lists i'm on where someone complains
> they can't compile something and it turns out they didn't have
> the -dev package installed.
>
> Please don't perpetuate this lunacy.
There's one very good reason for it: if you put the plain .so symlink in
the non-development package, then you cannot simultaneously install two
different versions of a library (without Replaces: hacks which mean that
you end up not really knowing where the .so is going to point, or
without changing the entire name so that users have to do -lsvn_client2
or whatever). That's a true pain when it comes time for a soname change.
My experience is with Debian, but I guess the same holds for other
packaging systems too.
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The *.so files
Posted by Oden Eriksson <od...@kvikkjokk.net>.
torsdagen den 7 november 2002 09.02 skrev Nuutti Kotivuori:
> Eric Gillespie wrote:
> > That said, let me state that i abhor this practice. When a user
> > on such a system installs package 'foo' they later discover they
> > have only random chunks of package 'foo', not all of it. That's
> > a disservice both to the users and the authors of the software.
> >
> > I can't tell you how many lists i'm on where someone complains
> > they can't compile something and it turns out they didn't have
> > the -dev package installed.
> >
> > Please don't perpetuate this lunacy.
>
> Well here I must say that - respect the policy of your distribution.
>
> It may very well be that in your distribution of choice, -dev or
> -devel packages are rare or work suboptimally, in which case you
> obviously do not want to make them.
>
> But for example in the case of Debian, it is absolute lunacy _not_ to
> do it. Separating -dev and separating libraries from the programs
> (libsvn0 vs. subversion) is the way of the distribution and it works
> very very well.
Well said Nuutti!
I didn't want to participate in this debate, but your reply was the best!
--
Regards // Oden Eriksson, Deserve-IT Networks
Check the "Modules For Apache2" status page at:
http://www.deserve-it.com/modules_for_apache2.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The *.so files
Posted by Nuutti Kotivuori <na...@iki.fi>.
Eric Gillespie wrote:
> That said, let me state that i abhor this practice. When a user
> on such a system installs package 'foo' they later discover they
> have only random chunks of package 'foo', not all of it. That's
> a disservice both to the users and the authors of the software.
>
> I can't tell you how many lists i'm on where someone complains
> they can't compile something and it turns out they didn't have
> the -dev package installed.
>
> Please don't perpetuate this lunacy.
Well here I must say that - respect the policy of your distribution.
It may very well be that in your distribution of choice, -dev or
-devel packages are rare or work suboptimally, in which case you
obviously do not want to make them.
But for example in the case of Debian, it is absolute lunacy _not_ to
do it. Separating -dev and separating libraries from the programs
(libsvn0 vs. subversion) is the way of the distribution and it works
very very well.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The *.so files
Posted by Oden Eriksson <od...@kvikkjokk.net>.
onsdagen den 6 november 2002 21.09 skrev Eric Gillespie:
> Oden Eriksson <od...@kvikkjokk.net> writes:
> > The common practise in Mandrake Linux is to package the "*.so"
> > files in a devel subpackage.
> >
> > Now, this doesn't seem to work with subpackage since for
> > example the client won't work without these "*.so" files.
>
> Kinda. The svn program should only require the *actual* shared
> objects, i.e. libsvn_ra_local-1.so.0.0. The .so files are only
> symbolic links to those files. What RH and Debian do (and thus
> Mandrake, i imagine) is put the actual shared objects (and the
> .soname symlink, i.e. libsvn_ra_local-1.so.0.0 and
> libsvn_ra_local-1.so.0) in one package and the plain .so symlink
> in the dev package. I think that's what you want to do.
Yes that seems a common practise in Mandrake.
I'm a contributer to Mandrake and I cannot change the appearance of thousands
of packages so that there are no devel sub packages. Also as I'm no coder I
can't say what's wrong in the subpackage code, other softwares don't seem to
have this problem. I suggest the subpackage developers look into this.
--
Regards // Oden Eriksson, Deserve-IT Networks
Check the "Modules For Apache2" status page at:
http://www.deserve-it.com/modules_for_apache2.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The *.so files
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Oden Eriksson <od...@kvikkjokk.net> writes:
> The common practise in Mandrake Linux is to package the "*.so"
> files in a devel subpackage.
> Now, this doesn't seem to work with subpackage since for
> example the client won't work without these "*.so" files.
Kinda. The svn program should only require the *actual* shared
objects, i.e. libsvn_ra_local-1.so.0.0. The .so files are only
symbolic links to those files. What RH and Debian do (and thus
Mandrake, i imagine) is put the actual shared objects (and the
.soname symlink, i.e. libsvn_ra_local-1.so.0.0 and
libsvn_ra_local-1.so.0) in one package and the plain .so symlink
in the dev package. I think that's what you want to do.
That said, let me state that i abhor this practice. When a user
on such a system installs package 'foo' they later discover they
have only random chunks of package 'foo', not all of it. That's
a disservice both to the users and the authors of the software.
I can't tell you how many lists i'm on where someone complains
they can't compile something and it turns out they didn't have
the -dev package installed.
Please don't perpetuate this lunacy.
--
Eric Gillespie <*> epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The *.so files
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Wed, Nov 06, 2002 at 02:16:45PM -0800, Greg Stein wrote:
> On Wed, Nov 06, 2002 at 09:22:35PM +0000, Joe Orton wrote:
> > SVN treats ra_dav and ra_local as libraries, but really they are
> > loadable modules - I think this is where the disconnect is happening.
>
> They *can* be loadable modules. Normally, we just link them in. But if you
> pass --enable-dso to ./configure, then it will stop linking them in. When
> doing so, however, the DSO loader must be able to find them. I'm not sure
> what the Linux rules are for that. I suspect the paths in ld.so.conf and/or
> LD_LIBRARY_PATH.
Ah, okay, I'd thought this was the default for shared builds.
It looks like build.conf specifies $(NEON_LIBS) as a dependency of the
svn binary, which seems odd. That makes putting the ra_dav module in a
separate package a little pointless, since the neon dependency isn't
isolated.
> > The loadable modules should really go in %{_libdir}/subversion/*.so,
> > though you'd probably need to modify the ra loader to look in the right
> > place.
>
> Yah, sounds about right. Any ideas on how to get the system to "look in the
> right place" ? It it simply a matter of passing an absolute path to the
> loader?
Yes, exactly; otherwise you have to mess with LD_LIBRARY_PATH or
ld.so.conf etc.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The *.so files
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Nov 06, 2002 at 09:22:35PM +0000, Joe Orton wrote:
> On Wed, Nov 06, 2002 at 12:37:21PM -0800, Greg Stein wrote:
> > On Wed, Nov 06, 2002 at 07:31:50PM +0100, Oden Eriksson wrote:
> > > I have packaged subversion v0.14.5 r3578 for Mandrake Linux 9.0/Cooker, but
> > > stumbled upon an issue. The common practise in Mandrake Linux is to package
> > > the "*.so" files in a devel subpackage.
> >
> > Um. I suspect that you have that backwards. Typically, the regular package
> > has the *.so files, and -devel has the .a and .la files.
>
> A library libfoo.so goes in the -devel package since it's only needed
> when compiling against -lfoo, and is just a symlink to libfoo.x.y; just
> libfoo.so.x and libfoo.so.x.y go in the main package.
Gotcha. Somebody else pointed this out, too. I wasn't aware of the
convention. Thx.
> SVN treats ra_dav and ra_local as libraries, but really they are
> loadable modules - I think this is where the disconnect is happening.
They *can* be loadable modules. Normally, we just link them in. But if you
pass --enable-dso to ./configure, then it will stop linking them in. When
doing so, however, the DSO loader must be able to find them. I'm not sure
what the Linux rules are for that. I suspect the paths in ld.so.conf and/or
LD_LIBRARY_PATH.
How were the Mandrake packages set up? Do they use that configure switch?
[looking in packages/mandrake/ ...]
Ah. I see that it *is* used.
> For a loadable module, you always need the .so. (and can usually discard
> the .la and .a completely)
And since the switch *is* active, then yes: the .so will be needed.
> The loadable modules should really go in %{_libdir}/subversion/*.so,
> though you'd probably need to modify the ra loader to look in the right
> place.
Yah, sounds about right. Any ideas on how to get the system to "look in the
right place" ? It it simply a matter of passing an absolute path to the
loader?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The *.so files
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Wed, Nov 06, 2002 at 12:37:21PM -0800, Greg Stein wrote:
> On Wed, Nov 06, 2002 at 07:31:50PM +0100, Oden Eriksson wrote:
> > I have packaged subversion v0.14.5 r3578 for Mandrake Linux 9.0/Cooker, but
> > stumbled upon an issue. The common practise in Mandrake Linux is to package
> > the "*.so" files in a devel subpackage.
>
> Um. I suspect that you have that backwards. Typically, the regular package
> has the *.so files, and -devel has the .a and .la files.
A library libfoo.so goes in the -devel package since it's only needed
when compiling against -lfoo, and is just a symlink to libfoo.x.y; just
libfoo.so.x and libfoo.so.x.y go in the main package.
SVN treats ra_dav and ra_local as libraries, but really they are
loadable modules - I think this is where the disconnect is happening.
For a loadable module, you always need the .so. (and can usually discard
the .la and .a completely)
The loadable modules should really go in %{_libdir}/subversion/*.so,
though you'd probably need to modify the ra loader to look in the right
place.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The *.so files
Posted by Oden Eriksson <od...@kvikkjokk.net>.
onsdagen den 6 november 2002 21.37 skrev Greg Stein:
> On Wed, Nov 06, 2002 at 07:31:50PM +0100, Oden Eriksson wrote:
> > Hi.
> >
> > I have packaged subversion v0.14.5 r3578 for Mandrake Linux 9.0/Cooker,
> > but stumbled upon an issue. The common practise in Mandrake Linux is to
> > package the "*.so" files in a devel subpackage.
>
> Um. I suspect that you have that backwards. Typically, the regular package
> has the *.so files, and -devel has the .a and .la files.
Could very well be.
> > Now, this doesn't seem to work with subpackage since for example the
> > client won't work without these "*.so" files. What should I do, any
> > suggestions besides "breaking" the Mandrake way of doing things?
> >
> > My rpm packages are using parts and are based on the provided rpm spec
> > file, but provides these binary packages:
> >
> > libsubversion0-0.14.5-0.r3578.2mdk
> > libsubversion0-devel-0.14.5-0.r3578.2mdk
> > libsubversion0-static-devel-0.14.5-0.r3578.2mdk
>
> What does libsubversion0 install if not the *.so files?
It did contain all libraries not ending with *.so, now as I got sick of this I
threw those ones in too and everyone's happy. Mandrake has a similar "package
verifying tool" (rpmlint) as debian, and I got a lot of complaints about
these files not being in a devel package. Anyway the subversion packages in
Mandrake Linux Cooker should work now.
--
Regards // Oden Eriksson, Deserve-IT Networks
Check the "Modules For Apache2" status page at:
http://www.deserve-it.com/modules_for_apache2.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The *.so files
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Nov 06, 2002 at 07:31:50PM +0100, Oden Eriksson wrote:
> Hi.
>
> I have packaged subversion v0.14.5 r3578 for Mandrake Linux 9.0/Cooker, but
> stumbled upon an issue. The common practise in Mandrake Linux is to package
> the "*.so" files in a devel subpackage.
Um. I suspect that you have that backwards. Typically, the regular package
has the *.so files, and -devel has the .a and .la files.
> Now, this doesn't seem to work with subpackage since for example the client
> won't work without these "*.so" files. What should I do, any suggestions
> besides "breaking" the Mandrake way of doing things?
>
> My rpm packages are using parts and are based on the provided rpm spec file,
> but provides these binary packages:
>
> libsubversion0-0.14.5-0.r3578.2mdk
> libsubversion0-devel-0.14.5-0.r3578.2mdk
> libsubversion0-static-devel-0.14.5-0.r3578.2mdk
What does libsubversion0 install if not the *.so files?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The *.so files
Posted by Oden Eriksson <od...@kvikkjokk.net>.
onsdagen den 6 november 2002 23.59 skrev Michael Ballbach:
> He's talked to me about it briefly. We'll combine our efforts one way or
> another. He used my specs file as a basis.
>
> I did not like the idea of splitting up so's throughout development/lib
> prefixed packages because subversion uses a lot of them and there
> primary purpose is for subversion working. Maybe their
> secondary/tirtiary purpose is for the development of other programs.
>
> The devel package in the specs file in the subversion tree contains the
> linker scripts, headers, and the static libraries.
>
> The so's are broken up right now into several different packages based
> on the different functionality:
>
> subversion-base-0.14.5-3567.1mdk.i586.rpm
> subversion-client-common-0.14.5-3567.1mdk.i586.rpm
> subversion-client-local-0.14.5-3567.1mdk.i586.rpm
> subversion-client-dav-0.14.5-3567.1mdk.i586.rpm
> subversion-repos-0.14.5-3567.1mdk.i586.rpm
> subversion-server-0.14.5-3567.1mdk.i586.rpm
> subversion-devel-0.14.5-3567.1mdk.i586.rpm
> subversion-python-0.14.5-3567.1mdk.i586.rpm
>
> All are split out between these packages depending on their purpose.
> --enable-dso is used for this purpose. I'm neutral on the subversion
> folder in /usr/lib thing, since the subversion shared objects are
> obvious do to the 'svn' in the name.
I discussed this some on the cooker list and came up with that idea, put
shared modules perhaps in libexecdir? Right now I think most of the
developers at Mandrake are on leave, so it's hard to get help.
> I always figured the lib-something-mdk.x.rpm packages were meant for
> true-to-form libraries, used only for development. None of the
> subversion shared objects I can think of except the swig bindings in the
> python package can be said to be that way, so I did not consider using
> them. As an example, libperl.so is in the perl-base package, not in a
> libperl package.
In this case I may have wrongly assumed that this was the way to do it, I may
have to ditch my spec file and use yours, we'll see. I'm terrible new to this
software but I'll learn as I go along.
Ahh..., now that I come to think of it "rpmlint" which is used to verify and
check rpm packages, complained about compiled-in rpaths, could that maybe be
fixed somehow?
> On Wed, Nov 06, 2002 at 02:19:05PM -0800, Greg Stein wrote:
> > On Wed, Nov 06, 2002 at 07:31:50PM +0100, Oden Eriksson wrote:
> > > Hi.
> > >
> > > I have packaged subversion v0.14.5 r3578 for Mandrake Linux 9.0/Cooker,
> > > but stumbled upon an issue. The common practise in Mandrake Linux is to
> > > package the "*.so" files in a devel subpackage.
> >
> > Are you aware of the packages/rpm/mandrake-9.0/ directory in Subversion?
> > And if so, do you have patches for it? If not, then maybe your work
> > should be aligned with what is there? (I'd hate to have two divergent
> > Mandrake RPM setups)
--
Regards // Oden Eriksson, Deserve-IT Networks
Check the "Modules For Apache2" status page at:
http://www.deserve-it.com/modules_for_apache2.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The *.so files
Posted by Michael Ballbach <ba...@rten.net>.
He's talked to me about it briefly. We'll combine our efforts one way or
another. He used my specs file as a basis.
I did not like the idea of splitting up so's throughout development/lib
prefixed packages because subversion uses a lot of them and there
primary purpose is for subversion working. Maybe their
secondary/tirtiary purpose is for the development of other programs.
The devel package in the specs file in the subversion tree contains the
linker scripts, headers, and the static libraries.
The so's are broken up right now into several different packages based
on the different functionality:
subversion-base-0.14.5-3567.1mdk.i586.rpm
subversion-client-common-0.14.5-3567.1mdk.i586.rpm
subversion-client-local-0.14.5-3567.1mdk.i586.rpm
subversion-client-dav-0.14.5-3567.1mdk.i586.rpm
subversion-repos-0.14.5-3567.1mdk.i586.rpm
subversion-server-0.14.5-3567.1mdk.i586.rpm
subversion-devel-0.14.5-3567.1mdk.i586.rpm
subversion-python-0.14.5-3567.1mdk.i586.rpm
All are split out between these packages depending on their purpose.
--enable-dso is used for this purpose. I'm neutral on the subversion
folder in /usr/lib thing, since the subversion shared objects are
obvious do to the 'svn' in the name.
I always figured the lib-something-mdk.x.rpm packages were meant for
true-to-form libraries, used only for development. None of the
subversion shared objects I can think of except the swig bindings in the
python package can be said to be that way, so I did not consider using
them. As an example, libperl.so is in the perl-base package, not in a
libperl package.
On Wed, Nov 06, 2002 at 02:19:05PM -0800, Greg Stein wrote:
> On Wed, Nov 06, 2002 at 07:31:50PM +0100, Oden Eriksson wrote:
> > Hi.
> >
> > I have packaged subversion v0.14.5 r3578 for Mandrake Linux 9.0/Cooker, but
> > stumbled upon an issue. The common practise in Mandrake Linux is to package
> > the "*.so" files in a devel subpackage.
>
> Are you aware of the packages/rpm/mandrake-9.0/ directory in Subversion? And
> if so, do you have patches for it? If not, then maybe your work should be
> aligned with what is there? (I'd hate to have two divergent Mandrake RPM
> setups)
--
Michael Ballbach, N0ZTQ
ballbach@rten.net -- PGP KeyID: 0xA05D5555
http://www.rten.net/
Re: The *.so files
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Nov 06, 2002 at 07:31:50PM +0100, Oden Eriksson wrote:
> Hi.
>
> I have packaged subversion v0.14.5 r3578 for Mandrake Linux 9.0/Cooker, but
> stumbled upon an issue. The common practise in Mandrake Linux is to package
> the "*.so" files in a devel subpackage.
Are you aware of the packages/rpm/mandrake-9.0/ directory in Subversion? And
if so, do you have patches for it? If not, then maybe your work should be
aligned with what is there? (I'd hate to have two divergent Mandrake RPM
setups)
Thanks,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org