FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 04-09-2010, 08:17 AM
Tomas Mraz
 
Default Moving libcrypto.so.* back to /lib

So I got convinced that libcrypto.so.* should be moved back to /lib in
the https://bugzilla.redhat.com/show_bug.cgi?id=559953 The libssl.so.*
will stay in /usr/lib though.

I will do that change in F14 packages. Till Maas asked me for this
change also in F13, but I am a little hesitant to do this as I am afraid
of regressions. Do you think this change could break things in F13?
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2010, 01:44 PM
Adam Jackson
 
Default Moving libcrypto.so.* back to /lib

On Fri, 2010-04-09 at 10:17 +0200, Tomas Mraz wrote:
> So I got convinced that libcrypto.so.* should be moved back to /lib in
> the https://bugzilla.redhat.com/show_bug.cgi?id=559953 The libssl.so.*
> will stay in /usr/lib though.
>
> I will do that change in F14 packages. Till Maas asked me for this
> change also in F13, but I am a little hesitant to do this as I am afraid
> of regressions. Do you think this change could break things in F13?

It shouldn't. DSO lookup is by soname, not by path.

The only thing that could break is if a package had a file dependency on
the old path. Which is a ragingly stupid thing to do, so anyone it does
break deserves it.

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2010, 03:21 PM
"Richard W.M. Jones"
 
Default Moving libcrypto.so.* back to /lib

On Fri, Apr 09, 2010 at 10:17:25AM +0200, Tomas Mraz wrote:
> So I got convinced that libcrypto.so.* should be moved back to /lib in
> the https://bugzilla.redhat.com/show_bug.cgi?id=559953 The libssl.so.*
> will stay in /usr/lib though.
>
> I will do that change in F14 packages. Till Maas asked me for this
> change also in F13, but I am a little hesitant to do this as I am afraid
> of regressions. Do you think this change could break things in F13?

It'll temporarily break libguestfs, but a simple rebuild will fix it.
If you are a provenpackager, feel free to bump and rebuild it
yourself.

libguestfs builds its appliance on the fly by concatenating together
files [library files, binaries and data files] from the host. We
express this requirement by mapping the location of those files into
dependencies.

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2010, 03:26 PM
Chris Adams
 
Default Moving libcrypto.so.* back to /lib

Once upon a time, Richard W.M. Jones <rjones@redhat.com> said:
> libguestfs builds its appliance on the fly by concatenating together
> files [library files, binaries and data files] from the host. We
> express this requirement by mapping the location of those files into
> dependencies.

Why can't it just depend on libcrypto.so.<vesion>, and then use the
linker to find the libraries at run-time? Depending on fixed paths
seems like a bad idea.
--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2010, 04:01 PM
Till Maas
 
Default Moving libcrypto.so.* back to /lib

On Fri, Apr 09, 2010 at 04:21:53PM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 09, 2010 at 10:17:25AM +0200, Tomas Mraz wrote:
> > So I got convinced that libcrypto.so.* should be moved back to /lib in
> > the https://bugzilla.redhat.com/show_bug.cgi?id=559953 The libssl.so.*
> > will stay in /usr/lib though.
> >
> > I will do that change in F14 packages. Till Maas asked me for this
> > change also in F13, but I am a little hesitant to do this as I am afraid
> > of regressions. Do you think this change could break things in F13?
>
> It'll temporarily break libguestfs, but a simple rebuild will fix it.
> If you are a provenpackager, feel free to bump and rebuild it
> yourself.
>
> libguestfs builds its appliance on the fly by concatenating together
> files [library files, binaries and data files] from the host. We
> express this requirement by mapping the location of those files into
> dependencies.

According to repoquery, libguestfs is the only package doing this:
$ repoquery --releasever 13 --whatrequires /usr/lib*/libcrypto.so*
libguestfs-1:1.0.85-2.fc13.4.i686
libguestfs-1:1.0.85-2.fc13.4.x86_64

You may need a patched repoquery to use the releasever commandline
option on F12 or earlier, but for F13 it can be skipped anyhow.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2010, 04:54 PM
"Richard W.M. Jones"
 
Default Moving libcrypto.so.* back to /lib

On Fri, Apr 09, 2010 at 10:26:01AM -0500, Chris Adams wrote:
> Once upon a time, Richard W.M. Jones <rjones@redhat.com> said:
> > libguestfs builds its appliance on the fly by concatenating together
> > files [library files, binaries and data files] from the host. We
> > express this requirement by mapping the location of those files into
> > dependencies.
>
> Why can't it just depend on libcrypto.so.<vesion>, and then use the
> linker to find the libraries at run-time?

Because it's not linking with the library, it's copying it (along with
many other non-library-like files) into an appliance.

> Depending on fixed paths seems like a bad idea.

It depends on fixed paths because fixed paths are used to build the
appliance. Therefore the dependencies tell us when something isn't
going to work at runtime, instead of having the package silently
broken by changes such as the one discussed in the OP.

Now you may think that this is a bad way to build an appliance, but no
one has come up with any better ideas for that so far.

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2010, 05:19 PM
Chris Adams
 
Default Moving libcrypto.so.* back to /lib

