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 Packaging

 
 
LinkBack Thread Tools
 
Old 04-10-2008, 03:17 AM
Jesse Keating
 
Default Static Library Policy Draft Changes

On Wed, 2008-04-09 at 22:54 -0400, Bill Nottingham wrote:
> The only way this can happen (AFAIK) is if they're linked by:
>
> - explicitly listing %{_libdir}/libfoo.a on the link line
> - explicitly passing -Wl,-bstatic
>
> Either of these things should be auditable.

Ok, if that's the case, we can relax the need for the -noshared
subpackage. I'm really just going on the word of others here.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-10-2008, 07:50 AM
Patrice Dumas
 
Default Static Library Policy Draft Changes

On Wed, Apr 09, 2008 at 09:44:36AM -0400, Tom spot Callaway wrote:
>
> 2. When a package goes from only providing static libraries to providing
> some shared libraries (but not all), we want to be able to track these.

Does it happens? I guess that this is raised by a real life example, but
is there more than one package providing some library as shared+static
and some only as static?

--
Pat

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-10-2008, 08:19 AM
Ralf Corsepius
 
Default Static Library Policy Draft Changes

On Wed, 2008-04-09 at 09:44 -0400, Tom "spot" Callaway wrote:
> On Wed, 2008-04-09 at 14:17 +0200, Hans de Goede wrote:
> > Toshio Kuratomi wrote:
> > > Tom "spot" Callaway wrote:
> > > From item #3:
> > > """
> > > When a package only provides static libraries you can place all the
> > > static library files in the *-devel subpackage. When doing this you also
> > > have to have a virtual Provide for the *-static and *-static-noshared
> > > packages:
> > > """
> > >
> > > It seems like we should only have a Provide for *-static-noshared as
> > > this is a special case of item #2. Thoughts on that?
> > >
> >
> > I actually think we only should have a Provide for *-static, so that people who
> > want to use static libs now and in the future (when there may be a shared
> > version) , can guarantee they will get the static version by BuildRequiring the
> > -static, since very few packages will ever have a real *-static-noshared,
> > having a virtual provides for this feels wrong.
>
> The problem is two-fold:
>
> 1. We want to be able to track when packages are building against static
> libraries, whether they are static or static-noshared.
What for? IMO this is simply bureaucracy.

> 2. When a package goes from only providing static libraries to providing
> some shared libraries (but not all), we want to be able to track these.
But this isn't what your proposal does.

Your proposal pesters/pollutes library-clients *.specs with a library's
provider's packaging details, these library-clients are not interested
in.

> If we have these packages BuildRequire the static provide, that won't be
> correct anymore (we want them to use the shared libraries +
> static-noshared).
>
> Realistically, what Toshio says is correct, we strictly speaking only
> need the Provide for *-static-noshared there. I kept the other *-static
> provide since it is how we used to do it.
This is something completely different.

Here, you seem to be talking about "Additionally providing
*-static-noshared" and NOT to pester library-clients with BR:
*-static-nonshared".

In real world, no library-client who needs a static library, needs know
if this library is being provided "*-static-noshared" or "*-static".
=> Such kind of Provides is useless to the library-client.

Ralf


--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-10-2008, 08:23 AM
Ralf Corsepius
 
Default Static Library Policy Draft Changes

On Thu, 2008-04-10 at 09:50 +0200, Patrice Dumas wrote:
> On Wed, Apr 09, 2008 at 09:44:36AM -0400, Tom spot Callaway wrote:
> >
> > 2. When a package goes from only providing static libraries to providing
> > some shared libraries (but not all), we want to be able to track these.
>
> Does it happens?
This happens all the time.

The critical case would be the opposite: A package going from providing
shared libs to providing static libs only.

I have never seen this happen, but provides the craziness of some
upstreams, I would not exclude this to happen.

> I guess that this is raised by a real life example, but
> is there more than one package providing some library as shared+static
> and some only as static?
This isn't much of a problem.

* If a library's client package BR:'s *-devel,
it will pick up the shared library during the next rebuild.

* If a library's client package BR:'s *-static,
it will bomb out during the next rebuild.


The only issue is library-client packages not being automatically
notified that they might need to be rebuilt.

