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 10-07-2010, 06:12 PM
Toshio Kuratomi
 
Default Need feedback on what constitutes "unbundling" a library

Greetings all, I've just opened a ticket for the FPC to define what
constitutes unbundling of a library:
https://fedorahosted.org/fpc/ticket/19

I'm going to paste the question here for discussion so that the FPC doesn't
make this decision in a vacuum.

When we deal with bundled libraries there's some ambiguity as to what
changes represent "unbundling". The changes may also differ between
programming languages.

First the options that I see in descending order of intrusiveness into the
package:

1. Delete the bundled libraries so they aren't installed by the binary rpm.
2. Make sure that if bundled libraries are present in the final installed
rpm that:
1. They are not used by the rpm package
2. They are marked private in some way so that they are not used by
other rpm packages
3. Make sure that if bundled libraries are present in the final installed
rpm that they are not used by the rpm package

Here's a case in a python application that bundles but does so compliant to
option #2:
https://bugzilla.redhat.com/show_bug.cgi?id=549405

In this case, upstream is providing pieces of the python stdlib that may not
be present on older versions of python. They mark the copied stdlib modules
as private by prepending with a leading underscore. When run on a new
enough python, the stdlib version of the module is imported rather than the
bundled version. As a tangent, this upstream has set up importing of the
modules so that they only have to make the check for stdlib modules in one
place. Other upstreams I've seen have made the check each place that the
module is imported which can lead to inadvertant use of the bundled module
if they forget to make the check when adding new code.

In the case of other languages, it depends on whether the languages provide
a means of conditionally loading the bundled library vs the system library
if present and if they provide a means of marking the bundled library
private. For C libraries, for instance, I think this would require storing
the module in a directory outside of the standard library path and also
dlopening the bundled library if the program fails to dlopen the library
from the standard library path. Writing this from scratch for C libraries
and passing it to upstream is likely to be much more intrusive than writing
something like the above python application does and hence less likely to be
accepted by upstream. Upstream for C applications normally accept patches
to choose the system library or bundled library at buildtime instead of
runtime so doing the runtime detection also doesn't make as much sense there
as for python.

I think that allowing option #2 or better makes sense (ie: making sure the
bundled library never shows up on the filesystem at all would also be
acceptable) but I'd like to hear other input. For instance, I'm willing to
bet that some packages are doing #3 at the moment and would need to be
further modified to also mark the libraries private. And I also wonder if
anyone feels that #2 is not sufficient. Please speak up and tell me what
you think.

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 10-12-2010, 05:25 PM
Jon Ciesla
 
Default Need feedback on what constitutes "unbundling" a library

Toshio Kuratomi wrote:
> Greetings all, I've just opened a ticket for the FPC to define what
> constitutes unbundling of a library:
> https://fedorahosted.org/fpc/ticket/19
>
> I'm going to paste the question here for discussion so that the FPC doesn't
> make this decision in a vacuum.
>
> When we deal with bundled libraries there's some ambiguity as to what
> changes represent "unbundling". The changes may also differ between
> programming languages.
>
> First the options that I see in descending order of intrusiveness into the
> package:
>
> 1. Delete the bundled libraries so they aren't installed by the binary rpm.
> 2. Make sure that if bundled libraries are present in the final installed
> rpm that:
> 1. They are not used by the rpm package
> 2. They are marked private in some way so that they are not used by
> other rpm packages
> 3. Make sure that if bundled libraries are present in the final installed
> rpm that they are not used by the rpm package
>
> Here's a case in a python application that bundles but does so compliant to
> option #2:
> https://bugzilla.redhat.com/show_bug.cgi?id=549405
>
> In this case, upstream is providing pieces of the python stdlib that may not
> be present on older versions of python. They mark the copied stdlib modules
> as private by prepending with a leading underscore. When run on a new
> enough python, the stdlib version of the module is imported rather than the
> bundled version. As a tangent, this upstream has set up importing of the
> modules so that they only have to make the check for stdlib modules in one
> place. Other upstreams I've seen have made the check each place that the
> module is imported which can lead to inadvertant use of the bundled module
> if they forget to make the check when adding new code.
>
> In the case of other languages, it depends on whether the languages provide
> a means of conditionally loading the bundled library vs the system library
> if present and if they provide a means of marking the bundled library
> private. For C libraries, for instance, I think this would require storing
> the module in a directory outside of the standard library path and also
> dlopening the bundled library if the program fails to dlopen the library
> from the standard library path. Writing this from scratch for C libraries
> and passing it to upstream is likely to be much more intrusive than writing
> something like the above python application does and hence less likely to be
> accepted by upstream. Upstream for C applications normally accept patches
> to choose the system library or bundled library at buildtime instead of
> runtime so doing the runtime detection also doesn't make as much sense there
> as for python.
>
> I think that allowing option #2 or better makes sense (ie: making sure the
> bundled library never shows up on the filesystem at all would also be
> acceptable) but I'd like to hear other input. For instance, I'm willing to
> bet that some packages are doing #3 at the moment and would need to be
> further modified to also mark the libraries private. And I also wonder if
> anyone feels that #2 is not sufficient. Please speak up and tell me what
> you think.
>
> -Toshio
>
> ------------------------------------------------------------------------
>
> --
> packaging mailing list
> packaging@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/packaging
My understanding is that to completely unbundle a library, whether a
solib, a PHP lib, a Python module, whatever, you need to remove it from
the upstream tarball prior to the build (i.e. modified tarball, not a
patch or rm -rf in prep), and then use flags, symlinks, or whatever is
appropriate to use the system lib for building and running the program.
I don't feel like including the bundled version and making sure it's not
used is enough. You *can't* really make sure it's not used if it's present.

