[Guidelines Change] Changes to the Packaging Guidelines

[Kevin Kofler]

Tom Callaway wrote:
> The Naming Guidelines for python modules has been updated to remove the
> exception for packages which have a "py" prefix in the upstream name.
> This change comes at a time when python2 and python3 modules are
> commonly built from the same package and all python3 modules are
> required to have a "python3" in their name. This change makes it easier
> for users to identify that the python3-foo module is part of the
> python-foo package for filing bugs and searching for the python3 version
> of a package they use in python2.

IMHO this is really unhelpful. What is next, are we going to adopt that
silly "lib*" naming policy/requirement for libraries next? I sure hope not.

Everyone knows PyQt4 as PyQt4, not python-qt4 or the impressively redundant
python-PyQt4. The naming rules for the Python 3 version should have been
relaxed instead, allowing something like Py3Qt4 or PyQt4-python3.

> The prohibition against packages installing files into /bin, /sbin,
> /lib, and /lib4 has been removed and a section explaining how Fedora's
> UsrMove? feature interacts with the rpm %files section has been added.
> Packagers who maintain software that installs into /bin, /sbin, /lib,
> and /lib64 historically or in upstream are encouraged to read that
> section to understand what's best for their package: ​
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#Effect_of_the_UsrMove_Fedora_Feature

Together with:
http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-provides-bin-file-does-not-find-any-packages-on-fedora
doesn't that mean that users will have to run BOTH:
dnf provides /usr/bin/foo
AND
dnf provides /bin/foo
to check what package owns that particular file? That strikes me as
extremely user-unfriendly.

> Added an additional allowed use of Conflicts to the packaging guidelines
> on Conflicts. This usage is for a package which is split into multiple
> packages with files that may conflict with files in the older version of
> the base package. See the Conflicts Guidelines if you think you may be
> able to make use of this:
> 
> ​https://fedoraproject.org/wiki/Packaging:Conflicts#Splitting_Packages

The use of <= (resp. > for the Requires part) there is very problematic in
the presence of disttags (Conflicts: foo <= 1.2.3-4 does NOT match
1.2.3-4.fc21) or also in the case of stable branches
(Conflicts: kdefoo <= 4.12.4 and then KDE releases kdefoo-4.12.5). IMHO,
this should be amended to use < (resp. >=) versioning
(Conflicts: foo < 1.2.3-5 resp. Conflicts: kdefoo < 4.12.80, for most other
upstreams you'd even use < 4.13).

> A method of handling noarch packages which have dependencies that are
> not present on some architectures was made official. ​
> https://fedoraproject.org/wiki/Packaging:Guidelines#Noarch_with_unported_dependencies
> 
> 
> These methods are a change from the common practice in, for instance,
> node.js packaging. Packagers should think about updating their packages
> to the new guidelines as they make other updates.
> 
> Please see ​https://fedorahosted.org/fpc/ticket/355#comment:8 or the
> meeting log for that date if you want more information than is in the
> Guidelines. The possibility of enhancing rpm or koji to deal with this
> in a better manner is being looked into by the packaging-team and
> rel-eng. When those features eventually are available to Fedora, we'll
> update the Guidelines to take advantage of them.

Hmmm, I know I'm late to the discussion (and I hadn't thought of it when the
discussion first came up) couldn't we use something like this
(foo-dummymain.spec):

Name: foo-dummymain
ExclusiveArch: %{ix86}
…
# the actual noarch package built as a noarch subpackage:
%package -n foo
BuildArch: noarch
…
%files
# empty list so that foo-dummymain does not get generated
%files -n foo
# the actual file list

? That should give us the best of both worlds.

> Changes to python-setuptools in F20 cause easy_install to install egg
> files instead of egg directories by default. This sometimes causes
> problems for rpms of multi-version python modules as the egg filenames
> are the same if the version of the package hasn't been increased and rpm
> is unable to replace the directory with a file. To fix this, the ​
> https://fedoraproject.org/wiki/Packaging:Python_Eggs#Multiple_Versions
> guideline has been updated to pass the "-Z" switch to easy_install which
> restores the former behaviour of installing eggs as a directory.
> 
> If you package a backwards or forwards compat python module that makes
> use of the Multiple_Versions guideline (or easy_install in some other
> way), please update your spec file to include the -Z switch.

Couldn't we %pretrans-hack that?

And with all the issues this and the related symlink problem have caused,
IMHO, it's really time to fix RPM to support these cases without hacks!

        Kevin Kofler