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 11-13-2010, 06:26 PM
Siddhesh Poyarekar
 
Default Updates to static library packages

Hi,

I maintain LibRaw, which is only a static library -- upstream has
rejected the idea of maintaining dynamic libs since they would have to
take care of ABI compatibility across releases.

I wanted to know if there are any other only-static libraries out
there and how they maintainers manage releases. I had packaged this to
build Shotwell 0.6.x but I understand there are a couple of other apps
too that build against this now. Do i have to keep track of all of
them and coordinate releases with them, i.e. announce an update, have
them test and then push a build? Or do I just go ahead and build in
rawhide and then wait for someone to complain?

Thanks,
Siddhesh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-13-2010, 10:38 PM
Michel Alexandre Salim
 
Default Updates to static library packages

Hi Siddhesh,

On Sun, 14 Nov 2010 00:56:47 +0530, Siddhesh Poyarekar wrote:

> I wanted to know if there are any other only-static libraries out there
> and how they maintainers manage releases. I had packaged this to build
> Shotwell 0.6.x but I understand there are a couple of other apps too
> that build against this now. Do i have to keep track of all of them and
> coordinate releases with them, i.e. announce an update, have them test
> and then push a build? Or do I just go ahead and build in rawhide and
> then wait for someone to complain?
I maintain llvm, which *used* to be static-only. The guideline:
http://fedoraproject.org/wiki/
PackagingGuidelines#Packaging_Static_Libraries

does not discuss update policies, but luckily for LLVM they update on a
predictable schedule, once a year, and the dependent packages normally
are quite good at keeping track.

I'd say do try a rebuild of affected packages yourself, and notify the
maintainers only in case there is a breakage and coordinate on what to do
(otherwise they'd get an unpleasant FTBFS report).

I just noticed, actually, that shotwell incorrectly depends on LibRaw-
devel rather than LibRaw-static. Fixing it now :P

Incidentally, does anyone know how to keep track of which package lists
something as a *build* requirement? repoquery has --whatrequires and
--tree-whatrequires, and has an --srpm option that seems promising, but
does not seem to do the trick.

Best Regards,

--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email: salimma@fedoraproject.org | GPG key ID: 78884778
Jabber: hircus@jabber.ccc.de | IRC: hircus@irc.freenode.net

() ascii ribbon campaign - against html e-mail
/ www.asciiribbon.org - against proprietary attachments

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-14-2010, 12:12 AM
Rex Dieter
 
Default Updates to static library packages

Michel Alexandre Salim wrote:

> Incidentally, does anyone know how to keep track of which package lists
> something as a *build* requirement? repoquery has --whatrequires and
> --tree-whatrequires, and has an --srpm option that seems promising, but
> does not seem to do the trick.

Thanks to http://yum.baseurl.org/wiki/RepoQuery

If you need to figure out which srpms have a buildrequirement on a
particular pkgname run:
repoquery --archlist=src --repoid=some_repo_with_srpms
-q --whatrequires pkgname

-- Rex

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-14-2010, 11:31 AM
Michel Alexandre Salim
 
Default Updates to static library packages

On Sat, 13 Nov 2010 19:12:18 -0600, Rex Dieter wrote:

> Thanks to http://yum.baseurl.org/wiki/RepoQuery
>
> If you need to figure out which srpms have a buildrequirement on a
> particular pkgname run:
> repoquery --archlist=src --repoid=some_repo_with_srpms
> -q --whatrequires pkgname
>
Aha! Thanks.

--
Michel Alexandre Salim

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-14-2010, 05:48 PM
Siddhesh Poyarekar
 
Default Updates to static library packages

On Sat, Nov 13, 2010 at 11:38:50PM +0000, Michel Alexandre Salim wrote:
> I'd say do try a rebuild of affected packages yourself, and notify the
> maintainers only in case there is a breakage and coordinate on what to do
> (otherwise they'd get an unpleasant FTBFS report).
>

That was helpful, thank you

--
Siddhesh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-17-2010, 09:35 PM
Kevin Kofler
 
Default Updates to static library packages

Siddhesh Poyarekar wrote:
> I maintain LibRaw, which is only a static library -- upstream has
> rejected the idea of maintaining dynamic libs since they would have to
> take care of ABI compatibility across releases.
>
> I wanted to know if there are any other only-static libraries out
> there and how they maintainers manage releases. I had packaged this to
> build Shotwell 0.6.x but I understand there are a couple of other apps
> too that build against this now. Do i have to keep track of all of
> them and coordinate releases with them, i.e. announce an update, have
> them test and then push a build? Or do I just go ahead and build in
> rawhide and then wait for someone to complain?

You can just build a shared library with custom sonames (probably a new
soname per version, unfortunately). I think that's actually the sanest
approach to handle this problem.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 11:40 PM.

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