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 12-30-2009, 07:56 PM
Kevin Kofler
 
Default packaging a static library

Martin Langhoff wrote:
> Let's focus on the important bit: we need a frozen version of a
> library (that, btw, is useful, and is not in Fedora yet :-) ). What's
> the best practice for that? I don't see why we'd need to embed it
> statically anywhere (except OFW of course).

It's just not allowed. Use the system version, audited or not. If you need
frozen, audited software, you need to go back to maintaining your own OLPC
branch of Fedora, just like RHEL branches off Fedora. Working directly with
upstream Fedora means working the upstream Fedora way. Using old components
just because they're audited is not the Fedora way, sorry.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-30-2009, 07:58 PM
Kevin Kofler
 
Default packaging a static library

Daniel Drake wrote:
> The upstream library is already in Fedora as a shared library.
> I guess the approach I will take is to install our audited version as a
> shared library under a different name (libtommath_olpc?) which the
> components will then dynamically link against.

While that at least conforms to our packaging guidelines, I think this is
still against Fedora policies, in particular the Fedora Objectives. We want
to ship the current software, not old audited one. Fedora is not a certified
distribution, it's an up-to-date distribution.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-30-2009, 08:02 PM
Kevin Kofler
 
Default packaging a static library

Daniel Drake wrote:
> OLPC has previously had a specific version of tomcrypt/tommath
> profesionally audited for security reasons. So we obviously want to
> stick with that version.

This is a bad idea and inconsistent with what Fedora is about. If you want
that sort of things, you need to go back to maintaining separate OLPC
branches. In Fedora, you're supposed to use the current version whenever
technically possible.

> A few packages we have in Fedora currently use this frozen, audited
> version - we do so by shipping duplicate copies of that source code
> within the individual packages, rather than linking against the dynamic
> systemwide equivalents.

This is not allowed and the packages MUST be fixed ASAP (in fact they should
never have passed review in the first place, this is a failure of our review
process). (And if you refuse to fix it, I'll have to escalate it to FESCo.)

> As we're now looking at making another package which uses yet another
> duplicate copy of this code base I'm wondering if we can do it better.

Yes, just use the system version.

> Could I add a package, named olpc-bios-crypto-devel (a subpackage of the
> to-be-packaged olpc-bios-crypto), which installs the .a files for the
> audited libraries somewhere on the system?

Static libraries suck, your later suggestion of a shared audited version is
better, but still the right solution is to just use the current version.

> Then the individual components that rely on this library (e.g. bitfrost,
> olpc-contents, olpc-bios-crypto) would have a BuildRequires dependency
> on olpc-bios-crypto-devel and build against the 'systemwide' static .a
> library files.
>
> Or am I going too far against common packaging practice at this point?

Yes. Common practice in Fedora is to just use current software and forget
about audits. Fedora is not a certified distribution.

> Any alternative suggestions?

See above.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-30-2009, 08:42 PM
"Tom "spot" Callaway"
 
Default packaging a static library

On 12/30/2009 03:58 PM, Kevin Kofler wrote:
> Daniel Drake wrote:
>> The upstream library is already in Fedora as a shared library.
>> I guess the approach I will take is to install our audited version as a
>> shared library under a different name (libtommath_olpc?) which the
>> components will then dynamically link against.
>
> While that at least conforms to our packaging guidelines, I think this is
> still against Fedora policies, in particular the Fedora Objectives. We want
> to ship the current software, not old audited one. Fedora is not a certified
> distribution, it's an up-to-date distribution.

FWIW, I'm pretty sure this is not against current Fedora policies,
assuming that the libtommath maintainer signs off on it and there is no
conflict between the two packages.

~spot

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-30-2009, 09:01 PM
Kevin Kofler
 
Default packaging a static library

Tom "spot" Callaway wrote:
> FWIW, I'm pretty sure this is not against current Fedora policies,
> assuming that the libtommath maintainer signs off on it and there is no
> conflict between the two packages.

I guess it's indeed not against the letter of the policies, it's still
against their spirit though. Compat packages make sense where they're
required for technical or licensing reasons (the latter case being
particularly annoying though). In this case, they're neither. And our
objectives are to ship the latest software, not an old version just because
it went through some sort of formal audit and/or certification.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-30-2009, 09:04 PM
Patrice Dumas
 
Default packaging a static library

On Wed, Dec 30, 2009 at 04:42:35PM -0500, Tom spot Callaway wrote:
>
> FWIW, I'm pretty sure this is not against current Fedora policies,
> assuming that the libtommath maintainer signs off on it and there is no
> conflict between the two packages.

Indeed, it is just a compat library (and I think that having a rightly
packaged static library alongside wouldn't be bad). Nothing in fedora,
however, should link against it, that would be against the guidelines,
and also not very fedora-like.

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-30-2009, 09:22 PM
"Tom "spot" Callaway"
 
Default packaging a static library

On 12/30/2009 05:01 PM, Kevin Kofler wrote:
> Tom "spot" Callaway wrote:
>> FWIW, I'm pretty sure this is not against current Fedora policies,
>> assuming that the libtommath maintainer signs off on it and there is no
>> conflict between the two packages.
>
> I guess it's indeed not against the letter of the policies, it's still
> against their spirit though. Compat packages make sense where they're
> required for technical or licensing reasons (the latter case being
> particularly annoying though). In this case, they're neither. And our
> objectives are to ship the latest software, not an old version just because
> it went through some sort of formal audit and/or certification.

Well, my concerns around this are:

1. That this library will be impossible to bugfix without losing its
"audit approval"
2. (A) That the OLPC dependent packages in Fedora which depend on this
library will want to link against this compat package rather than the
current revision
OR
2. (B) That the OLPC dependent packages in Fedora will also need to be
forked to link against this compat package rather than the current revision.

However, it is worth noting that the OLPC OS build is a Fedora Remix,
rather than a spin, so they may be able to get by with simply having the
compat libtommath-audited package (containing shared rather than static
libs) present, and not making any other changes in Fedora.

~spot

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

Thread Tools




All times are GMT. The time now is 07:36 AM.

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