Inconsistencies in Python package naming
by Bohuslav Kabrda
Hi all,
so after spending some months with Python packaging, I came to think that the naming has to be standardized better.
Problem 1:
The naming guidelines say, that if there is "py" or "Py" in package name, you _can_ use that name for a package, otherwise use python-{name} [1]. So if I'm trying to install "pygments", I just try "pygments", but whoops - it's named python-pygments. How could I tell?
Problem 2:
If I install "PyYaml" (this time I was lucky and guessed correctly), then it's confusing that I have to install python3-PyYaml. Both should be prefixed "python[possibly 3]-", or none of them.
Problem 3:
The table in [2] is even more confusing. If the upstream name is "pygtk", why should Fedora's package be called "pygtk2"? Where did the "2" come from? Why do we need it if Python 3 version is clearly named "python3-pygtk"?
So my proposal would be:
Let's make it mandatory for all the Python package names to be prefixed with python-/python3-. If the upstream name already starts with "python-", then let's use that (possibly inserting the "3").
Another python implementations may pose a problem here - if we decide to package something for pypy, how do we call it? My suggestion would be to use it instead of "python-" - so "python-foo" would translate to "pypy-foo" in terms of binary RPM names.
Please note, that very similar proposal was already discussed some time ago on python-devel [3], and this feature [4] (never actually proposed) was created back then. I'm trying to restart the discussion to make this moving.
Thoughts?
Thanks.
--
Regards,
Bohuslav "Slavek" Kabrda.
[1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_...
[2] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_...
[3] http://lists.fedoraproject.org/pipermail/python-devel/2012-August/000435....
[4] https://fedoraproject.org/wiki/Features/PythonNamingDependingOnImplementa...
11 years, 1 month
Filtering Provides for Node.js Binary Extension Modules
by T.C. Hollingsworth
Like the equivalent many other languages, Node.js C++ extension
modules result in unwanted provides that by policy need to be
filtered, We definitely want to provide a %nodejs_default_filter
similar to Perl's %perl_default_filter to make this easy for
packagers.
However, I understand the old guidelines are outdated, and Perl's
macro already uses the new version [1]. Should we go ahead and use
the new version too when implementing %nodejs_default_filter or wait
for the draft to be approved?
Thanks!
-T.C.
[1] https://fedoraproject.org/wiki/User:Toshio/AutoProvidesAndRequiresFilteri...
11 years, 1 month
Vote in ticket: Ruby Guidelines update
by Toshio Kuratomi
Since FPC hasn't had quorum for several weeks, the members at the meeting
today decided to select one or two tickets each and propose votes in ticket.
Here's my low hanging fruit:
https://fedorahosted.org/fpc/ticket/256
We voted to approve this initially 4 weeks ago however after more discussion
in the ticket it became apparent that the update is unclear on what would be
misuse of the -d switch to the %gem_install macro. To unstick that, I
proposed a change to the guideline:
https://fedorahosted.org/fpc/ticket/256#comment:10
Please vote in the ticket or discuss here.
Thank you,
Toshio
11 years, 2 months
RPM macro for /usr/lib/rpm/macros.d?
by Björn Persson
I have a file of RPM macros (macros.gnat) which has been in /etc/rpm
until now. I agree with the recent decision that such files aren't
configuration, and therefore I'm moving it to /usr/lib/rpm/macros.d.
Should I write the path as "%{_rpmconfigdir}/macros.d", or is there a
better macro to use?
Björn Persson
11 years, 2 months
[Proposal] Packaging guidelines/spec per version
by Vít Ondruch
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora
version? If this would be accompanied by the rule, that .spec files
can't be shared as well (using some conditions), this would allow us to
have much faster evolution of our packaging. I'll give you a few examples.
= Tilde versioning
It is available in RPM since 4.10 [1], i.e. Fedora 18. It is prohibited
by guidelines [2].
= Support for /usr/lib/rpm/macros.d/
Available since RPM 4.11 [3, 4], i.e. Fedora 19, nobody place the
additional macros there (well I'll fix Ruby and RubyGems as soon as I'll
have some free cycles). Actually it could be nice scripted.
= Changes in Ruby guidelines
There are currently 3 versions of Ruby guidelines [5], which apply to
different versions of Fedora and EPEL anyway.
= %clean section
Not mandated since F13 [6], but widely used in older packages. That
could be easily removed by script it there would not be chance that the
package is in use for EPEL5
= BuildRoot tag
Not needed since F10! [7] But needed by EPEL. BTW you should not update
packages in EPEL, to keep ABI stability, anyway, so why you should carry
around such thing in F20? There is high chance that EPEL5 package
contains much older version.
= mandatory %defattr at the beginning of %files section
Not needed since RPM 4.4 [8].
This is not exhaustive list. If you just count %clean section, BuildRoot
tag and %deffattr, the spec file could be 5 lines shorter. 5 lines which
can make difference in maintainability, in attraction new packagers,
since they would not need to wonder "what the BuildRoot is there for?"
What I have learned during recent rebuild of Ruby packages is that the
.specs, which contains conditions to support different versions of
Fedora or EPEL are the one, which are the hardest to maintain. There is
no simple way how to automatically migrate them to support newer
guidelines. This exactly prohibits the innovation. This prohibits any
new feature which we could benefit.
If the .spec would be specific to the Fedora version, it could follow
the latest and greatest development. However there are some version
specific branches which prevent that.
Some may object, that the resulting binary RPM should be compatible
between Fedoras and installable everywhere, but I can assure you, that
you cannot install any RPM which depends on Ruby from F18 to F19 and
vice versa, so the argument is moot. This apply also to all libraries
after soname bump, not just that we are doing something terribly wrong
in Ruby.
So please, consider this proposal. In a long term (speaking about really
long term now), the .spec file should contain just a few lines, such as
SOURCE0 and the rest would be done by a few simple macros. Take a look
for example what Java guys did recently [9] and how it used to be [10]
(I am sure they could provide you better examples :). This would let us
to focus on more important things then copy pasting guidelines to .spec
files.
Thank you
Vít
[1] http://www.rpm.org/wiki/Releases/4.10.0
[2] http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Version_Tag
[3] http://www.rpm.org/wiki/Releases/4.11.0
[4] https://bugzilla.redhat.com/show_bug.cgi?id=846679
[5] https://fedoraproject.org/wiki/Packaging:Ruby
[6] https://fedoraproject.org/wiki/Packaging:Guidelines#.25clean
[7] https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag
[8] https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions
[9] https://fedoraproject.org/wiki/Packaging:Java#Apache_Maven
[10]
https://fedoraproject.org/w/index.php?title=Packaging:Java&oldid=246507#m...
11 years, 2 months
Question about packaging of MPICH2
by Andrew Prokhorenkov
I get confused with the environment modules with MPICH2 package.
It has two identical modules files:
/etc/modulefiles/mpich2-i386
/etc/modulefiles/mpi/mpich2-i386
If they are identical, why not to make one of them a symlink? Does
even both files needed?
For example, in openmpi there is only one file:
/etc/modulefiles/mpi/openmpi-i386
--
Andrew Prokhorenkov
11 years, 2 months
FPC Meeting this week
by Toshio Kuratomi
This is just a heads up that I will probably not be available this week for
the FPC meeting. If someone else wants to run it, please do. the only two
commands you absolutely need to know are:
#startmeeting fpc
#endmeeting
If you need me to vote after the meeting on certain tickets, just let me
know.
Next week I hope to be present for the meeting but I can't promise I will.
I'm at the PyCon conference both weeks but next week is the hackfest portion
so it will depends on internet connectivity more than scheduling.
The Haskell Guidelines are one thing that needs to be looked over and voted
upon: https://fedorahosted.org/fpc/ticket/194
The filtering guidelines need one vote to pass (or five negative votes to
fail): https://fedorahosted.org/fpc/ticket/189
I think that all other tickets that we were voting on in trac are done.
Lots of "new" tickets if you get past those two.
-Toshio
11 years, 2 months