To me, this is a negligible, minor issue, your proposal is too heavy
weight for to find it appropriate.

We have way more serious packaging issues than this minor detail.

Ralf




--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-10-2008, 11:38 AM
Patrice Dumas
 
Default Static Library Policy Draft Changes

On Thu, Apr 10, 2008 at 10:23:54AM +0200, Ralf Corsepius wrote:
>
> On Thu, 2008-04-10 at 09:50 +0200, Patrice Dumas wrote:
> > On Wed, Apr 09, 2008 at 09:44:36AM -0400, Tom spot Callaway wrote:
> > >
> > > 2. When a package goes from only providing static libraries to providing
> > > some shared libraries (but not all), we want to be able to track these.
> >
> > Does it happens?
> This happens all the time.

I don't think so. Currently there are no such packages in fedora, with a
mix of shared and static libs in -devel.

I did the following:
repoquery --whatprovides '*-static' --qf '%{name}' > provides_static_names
for file in `grep -v -- '-static$' provides_static_names`; do repoquery -ql $file | grep '.so$'; done
/usr/lib/libruby.so
/usr/lib/libfrysk-junit.so
/usr/lib/libnettle.so
/usr/libexec/p7zip/7z.so

I filled a bug against nettle-devel, p7zip and frysk are false positives
(they provides a file ending in -static), so ruby-devel is the only package
doing that sort of thing, but the libraries have different names:
/usr/lib/libruby-static.a
/usr/lib/libruby.so


But maybe you are referring to a package providing only static libraries
then providing shared libraries (in -devel) and static libraries (in
-static). In that case, I think it is not different from the case when a
static library is rebuilt and therefoer the package linking against that
library needs to be rebuilt too. This is covered by the guidelines:

"If you link statically against a library, add yourself to the initialcc
list for the library so you can watch for any security issues or bug
fixes for which you'd want to rebuild your package against a new version
of the library. Here are instructions for making that request."

In my opinion this also covers going from static to shared, in that case
the maitainer can fill himself a bug when going shared.

> The critical case would be the opposite: A package going from providing
> shared libs to providing static libs only.
>
> I have never seen this happen, but provides the craziness of some
> upstreams, I would not exclude this to happen.

Indeed, it may happen, but just following the existing guidelines in
that case seems enough to me.

> * If a library's client package BR:'s *-devel,
> it will pick up the shared library during the next rebuild.
>
> * If a library's client package BR:'s *-static,
> it will bomb out during the next rebuild.
>
>
> The only issue is library-client packages not being automatically
> notified that they might need to be rebuilt.

As I said above, having the maintainer fill a bug when going shared
should solve this issue, since packagers should already be in CC.

The only issue I see is when a packager doesn't know that he is building
against a static library.

My investigations show that (with ruby excluded), the following -devel
packages consist only of static libs and have dependent packages:

--> factory-devel
libfac-0:3.0.3-2.fc9.src
Macaulay2-0:1.1-1.fc9.src
--> flam3-devel
qosmic-0:1.3.1-3.fc9.src
--> g2clib-devel
ncl-0:5.0.0-10.fc9.src
--> libassuan-devel
gnupg2-0:2.0.9-1.fc9.src
dirmngr-0:1.0.1-2.fc9.src
--> libfac-devel
Macaulay2-0:1.1-1.fc9.src
--> libnet-devel
tcptraceroute-0:1.5-0.5.beta7.fc9.src
dsniff-0:2.4-0.2.b1.fc9.src
etherbat-0:1.0.1-4.fc9.src
libnids-0:1.22-4.fc9.src
heartbeat-0:2.1.3-1.fc9.src
ettercap-0:0.7.3-22.fc9.src
isic-0:0.07-2.fc9.src
intuitively-0:0.7-13.fc9.src
firewalk-0:5.0-2.fc9.src

Also libmimedir-devel and osiv-devel requires the corresponding -static
subpackages since there are no corresponding shared libraries, and
uulib-static provides uulib-devel. This adds:

# repoquery --whatrequires uulib-devel --archlist=src
klibido-0:0.2.5-10.fc9.src
# repoquery --whatrequires uulib-static --archlist=src
nget-0:0.27.1-8.fc9.src
# repoquery --whatrequires libmimedir-devel --archlist=src
librra-0:0.11-2.fc9.src

