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-09-2008, 12:39 PM
Ralf Corsepius
 
Default Static Library Policy Draft Changes

On Wed, 2008-04-09 at 07:37 -0400, Jesse Keating wrote:
> On Tue, 2008-04-08 at 23:12 -0400, Bill Nottingham wrote:
> > I'd rather just require them to be in -static instead of -static-noshared
> > - they can still be tracked that way.
>
> The problem (as described to me) is that if you put them in -static, and
> you BR -static, you then potentially link against /all/ the static
> libraries, even those that have shared alternatives.
How that? Our rule has been that *-static must Require *-devel, i.e.
unless a package is playing nasty games with linking (or this packaging
rule is being obeyed), it will always link dynamically.

> The motivation was
> to isolate the static libraries which have no shared alternative from
> those that do.
>
> We can still "track" things which BR -static-noshared just as easily as
> we can track those that BR -static.
I still fail to see the usefulness of this.

Our logic had been: Client-packages who intentionally want to link
statically, must BR: *-static, those who don't care should BR: *-devel.

With your approach above, client-packages will have to care about
characteristics of a package providing a static library.

This doesn't make any sense to me on the client-side.

Ralf


--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-09-2008, 01:27 PM
Jesse Keating
 
Default Static Library Policy Draft Changes

On Wed, 2008-04-09 at 14:39 +0200, Ralf Corsepius wrote:
> > The problem (as described to me) is that if you put them in -static, and
> > you BR -static, you then potentially link against /all/ the static
> > libraries, even those that have shared alternatives.
> How that? Our rule has been that *-static must Require *-devel, i.e.
> unless a package is playing nasty games with linking (or this packaging
> rule is being obeyed), it will always link dynamically.

Since spot was the person who described it to me, perhaps it would be
best to get his input here. The way he stated it was that if there were
static libs around at link time, they would get automatically linked,
even if the didn't want them to.

>
> > The motivation was
> > to isolate the static libraries which have no shared alternative from
> > those that do.
> >
> > We can still "track" things which BR -static-noshared just as easily as
> > we can track those that BR -static.
> I still fail to see the usefulness of this.
>
> Our logic had been: Client-packages who intentionally want to link
> statically, must BR: *-static, those who don't care should BR: *-devel.
>
> With your approach above, client-packages will have to care about
> characteristics of a package providing a static library.
>
> This doesn't make any sense to me on the client-side.

It is a minor annoyance on the client side, but the client side /should/
know if they are linking to anything static. In fact, if they do, they
have to be on the initialcc of said static package. It's an extra
burden you take on by linking statically.

--
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-09-2008, 01:44 PM
"Tom "spot" Callaway"
 
Default Static Library Policy Draft Changes

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.
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.
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.

~spot

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

On Wed, 2008-04-09 at 09:27 -0400, Jesse Keating wrote:
> Since spot was the person who described it to me, perhaps it would be
> best to get his input here. The way he stated it was that if there
> were
> static libs around at link time, they would get automatically linked,
> even if the didn't want them to.
>
A lot of packages will look first for static libraries, then if (and
only if) they are not found, look for shared libraries. By splitting
into static and static-noshared, we can safely put in -devel and
-static-noshared and avoid this confusion.

~spot

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

On Wed, 2008-04-09 at 09:47 -0400, Tom "spot" Callaway wrote:
> On Wed, 2008-04-09 at 09:27 -0400, Jesse Keating wrote:
> > Since spot was the person who described it to me, perhaps it would be
> > best to get his input here. The way he stated it was that if there
> > were
> > static libs around at link time, they would get automatically linked,
> > even if the didn't want them to.
> >
> A lot of packages will look first for static libraries, then if (and
> only if) they are not found, look for shared libraries.
Examples? I am not aware of any such case.

Also, this will never happen in a chroot unless a package BR:'s *-static
or if a *-devel contains a static library.

> By splitting
> into static and static-noshared, we can safely put in -devel and
> -static-noshared and avoid this confusion.

Which confusion? I don't see any such confusion. The only situation such
case may occur is with packages whose maintainers have been ignorant on
the *-static/*-devel rule so far.

Ralf


--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-09-2008, 02:33 PM
Bill Nottingham
 
Default Static Library Policy Draft Changes

Tom spot Callaway (tcallawa@redhat.com) said:
> > Since spot was the person who described it to me, perhaps it would be
> > best to get his input here. The way he stated it was that if there
> > were
> > static libs around at link time, they would get automatically linked,
> > even if the didn't want them to.
>
> A lot of packages will look first for static libraries, then if (and
> only if) they are not found, look for shared libraries. By splitting
> into static and static-noshared, we can safely put in -devel and
> -static-noshared and avoid this confusion.

That's not the case for anything that just passes -l<foo>. Can't
we just fix those packages?

Bill

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-09-2008, 02:40 PM
Rex Dieter
 
Default Static Library Policy Draft Changes

Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:

Since spot was the person who described it to me, perhaps it would be
best to get his input here. The way he stated it was that if there
were
static libs around at link time, they would get automatically linked,
even if the didn't want them to.

A lot of packages will look first for static libraries, then if (and
only if) they are not found, look for shared libraries. By splitting
into static and static-noshared, we can safely put in -devel and
-static-noshared and avoid this confusion.


That's not the case for anything that just passes -l<foo>. Can't
we just fix those packages?


+1 to bill's comment. I see static-noshared as nothing but a hack to
get around what could/should be fixed in the offending packages.


Unless there is some other purpose to it that I'm missing. Heightened
paranoia, err, verification about what is being statically linked?


-- Rex

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-09-2008, 02:44 PM
Rex Dieter
 
Default Static Library Policy Draft Changes

Tom "spot" Callaway wrote:

On Wed, 2008-04-09 at 14:17 +0200, Hans de Goede wrote:


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:

> ...

Thanks, I think I finally have a grasp of all the motivations here, and
agree the new draft is the best way forward.


-- Rex

p.s. static libraries suck

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-10-2008, 02:35 AM
Jesse Keating
 
Default Static Library Policy Draft Changes

On Wed, 2008-04-09 at 16:10 +0200, Ralf Corsepius wrote:
> Also, this will never happen in a chroot unless a package BR:'s *-static
> or if a *-devel contains a static library.
>
> > By splitting
> > into static and static-noshared, we can safely put in -devel and
> > -static-noshared and avoid this confusion.
>
> Which confusion? I don't see any such confusion. The only situation such
> case may occur is with packages whose maintainers have been ignorant on
> the *-static/*-devel rule so far.

For the case where you have some shared, some static with matching
shared, and some static only:

If you put the static only in -devel, we can't reasonably detect all the
things that link against the static library. We'd have to investigate
anything that BRs the -devel package. If you put the static only in
with the other statics in -static you then have all the statics in the
chroot and run the risk that spot talks about of accidentally statically
linking to things that have shared alternatives.

--
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, 02:54 AM
Bill Nottingham
 
Default Static Library Policy Draft Changes

Jesse Keating (jkeating@redhat.com) said:
> For the case where you have some shared, some static with matching
> shared, and some static only:
>
> If you put the static only in -devel, we can't reasonably detect all the
> things that link against the static library. We'd have to investigate
> anything that BRs the -devel package. If you put the static only in
> with the other statics in -static you then have all the statics in the
> chroot and run the risk that spot talks about of accidentally statically
> linking to things that have shared alternatives.

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.

Bill

--
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 09:40 AM.

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