Once upon a time, Richard W.M. Jones <rjones@redhat.com> said:
> On Fri, Apr 09, 2010 at 10:26:01AM -0500, Chris Adams wrote:
> > Once upon a time, Richard W.M. Jones <rjones@redhat.com> said:
> > > libguestfs builds its appliance on the fly by concatenating together
> > > files [library files, binaries and data files] from the host. We
> > > express this requirement by mapping the location of those files into
> > > dependencies.
> >
> > Why can't it just depend on libcrypto.so.<vesion>, and then use the
> > linker to find the libraries at run-time?
>
> Because it's not linking with the library, it's copying it (along with
> many other non-library-like files) into an appliance.

So?

$ ldconfig -p | grep "libcrypto.so." | sed 's/.* => //'
/lib/libcrypto.so.8

Granted, it would take another line or two to handle multilib, but
that's it.

If you wanted to get fancy, you could use the C compiler (avoids having
to directly deal with multilib), but that requires -devel packages
installed. Even better would be to do this at RPM build time; link an
empty program against all of the libraries you need and just install the
resulting no-op binary somewhere. Then use "ldd" to find all the
dependencies (like the old mkinitrd script did).

$ echo 'main(){}' | cc -lcrypto -o findlib -x c -
$ ldd findlib
linux-vdso.so.1 => (0x00007fffdab7c000)
libcrypto.so.8 => /usr/lib64/libcrypto.so.8 (0x000000354ae00000)
libc.so.6 => /lib64/libc.so.6 (0x00000038f2200000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000038f2a00000)
libz.so.1 => /lib64/libz.so.1 (0x00000038f3200000)
/lib64/ld-linux-x86-64.so.2 (0x00000038f1e00000)

You copy everything from the ldd output (except for the VDSO bit
obviously), which should make sure you get any dependencies (except for
dlopen() libraries, but that is actually hard to handle in an automated
way).

> Now you may think that this is a bad way to build an appliance, but no
> one has come up with any better ideas for that so far.

It isn't hard to find a shared library without hard-coding static paths.
--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2010, 05:25 PM
Chuck Anderson
 
Default Moving libcrypto.so.* back to /lib

On Fri, Apr 09, 2010 at 10:17:25AM +0200, Tomas Mraz wrote:
> So I got convinced that libcrypto.so.* should be moved back to /lib in
> the https://bugzilla.redhat.com/show_bug.cgi?id=559953 The libssl.so.*
> will stay in /usr/lib though.
>
> I will do that change in F14 packages. Till Maas asked me for this
> change also in F13, but I am a little hesitant to do this as I am afraid
> of regressions. Do you think this change could break things in F13?

Will it break anaconda?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2010, 05:42 PM
Adam Jackson
 
Default Moving libcrypto.so.* back to /lib

On Fri, 2010-04-09 at 17:54 +0100, Richard W.M. Jones wrote:
> On Fri, Apr 09, 2010 at 10:26:01AM -0500, Chris Adams wrote:
> > Depending on fixed paths seems like a bad idea.
>
> It depends on fixed paths because fixed paths are used to build the
> appliance. Therefore the dependencies tell us when something isn't
> going to work at runtime, instead of having the package silently
> broken by changes such as the one discussed in the OP.
>
> Now you may think that this is a bad way to build an appliance, but no
> one has come up with any better ideas for that so far.

I thought I did suggest how to do this better:

http://lists.fedoraproject.org/pipermail/devel/2010-February/131091.html

Is there a reason why that won't work?

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2010, 06:35 PM
"Richard W.M. Jones"
 
Default Moving libcrypto.so.* back to /lib

On Fri, Apr 09, 2010 at 01:42:54PM -0400, Adam Jackson wrote:
> On Fri, 2010-04-09 at 17:54 +0100, Richard W.M. Jones wrote:
> > On Fri, Apr 09, 2010 at 10:26:01AM -0500, Chris Adams wrote:
> > > Depending on fixed paths seems like a bad idea.
> >
> > It depends on fixed paths because fixed paths are used to build the
> > appliance. Therefore the dependencies tell us when something isn't
> > going to work at runtime, instead of having the package silently
> > broken by changes such as the one discussed in the OP.
> >
> > Now you may think that this is a bad way to build an appliance, but no
> > one has come up with any better ideas for that so far.
>
> I thought I did suggest how to do this better:
>
> http://lists.fedoraproject.org/pipermail/devel/2010-February/131091.html
>
> Is there a reason why that won't work?

It's not just libraries, the appliance gets built from many different
types of files. To do this quickly, in 1/5th of a second, we start
with a list of filenames[0] (wildcards, actually) that we want to pick
up from the host system. We use a C program[1], that for speed
reasons doesn't call out to any external programs, to generate the
cpio-format initramfs.

It turns out that binaries moving between /s?bin and /usr/s?bin, or
libraries moving, are quite rare events. In the very few cases where
there are libraries that frequently churn we've added exceptions for
them. We added an exception for libntfs-3g.so more than a month ago,
and that's been it since.

Patches welcomed if you want to have a go at solving a very
challenging problem better.

Rich.

[0] http://annexia.org/tmp/hostfiles.txt

[1] http://git.annexia.org/?p=libguestfs.git;a=blob;f=appliance/libguestfs-supermin-helper.c;hb=HEAD

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 02:02 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org