Also I noticed that some packages BuildRequires static packages, I
filled few bugs, but most of the time, the -devel is also BuildRequires,
and I guess that there is a good reason to BR the static sub package.

--
Pat

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-11-2008, 09:40 AM
"Richard W.M. Jones"
 
Default Static Library Policy Draft Changes

On Tue, Apr 08, 2008 at 05:51:31PM -0400, Tom spot Callaway wrote:
> As promised, here is my new proposed draft for handling static libs:
>
> http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy
>
> I know that it won't make everyone happy (it doesn't just leave static
> bits in -devel), but we really do want to track who is building against
> static libraries.

Can you remove the perjorative term "deficiency", since OCaml has good
reasons for statically linking to do with software safety.

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-11-2008, 09:46 AM
"Richard W.M. Jones"
 
Default Static Library Policy Draft Changes

On Fri, Apr 11, 2008 at 10:40:05AM +0100, Richard W.M. Jones wrote:
> On Tue, Apr 08, 2008 at 05:51:31PM -0400, Tom spot Callaway wrote:
> > As promised, here is my new proposed draft for handling static libs:
> >
> > http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy
> >
> > I know that it won't make everyone happy (it doesn't just leave static
> > bits in -devel), but we really do want to track who is building against
> > static libraries.
>
> Can you remove the perjorative term "deficiency", since OCaml has good
> reasons for statically linking to do with software safety.

Don't worry - I found I could edit that page myself.

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-22-2008, 04:41 PM
"Tom "spot" Callaway"
 
Default Static Library Policy Draft Changes

On Wed, 2008-04-09 at 23:17 -0400, Jesse Keating wrote:
> On Wed, 2008-04-09 at 22:54 -0400, Bill Nottingham wrote:
> > The only way this can happen (AFAIK) is if they're linked by:
> >
> > - explicitly listing %{_libdir}/libfoo.a on the link line
> > - explicitly passing -Wl,-bstatic
> >
> > Either of these things should be auditable.
>
> Ok, if that's the case, we can relax the need for the -noshared
> subpackage. I'm really just going on the word of others here.

I've rewritten it to remove the need for the -noshared subpackage:

http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy

In plain English:

When shared libraries exist, static libraries go into -static (whether
they have a shared library counterpart or not). Any packages which link
against static libraries must BuildRequire: the -static subpackage. If
(and only if) there are no shared libraries provided, then the static
libraries can go in -devel, but -devel must also provide -static.

It is worth noting that this draft is no longer significantly different
from the current policies, but is a clarification to try and eliminate
confusion.

~spot

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-22-2008, 05:19 PM
Patrice Dumas
 
Default Static Library Policy Draft Changes

On Tue, Apr 22, 2008 at 12:41:02PM -0400, Tom spot Callaway wrote:
>
> I've rewritten it to remove the need for the -noshared subpackage:
>
> http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy
>
> If
> (and only if) there are no shared libraries provided, then the static
> libraries can go in -devel, but -devel must also provide -static.

I have 2 related questions, maybe they could be part of this, if they
hapen to need a guideline. It is in the case of no shared libraries
provided:

1. Is it permitted to have a subpackage called
mylib-static which holds what is generally in a devel subpackage, and
Provides: mylib-devel = %{version}-%{release}

2. Is it permitted to have the headers in
devel and the static library in -static and have
mylib-devel
Requires: mylib-static = %{version}-%{release}

--
Pat

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-22-2008, 05:25 PM
"Tom "spot" Callaway"
 
Default Static Library Policy Draft Changes

On Tue, 2008-04-22 at 19:19 +0200, Patrice Dumas wrote:
> 1. Is it permitted to have a subpackage called
> mylib-static which holds what is generally in a devel subpackage, and
> Provides: mylib-devel = %{version}-%{release}

No.

> 2. Is it permitted to have the headers in
> devel and the static library in -static and have
> mylib-devel
> Requires: mylib-static = %{version}-%{release}

Yes. But you'd still need to have any packages which link against the
static libraries BuildRequire: mylib-static.

~spot

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 

Thread Tools




All times are GMT. The time now is 06:44 AM.

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