In essence, if it's not #1, you're not really un-bundling.

My $0.02.

-J

--
in your fear, seek only peace
in your fear, seek only love

-d. bowie

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

Tue Oct 12 20:30:01 2010
Return-path: <bounce-debian-user=tom=linux-archive.org@lists.debian.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Tue, 12 Oct 2010 19:32:50 +0300
Received: from liszt.debian.org ([82.195.75.100]:53827)
by s2.java-tips.org with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.69)
(envelope-from <bounce-debian-user=tom=linux-archive.org@lists.debian.org>)
id 1P5hmT-0003kH-SV
for tom@linux-archive.org; Tue, 12 Oct 2010 19:32:50 +0300
Received: from localhost (localhost [127.0.0.1])
by liszt.debian.org (Postfix) with QMQP
id 18BF213A5300; Tue, 12 Oct 2010 17:26:55 +0000 (UTC)
Old-Return-Path: <stf@eisenbits.homelinux.net>
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on liszt.debian.org
X-Spam-Level:
X-Spam-Status: No, score=-11.0 required=4.0 tests=LDOSUBSCRIBER,LDO_WHITELIST
autolearn=failed version=3.2.5
X-Original-To: lists-debian-user@liszt.debian.org
Delivered-To: lists-debian-user@liszt.debian.org
Received: from localhost (localhost [127.0.0.1])
by liszt.debian.org (Postfix) with ESMTP id 5A5D813A4658
for <lists-debian-user@liszt.debian.org>; Tue, 12 Oct 2010 17:26:49 +0000 (UTC)
X-Virus-Scanned: at lists.debian.org with policy bank en-ht
X-Amavis-Spam-Status: No, score=-7 tagged_above=-10000 required=5.3
tests=[BAYES_00=-2, LDO_WHITELIST=-5] autolearn=ham
Received: from liszt.debian.org ([127.0.0.1])
by localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525)
with ESMTP id lMB+TXkNt5Gd for <lists-debian-user@liszt.debian.org>;
Tue, 12 Oct 2010 17:26:42 +0000 (UTC)
X-policyd-weight: using cached result; rate: -7
X-Greylist: delayed 375 seconds by postgrey-1.31 at liszt; Tue, 12 Oct 2010 17:26:42 UTC
Received: from k8ux.eisenbits.homelinux.net (53-mo6-3.acn.waw.pl [82.210.166.53])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by liszt.debian.org (Postfix) with ESMTPS id 077E213A44F7
for <debian-user@lists.debian.org>; Tue, 12 Oct 2010 17:26:35 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by k8ux.eisenbits.homelinux.net (Postfix) with ESMTP id 6002E182470
for <debian-user@lists.debian.org>; Tue, 12 Oct 2010 19:14:41 +0200 (CEST)
Message-ID: <4CB4981B.20306@eisenbits.homelinux.net>
Date: Tue, 12 Oct 2010 19:17:15 +0200
From: =?UTF-8?B?U3RhbmlzxYJhdyBGaW5kZWlzZW4=?=
<stf@eisenbits.homelinux.net>
User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328)
MIME-Version: 1.0
To: debian-user@lists.debian.org
Subject: WiFi: nm-applet, nm-editor, replace NetworkManager
X-Enigmail-Version: 0.95.0
OpenPGP: id=3B31FE8A;
url=http://eisenbits.homelinux.net/~stf/key-stf.txt
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Rc-Virus: 2007-09-13_01
X-Rc-Spam: 2008-11-04_01
Resent-Message-ID: <Wou6qBzXK9H.A.0BD.fpJtMB@liszt>
Resent-From: debian-user@lists.debian.org
X-Mailing-List: <debian-user@lists.debian.org> archive/latest/587121
X-Loop: debian-user@lists.debian.org
List-Id: <debian-user.lists.debian.org>
List-Post: <mailto:debian-user@lists.debian.org>
List-Help: <mailto:debian-user-request@lists.debian.org?subject=help>
List-Subscribe: <mailto:debian-user-request@lists.debian.org?subject=subscribe>
List-Unsubscribe: <mailto:debian-user-request@lists.debian.org?subject=unsubscribe>
Precedence: list
Resent-Sender: debian-user-request@lists.debian.org
Resent-Date: Tue, 12 Oct 2010 17:26:55 +0000 (UTC)

Here in campus we have 2 networks:

eduroam-open, which is open and very restricted
eduroam, which requires authentication and is less restricted.

I have 3 questions.

1. How to actually select the network to use? I was trying nm-applet but
NetworkManager seems to fallback to eduroam-open simply becase it thinks
it is "better":

> Oct 12 18:45:16 t42-debian NetworkManager: <info> Activation (eth1) New wireless user key requested for network 'eduroam'.
> Oct 12 18:45:16 t42-debian NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) complete.
> Oct 12 18:45:22 t42-debian NetworkManager: <info> SWITCH: found better connection 'eth1/eduroam-open' than current connection 'eth1/eduroam'. same_ssid=0, have_link=1
> Oct 12 18:45:22 t42-debian NetworkManager: <info> Will activate connection 'eth1/eduroam-open'.

2. Where does nm-editor store network passwords? Are those files
encrypted in any way?

3. This is not the first time I am having problems with NetworkManager
here on Debian, so I think I will get rid of it. The question is how to
switch between available WiFi connections without NetworkManager.

For instance I could store network connection parameters unencrypted in
/etc/wpa_supplicant.conf (-rw-------, root:root). How to make WPA
Supplicant select the network I want?

Thanks!

--
http://people.eisenbits.com/~stf/
OpenPGP: DFD9 0146 3794 9CF6 17EA D63F DBF5 8AA8 3B31 FE8A

Like hardship, risk & challenge? --- Follow Jesus!!


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/4CB4981B.20306@eisenbits.homelinux.net
 
Old 10-12-2010, 06:40 PM
Toshio Kuratomi
 
Default Need feedback on what constitutes "unbundling" a library

On Tue, Oct 12, 2010 at 12:25:53PM -0500, Jon Ciesla wrote:
> My understanding is that to completely unbundle a library, whether a
> solib, a PHP lib, a Python module, whatever, you need to remove it from
> the upstream tarball prior to the build (i.e. modified tarball, not a
> patch or rm -rf in prep),

This part at least is not necessary. We only modify the upstream tarball
when there's a reason that we can't ship the upstream source (which does
coincide with bundling of some patent-encumbered media libraries.)

> and then use flags, symlinks, or whatever is
> appropriate to use the system lib for building and running the program.
> I don't feel like including the bundled version and making sure it's not
> used is enough. You *can't* really make sure it's not used if it's present.
>
<nod> This is the part I'd like us to discuss and decide. With pure python
code, I can audit a particular release fairly confidently but in many cases,
that doesn't provide protection when the next release is made (as upstream
may have made a mistake when importing the compat library in their new
code). Scons is an interesting case in that they've done a very good job of
making it so that won't happen either.

I'm not sure about whether that's possible for other languages and also
whether we want to ignore the technical possibilities in order to make it
easier to review -- ie: "Just delete the bundled versions and patch the
source code so it runs" is easier to test if you're a non-programmer than
"you don't have to delete the bundled version if certain other technical
requirements for marking the library private are met of which both the
reviewer and the packager would have to be knowledgable".

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 10-12-2010, 06:44 PM
Jon Ciesla
 
Default Need feedback on what constitutes "unbundling" a library

Toshio Kuratomi wrote:
> On Tue, Oct 12, 2010 at 12:25:53PM -0500, Jon Ciesla wrote:
>
>> My understanding is that to completely unbundle a library, whether a
>> solib, a PHP lib, a Python module, whatever, you need to remove it from
>> the upstream tarball prior to the build (i.e. modified tarball, not a
>> patch or rm -rf in prep),
>>
>
> This part at least is not necessary. We only modify the upstream tarball
> when there's a reason that we can't ship the upstream source (which does
> coincide with bundling of some patent-encumbered media libraries.)
>
>
Ok, fair enough, as long as it's pulled in prep.
>> and then use flags, symlinks, or whatever is
>> appropriate to use the system lib for building and running the program.
>> I don't feel like including the bundled version and making sure it's not
>> used is enough. You *can't* really make sure it's not used if it's present.
>>
>>
> <nod> This is the part I'd like us to discuss and decide. With pure python
> code, I can audit a particular release fairly confidently but in many cases,
> that doesn't provide protection when the next release is made (as upstream
> may have made a mistake when importing the compat library in their new
> code). Scons is an interesting case in that they've done a very good job of
> making it so that won't happen either.
>
> I'm not sure about whether that's possible for other languages and also
> whether we want to ignore the technical possibilities in order to make it
> easier to review -- ie: "Just delete the bundled versions and patch the
> source code so it runs" is easier to test if you're a non-programmer than
> "you don't have to delete the bundled version if certain other technical
> requirements for marking the library private are met of which both the
> reviewer and the packager would have to be knowledgable".
>
>
Easier to review is typically the best path to full compliance.
Probably the easiest to script for audit purposes, as well.
> -Toshio
>
> ------------------------------------------------------------------------
>
> --
> packaging mailing list
> packaging@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/packaging


--
in your fear, seek only peace
in your fear, seek only love

-d. bowie

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

Thread Tools




All times are GMT. The time now is 12:33 AM.

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