packaging December 2014

packaging@lists.fedoraproject.org

21 participants
21 discussions

Provides for python shared objects
by Paul Howarth 11 Dec '14

11 Dec '14

The python packaging guidelines include a pointer to http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Ar…, which includes an example for python packages to avoid provides for arch-specific shared objects in the sitearch hierarchy. I was doing a local build of limxml2 and added filtering for the libxml2mod.so object in the libxml2-python sub-package. However, when I came to update to my local build I ran into a dependency issue because python-dmidecode actually requires libxml2mod.so (and libxml2-python is the only thing that currently provides it). I don't know the specifics of the relationship between python-dmidecode and libxml2-python, so I'd like to ask: 1. Is it *always* right to filter provides for private shared objects, or are exceptions like this quite common, or 2. If this is not a real dependency, what should packages like python-dmidecode do to avoid them? Is it due to unnecessary linking perhaps? Paul.

2 1

Schedule for Thursday's FPC Meeting (2014-12-11 17:00 UTC)
by James Antill 10 Dec '14

10 Dec '14

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2014-12-11 17:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2014-12-11 09:00 Thu US/Pacific PST 2014-12-11 12:00 Thu US/Eastern EST 2014-12-11 17:00 Thu UTC <- 2014-12-11 17:00 Thu Europe/London <- 2014-12-11 18:00 Thu Europe/Paris CET 2014-12-11 18:00 Thu Europe/Berlin CET 2014-12-11 22:30 Thu Asia/Calcutta IST ------------------new day---------------------- 2014-12-12 01:00 Fri Asia/Singapore SGT 2014-12-12 01:00 Fri Asia/Hong_Kong HKT 2014-12-12 02:00 Fri Asia/Tokyo JST 2014-12-12 03:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = Followups = (needed policy, feature not accepted yet) #topic #466 recommend Privatedevices and PrivateNetwork in systemd guidelines .fpc 466 https://fedorahosted.org/fpc/ticket/466 (needinfo, just package dep?) #topic #468 Temporary modernizr packing exception for kimchi .fpc 468 https://fedorahosted.org/fpc/ticket/468 = New business = None = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

1 0

Re: [Fedora-packaging] introducing alternatives into a package
by Stephen Gallagher 10 Dec '14

10 Dec '14

On Wed, 2014-12-10 at 04:09 -0500, Jens Petersen wrote: > Hi, > > http://fedoraproject.org/wiki/Packaging:Alternatives explains how > alternatives should be done in Fedora, however it does not seem to > address the case of converting an existing package to use alternatives. > > Specifically the problem arises when a file is changed to become a %ghost. > It seems rpm keeps the old file around as a ghost and so update-alternatives > does not create the new symlink. > > I remember this happening when emacs introduced alternatives > a good while back: at the time I worked around it just by removing > emacs and reinstalling it. > > Adding: > > %pre > if [ $1 -gt 1 ] ; then > if [ -f %{_bindir}/%{name} -a ! -L %{_bindir}/%{name} ]; then > rm %{_bindir}/%{name} > fi > fi > > seems to be one way to handle this. > > Is there any better way to do this or is the above solution good enough? > > If so maybe I should ask FPC about updating Packaging:Alternatives to > include this. (I kind of wish these kind of idioms would be defined > as rpm macros.) > > Jens I'm CCing this to the packaging(a)lists.fedoraproject.org mailing list, as you're more likely to get a useful response from there.

1 0

Changes in Guidelines Connected to "Python 3 as Default" Change
by Bohuslav Kabrda 09 Dec '14

09 Dec '14

