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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