Hi all, as you are well aware, there is the "Python 3 as Default" change proposed for F22 [1]. There are several guideline changes that will need to be done and some that may be done in order to improve the situation. I'd like to make this thread a sort of brainstorming on my thoughts as well as possibility for anyone to add something that should be done as well. After that, I'm planning to open an FPC ticket with all the gathered and discussed changes that will come up on this thread. So here are my proposals for changes in current guidelines [2]: - In [3], it says "If the executables provide the same functionality independent of whether they are run on top of Python 2 or Python 3, then only one version of the executable should be packaged. Currently it will be the python 2 implementation, but once the Python 3 implementation is proven to work, the executable can be retired from the python 2 build and enabled in the python 3 package." - this should be changed to prefer Python 3 - (This is not really related to the switch, but more of a general remark) In [4], it says that "python 3 version of the executable gains a python3- prefix". This is IMO bad, since upstream projects tend to name the versioned binaries "foo-3.4, foo-3" or "foo3.4, foo3". We should accept one of these - I'm not really certain which one of them. I tried to discuss this several times on distutils-sig mailing list, but without reaching a consensus. Either way, prefixing with python3- doesn't make sense to me, because it's not similar to any upstream way and you don't find the binaries under their names using tab completion (e.g. foo<tab> doesn't tell you about python3-foo). - As for binaries/scripts in /usr/bin (assuming there are both python2 and python3 versions), the unversioned files should point to python2 version. This aligns with /usr/bin/python still pointing to python2. - Some time ago, I also put together a proposal for some larger changes in Python packaging [5], mostly in how the subpackages for different interpreters should be done. I opened an FPC ticket [6] to get some comments and it seemed that FPC was favorable. While I still think it'd be great to do this change, it'll require a significant effort and that is better spent helping upstreams to port to Python 3 ATM. So I'd also like to receive more comments on this proposal, although I think we should postpone it to F23 (or maybe even later). Thanks for all your comments and further suggestions. Slavek [1] http://fedoraproject.org/wiki/Changes/Python_3_as_Default [2] http://fedoraproject.org/wiki/Packaging:Python [3] http://fedoraproject.org/wiki/Packaging:Python#Guidelines [4] http://fedoraproject.org/wiki/Packaging:Python#Naming [5] https://fedoraproject.org/wiki/User:Bkabrda/Py2to3GuidelineChanges [6] https://fedorahosted.org/fpc/ticket/379

4 5

How to request exception for static linking?
by Dave Johansen 08 Dec '14

08 Dec '14

I'm working on packaging include-what-you-use ( https://bugzilla.redhat.com/show_bug.cgi?id=1091659 ), but right now the clang libraries are only available for static linking ( http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-November/040088.html ). How do I request an exception? Thanks, Dave

2 4

Summary/Minutes from today's FPC Meeting (2014-12-04 17:00 - 17:50 UTC)
by James Antill 04 Dec '14

04 Dec '14

====================== #fedora-meeting-1: fpc ====================== Meeting started by geppetto at 17:02:20 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2014-12-04/fpc.2014-12-04… . Meeting summary --------------- * Roll Call (geppetto, 17:02:20) * #472 Minor modification bootstrap-related guidelines (geppetto, 17:06:03) * LINK: https://fedorahosted.org/fpc/ticket/472 (geppetto, 17:06:17) * ACTION: mbooth Minor modification bootstrap-related guidelines (+1:6, 0:0, -1:0) (geppetto, 17:10:20) * #473 explicit conflicts exception for fedora-productimg-* (geppetto, 17:10:39) * #473 explicit conflicts exception for fedora-productimg-* packages (or other solution?) (geppetto, 17:10:53) * LINK: https://fedorahosted.org/fpc/ticket/473 (geppetto, 17:11:10) * Open Floor (geppetto, 17:29:08) * #469 Unified bootstrapping (geppetto, 17:32:55) * LINK: https://fedorahosted.org/fpc/ticket/469 (geppetto, 17:33:03) * LINK: http://fpaste.org/156678/14177146/ (tibbs|w, 17:38:08) * ACTION: tibbs|w Make dist mandatory for all packages. (+1:6, 0:0, -1:0) (geppetto, 17:48:31) * Open Floor (geppetto, 17:48:49) Meeting ended at 17:50:31 UTC. Action Items ------------ * mbooth Minor modification bootstrap-related guidelines (+1:6, 0:0, -1:0) * tibbs|w Make dist mandatory for all packages. (+1:6, 0:0, -1:0) Action Items, by person ----------------------- * mbooth * mbooth Minor modification bootstrap-related guidelines (+1:6, 0:0, -1:0) * tibbs|w * tibbs|w Make dist mandatory for all packages. (+1:6, 0:0, -1:0) * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * geppetto (73) * tibbs|w (35) * Rathann (17) * mbooth (12) * tomspur (11) * zodbot (9) * racor (7) * limburgher (5) * sgallagh (2) * williamjmorenor (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Re: [Fedora-packaging] Changes in Guidelines Connected to "Python 3 as Default" Change
by Toshio Kuratomi 04 Dec '14

04 Dec '14

On Thu, Dec 04, 2014 at 11:18:58PM +1000, Nick Coghlan wrote: > > I think these are good reasons to default to using the dash if its > Fedora adding it. The guideline could be something like "For Python > executables, also provide symlinks with a '-X' and '-X.Y' suffix, > unless upstream already provides appropriately versioned executables > without the dash. For compatibility packages, the Python version is > appended *after* the specific package version". > Couple notes -- if we do go with putting the Python version after the Fedora compat version, we'll want to phrase this so people know whether to do that for all packages or only for those where upstream is not already putting the version in the name. Always putting the python version at the end means that users have to remember that change when they switch to using a compat package: nosetests-3.4 vs nosetests-v1.1-3.4 Only putting the Fedora version first when upstream doesn't provide the names means that users have to remember the change on a package by package basis: sphinx-build-3.4-v1.1 vs nosetests-v1.1-3.4 We also want to mention the "v" addition to the version specified in the compat version. The "v" helps the user differentiate between the pyhton version and the package version. Most Fedora compat packages don't have this matrix of $language_version + $package_version so they mark the compat files with just a bare $package_version. Since we have both, we need to let packagers know that compat packages need to do a little bit more to distinguish the two sets of numbers. -Toshio

1 0

Re: [Fedora-packaging] Changes in Guidelines Connected to "Python 3 as Default" Change
by Toshio Kuratomi 04 Dec '14

04 Dec '14

On Thu, Dec 04, 2014 at 12:51:40AM +1000, Nick Coghlan wrote: > > On 4 Dec 2014 00:38, "Bohuslav Kabrda" <bkabrda(a)redhat.com> wrote: > > > > So here are my proposals for changes in current guidelines [2]: > > - In [3], it says "If the executables provide the same functionality > independent of whether they are run on top of Python 2 or Python 3, then only > one version of the executable should be packaged. Currently it will be the > python 2 implementation, but once the Python 3 implementation is proven to > work, the executable can be retired from the python 2 build and enabled in the > python 3 package." - this should be changed to prefer Python 3 > > Agreed. > Definitely +1 as well. > > - (This is not really related to the switch, but more of a general remark) In > [4], it says that "python 3 version of the executable gains a python3- prefix". > This is IMO bad, since upstream projects tend to name the versioned binaries > "foo-3.4, foo-3" or "foo3.4, foo3". We should accept one of these - I'm not > really certain which one of them. I tried to discuss this several times on > distutils-sig mailing list, but without reaching a consensus. Either way, > prefixing with python3- doesn't make sense to me, because it's not similar to > any upstream way and you don't find the binaries under their names using tab > completion (e.g. foo<tab> doesn't tell you about python3-foo). > > Agreed. > > CPython & pip use the "foo3.4, foo3" convention, so that seems enough of a > reason to use that convention by default. We may want a "unless upstream does > it differently" caveat though. > Second caveat here is that currently we use version suffixes to denote a command coming from a compat package. If we make this change we need to address that as well. So, you might have sphinx-build, sphinx-build-2, sphinx-build-2.7, sphinx-build-3, and sphinx-build-3.4 for the python interpreter. If you need a forwards or backwards compat package you might also have an 0.9 and 1.1 that you need to tack on. Possible solution here: use a "v" prefix for the compat package's version. So if the default package is 1.1, you would have the python-sphinx0.9 and python3-sphinx0.9 packages provide: * sphinx-build-v0.9 * sphinx-build-2-v0.9 * sphinx-build-2.7-v0.9 * sphinx-build-3-v0.9 * sphinx-build-3.7-v0.9 Also an addition: It would be great for us to always have a "major version number only" script name. Currently there's a few packages (python3-nose, I'm looking at you) that only provide the MAJOR.MINOR form ie: nosetests-3.4. That means scripts (user scripts as well as spec files) have to change whenever we update python3 to a new major release. Having the major only form for all of these binaries will alleviate that. Packagers can just create a symlink if upstrean doesn't provide the -MAJOR version. > > - As for binaries/scripts in /usr/bin (assuming there are both python2 and > python3 versions), the unversioned files should point to python2 version. This > aligns with /usr/bin/python still pointing to python2. > > This also aligns with CPython & pip conventions. Between them, only "pyvenv" > runs under Python 3 by default, and that's only because it doesn't exist in > Python 2. > One exception to this, I think, should be 2to3. Or perhaps python-tools should stop shipping 2to3 and the other /bin/ scripts which python3-tools ships and are not needed in two versions (Not sure if any of those scripts actually need to be carried in two versions.. pygettext.py might need to be tested to be sure the python3 version can handle all sorts of python2 strings correctly). -Toshio

2 2

Schedule for Thursday's FPC Meeting (2014-12-04 17:00 UTC)
by James Antill 04 Dec '14

04 Dec '14

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2014-12-04 17:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2014-12-04 09:00 Thu US/Pacific PST 2014-12-04 12:00 Thu US/Eastern EST 2014-12-04 17:00 Thu UTC <- 2014-12-04 17:00 Thu Europe/London <- 2014-12-04 18:00 Thu Europe/Paris CET 2014-12-04 18:00 Thu Europe/Berlin CET 2014-12-04 22:30 Thu Asia/Calcutta IST ------------------new day---------------------- 2014-12-05 01:00 Fri Asia/Singapore SGT 2014-12-05 01:00 Fri Asia/Hong_Kong HKT 2014-12-05 02:00 Fri Asia/Tokyo JST 2014-12-05 03:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = Followups = (needed policy, feature not accepted yet) #topic #466 recommend Privatedevices and PrivateNetwork in systemd guidelines .fpc 466 https://fedorahosted.org/fpc/ticket/466 (needinfo, just package dep?) #topic #468 Temporary modernizr packing exception for kimchi .fpc 468 https://fedorahosted.org/fpc/ticket/468 = New business = #topic #472 Minor modification bootstrap-related guidelines .fpc 472 https://fedorahosted.org/fpc/ticket/472 #topic #473 explicit conflicts exception for fedora-productimg-* packages (or other solution?) .fpc 473 https://fedorahosted.org/fpc/ticket/473 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

1 0

Re: [Fedora-packaging] Changes in Guidelines Connected to "Python 3 as Default" Change
by Bohuslav Kabrda 03 Dec '14

03 Dec '14

----- Original Message ----- > On Dec 3, 2014, at 9:51 AM, Nick Coghlan < ncoghlan(a)gmail.com > wrote: > > > - (This is not really related to the switch, but more of a general > > > remark) > > > In [4], it says that "python 3 version of the executable gains a python3- > > > prefix". This is IMO bad, since upstream projects tend to name the > > > versioned binaries "foo-3.4, foo-3" or "foo3.4, foo3". We should accept > > > one of these - I'm not really certain which one of them. I tried to > > > discuss this several times on distutils-sig mailing list, but without > > > reaching a consensus. Either way, prefixing with python3- doesn't make > > > sense to me, because it's not similar to any upstream way and you don't > > > find the binaries under their names using tab completion (e.g. foo<tab> > > > doesn't tell you about python3-foo). > > > Agreed. > > > CPython & pip use the "foo3.4, foo3" convention, so that seems enough of a > > reason to use that convention by default. We may want a "unless upstream > > does it differently" caveat though. > > It doesn't really matter right now but long term I think python packaging > should just natively support commands like this. Either just as a matter of > fact, opt in, or by allowing templated command names. Either way I think the > upstream tooling should and likely will follow python's lead for how these > are written. Agreed. However from my experience, most upstreams use the foo-3.4 (i.e. with dash) way. I have to admit I like using the dash more. One more reason for this is that if we start building stacks for other interpreters, e.g. pypy, it would be good to have foo-pypy3 instead of foopypy3 (or foo3pypy? :)). -- Regards, Slavek Kabrda

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging December 2014