packaging February 2012

packaging@lists.fedoraproject.org

30 participants
20 discussions

Error: Package: alsa-utils-1.0.25-7.fc16.x86_64 (updates) Requires: alsa-lib >= 1.0.25
by xning 15 Feb '12

15 Feb '12

Hello, This morning when I updated fedora 16 x86_64, failed: Error: Package: alsa-utils-1.0.25-7.fc16.x86_64 (updates) Requires: alsa-lib >= 1.0.25 Installed: alsa-lib-1.0.24-2.fc15.x86_64 (@anaconda-0) alsa-lib = 1.0.24-2.fc15 Best regards, Xibo Ning

3 2

Re: [Fedora-packaging] Architectures supported by LSB, fedora, ubuntu and kvm
by xning 14 Feb '12

14 Feb '12

Hello, I adjusted the volumn names to reduce the line length. Now the line length is less than 80. So it's suit to browse in terminal. And also add two architecures: s390 and s390x. ----- Original Message ----- From: "Xibo Ning" <xning(a)redhat.com> To: "fedora-devel" <devel(a)lists.fedoraproject.org> Sent: Tuesday, February 14, 2012 10:13:43 AM Subject: Architectures supported by LSB, fedora, ubuntu and kvm Hello, Just as the subject, I made a text table. It's simple. The column name explains itself. I think it is usefull for somebody. The table also contains two columns: 'is_fedora_kvm_support?' and 'is_ubuntu_kvm_support?'. The two columns tell us whether fedora/ubuntn kvm could virtualize the architecture. I got the information from LSB, fedora and ubuntu offical site. kvm information comes from KVM packages of fedora 16 and ubuntu 10.04 LTS. I am not familar with most of these architectures. So, I would like to receive feedback and advice. The table in attach file. Best regards, xning -- devel mailing list devel(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

1 0

Introducing a directory for installed test programs
by Julio Merino 13 Feb '12

13 Feb '12

Hello, The purpose of this long email is to justify the need for a /usr/tests directory and to ask for approval for its creation, with the final goal of packaging ATF, its tests and the tests provided by arbitrary applications (e.g. the just-approved lutok package[1]). This email is long because I feel the need to provide tons of background to explain why this directory is required. I hope the text is clear and that it makes enough sense to convince you of its approval. Here we go! I am the author of the Automated Testing Framework[2] (ATF for short). ATF is the testing framework currently used in the NetBSD operating system, although the ATF project itself is OS-agnostic. In other words, ATF builds and runs fine on multiple Linux distributions, BSD systems and OS X. (ATF is being replaced by a new project called Kyua[3]; this will come into play later in the text.) I am now interested in creating an RPM package of ATF (and Kyua) for Fedora and there is a "little detail" in ATF that will surely be controversial. This is why I am reaching the FPC before sending any spec file for review, as this particular point will need discussion and approval. ATF is made up of two parts: 1) a collection of libraries (C, C++ and shell) that enable developers to write test programs for their applications and libraries; and 2) a collection of tools (atf-run, atf-report) that allow the developers and *end users* to execute these tests. To re-emphasize the point above, note that I said "end users". One of the major features that differentiate ATF from other testing frameworks is that *the tests written using ATF are supposed to be installed in the system* as part of the regular application or library. ATF then provides standalone tools to execute these tests and to generate reports of their results, all without the need of the original program sources nor any development tools (read: no gcc, and specially no make). These tests can be run by any user as they don't require write access to the directory in which the tests live. To put this in the context of a Linux distribution, let's consider a fictitious example: imagine that glib and gtk came with ATF-based tests. These tests would get installed into testsdir/glib/... and testsdir/gtk/... The user would then do "cd testsdir/gtk/ && atf-run" to execute the tests on his machine, without the need for any -devel packages. The key point of this idea is that this allows end users to gain confidence in their systems, because they can validate that a particular piece of software runs fine on their OS / hardware combination. What is more, suppose that glib got upgraded to a new version but not gtk. If there were any incompatibilities between the two, the installed gtk tests would highlight it because they'd start failing. The packager may never have noticed that fact himself if he always kept his build environment up-to-date (as is commonly the case). (Also, consider creating a cron job to run all these tests nightly!) Well, imagine no more. We already do something like this in NetBSD. NetBSD defines the testsdir above as "/usr/tests". This tree[4] contains a subdirectory for each package that provides ATF-based tests, and there is a top-level Atffile file that allows atf-run to recurse into all the package subdirectories. (I.e. executing atf-run within /usr/tests runs *all* the tests available in the system for all packages.) You can see in [5] a more detailed description as to how this comes into practice. There are two important things to consider about /usr/tests: 1) The first is that there is a single directory acting as the "root" for the tests of arbitrary packages because this is what allows all these tests to be run at once. In other words, instead of having /usr/pkg1/tests /usr/pkg2/tests, we have /usr/tests/pkg1 and /usr/tests/pkg2. 2) The second is that ATF is not encoded anywhere in the path. I.e. the directories are /usr/tests/pkg*, not /usr/atf/pkg* nor /usr/tests/atf/pkg*. The reason for this is that the package-specific tests needn't be implemented using the ATF libraries. In fact, Kyua, the replacement for ATF, is able to execute these same unmodified tests and can also execute tests written other frameworks. In a future world, packages would install arbitrary tests into /usr/tests written using their preferred libraries (e.g. pyunit, autotest, etc.) and a single tool (Kyua) would run them all. Encoding the tool name in the directory introduces a dependency on the tool that does not necessarily exist. So, to sum it up: the whole point of this email is to discuss what the "testsdir" above should be in Fedora. I think it makes a lot of sense to keep the default of /usr/tests. However, of course, this does not complain with any the LSB policies. The problem is that no other already-existing directory seems to suit the goals of /usr/tests. For example: /usr/share/tests is unsuitable because the tests are obviously executables and thus not shareable. /usr/libexec/tests also appears unsuitable because these programs are not helper binaries internally used by other programs: they are supposed to be exposed to the end user, who may choose to run them by hand. /usr/lib/tests is even worse because these are not libraries and also has the same problem of libexec in the sense that the files are hidden from end users. End users need to be encouraged to "cd /usr/tests" and to run stuff from there, just as they do with /usr/bin or /usr/sbon. Therefore, I believe that introducing a new directory is sensible enough, particularly because it is potentially optional (e.g. could be made part of a -filesystem package). Actually, the way I envision the packaging to work is the following. Let's consider lutok again, as its distribution file contains ATF-based tests. lutok would come in these packages: lutok, lutok-devel, lutok-tests. The latter package would place files in /usr/tests/lutok only and it would depend on libatf-c++ (because lutok's tests are implemented in C++) and maybe some "tests-filesystem" package. lutok-tests needn't depend on the atf tools. Then, the user could just install the 'atf' package providing atf-run and atf-report to execute these tests from within /usr/tests or /usr/tests/lutok. Similarly, other tools could place their installable tests in /usr/tests/<pkg>. So, what packages would make use of /usr/tests if it were introduced now? As far as I can tell, these would be atf, lutok and kyua (including all of its subpackages for the libraries, etc.). Bind 9 recently adopted ATF too, although I'm not sure if they install the tests. This should be all for now. Is it OK to introduce this optional /usr/tests directory? Please let me know if you have any questions or concerns. Thank you, Julio Merino 1: https://bugzilla.redhat.com/show_bug.cgi?id=785619 2: http://www.NetBSD.org/~jmmv/atf/ 3: http://code.google.com/p/kyua/ 4: http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/?only_with_tag=MAIN 5: http://blog.netbsd.org/tnf/entry/testing_netbsd_easy_does_it

6 13

Additional sources / bundled?
by Brendan Jones 11 Feb '12

11 Feb '12

Hi I have a couple of packages that I'm porting from the CCRMA repo. A couple of them list some additional sources that contain only content (ie a PDF or audio presets / no binaries). Do I still have to create separate SPECS for these files? Some are also unversioned. regards, Brendan

5 5

section: binaries in /bin and /sbin
by Kay Sievers 09 Feb '12

09 Feb '12

This in no longer a problem in Fedora and can be removed: "Binaries placed into /bin and /sbin must not depend upon libraries stored in /usr/lib (or /usr/lib64). Binaries which depend on libraries in /usr/lib* must live in either /usr/bin or /usr/sbin." Thanks, Kay

3 2

broken recommendation for libexecdir
by Kay Sievers 09 Feb '12

09 Feb '12

Heya, recommending %{_libdir}/%{name} will result in /usr/lib64/foo/ which is very broken. "Application private directories' are for binaries not for libraries and are not architecture dependent; they must live in /usr/lib, regardless of the architecture. It is also defined that way by LSB. In general, we recommend, and all new tools use already, the LSB defined /usr/lib/<pkgname>/ dir, because libexec/ is entirely forbidden to use on all other Linux distributions, and we want to share more with them. There would be no rush to get rid of libexec in Fedora, it's nothing wrong with it in general; but recommending it in the packaging guidelines seems very wrong to me, and against all common sense in upstream Linux development. It's a pretty useless Fedora'ism that serves no real purpose and is just different from everything else. It solves no problem that isn't already solved since many years. Thanks, Kay

2 1

Request for confirmation: Which form is required for a review
by Matthias Runge 08 Feb '12

08 Feb '12

Hi, lately, I stumbled upon a review, which I thought, wouldn't suffice. It looks like the following name: ok summary: ok license: ok handling locale files: ok rpmlint output: only spelling warning Not needed BuildRequires: (names), please remove them in git. APPROVED. My question is: is this review sufficient, if not, where is it written down, that it isn't? I'm especially aiming to the form of this review. I wasn't able to spot a requirement to write something like approved (or something else) on http://fedoraproject.org/wiki/Packaging:ReviewGuidelines Further more, there isn't anything said about how the reviewer should document his work. If we deny the requirement of documenting reviewer's operation, then just setting the approved flag conforms with the guidelines; This also claims, everything has been checked and is well done. Am I missing something? Is there any need to clarify our review guidelines? Do we need something more documented? Do we trust our reviewers, so there's no need of bureaucracy? Why should/must I do more than just setting the flag or writing 7 catchwords? Thanks -- Matthias Runge <mrunge(a)matthias-runge.de> <mrunge(a)fedoraproject.org>

4 6

[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway 06 Feb '12

06 Feb '12

There have been quite a few approved changes to the Fedora Packaging Guidelines since the previous announcement, but this is mostly because I have not had time to actually apply the approved updates to the wiki until recently. These updates actually were approved over a period of several months. I will try harder to get updates written up and announced in a more timely fashion going forward. --- The Eclipse Plugin Packaging Guidelines were updated. The most major change is the addition of a section discussing how to run the reconciler. For the full updated guidelines see: https://fedoraproject.org/wiki/Packaging:EclipsePlugins --- t4k_common contains a forked copy of an older version of liblinebreak. A temporary bundling exception has been granted until the t4k_common upstream is able to port their code to use the newer system copy of liblinebreak. The t4k_common package must include Provides: bundled(liblinebreak) until the issue is resolved. This exception has been added to the list here: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gran… --- Spring RTS includes a forked and bundled copy of Lua which has Spring RTS specific patches applied, must link to streflop, and is configured differently from stock Lua (most importantly it needs lua_Number to be a float and not a double). Lua is particularly important because parts of the game code may be written in it, which must yield exactly identical results (also floating point operations!) on all platforms. As a result, it has been granted a bundling exception for lua. The Spring RTS package must include Provides: bundled(lua) = X.Y.Z (where X.Y.Z is the base lua version), until the bundling issue is resolved (if ever). This exception has been added to the list here: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gran… --- A section has been added to the Guidelines that limits which package manager repositories are allowed to be configured in Fedora. Additional repository configuration files are allowed as documentation provided that they are legally allowable by Fedora. https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_of_Packag… --- The MPI Guidelines have been clarified by adding this additional statement: If the maintainer wishes for the environment module to load automatically by use of a scriptlet in /etc/profile.d or by some other mechanism, this MUST be done in a subpackage. https://fedoraproject.org/wiki/Packaging:MPI --- The Devel Packages section of the Packaging Guidelines has been rewritten to be more comprehensive and clear: https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages In addition, the ReviewGuidelines have been simplified to state simply that Development files must be in a -devel package. --- An exception was granted which permits the bundling of binutils libraries, (most notably, libbfd, libcpu, libopcodes, and libdecnumber) but only to packages which share the same upstream as binutils (sourceware.org). This is because the libraries are developed by the application authors as common functionality shared between several applications. Being developers of both, they'll be intimately aware of both issues that arise in the libraries and know how to port to newer versions of the library as needed. Note that, at the moment, all of these applications and libraries come from sourceware.org but not all of them are used in binutils. Packages leveraging this exception must add: Provides: bundled(binutils) = %{snap}, where %{snap} is defined in the package as the date that the binutils checkout was made, until the bundling issue is resolved (if ever). This exception has been added to the list here: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gran… --- The Packaging Guidelines section on Architecture Support has been amended to clarify that all Fedora packages must successfully compile and build into binary rpms on at least one supported primary architecture, except where the package is useful only on a secondary architecture (such as an architecture-specific boot utility, microcode loader, or hardware configuration tool). https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support --- The "okjson" software has reluctantly been granted a bundling exception. Packages which bundle okjson.rb must add: Provides: bundled(okjson), until the bundling issue is resolved (if ever). https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gran… --- The section of the Packaging Guidelines covering /srv was amended to include /opt and /usr/local. Specifically, the following sentence was added: In addition, no Fedora package can have any files or directories under /opt or /usr/local, as these directories are not permitted to be used by Distributions in the FHS. https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories… --- A new section has been added to the Fedora Packaging Guidelines regarding Network Support. Specifically, if an application contains native and stable support for both IPv4 and IPv6, and support for IPv6 does not negatively affect IPv4 then both must be enabled in the Fedora package. https://fedoraproject.org/wiki/Packaging:Guidelines#Networking_Support --- As part of the /usrmove feature in Fedora 17, Fedora packages MUST NOT place files or directories in the /bin, /sbin, /lib or /lib64 directories. Instead, the /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64 directories must be used. Packages must assume that /bin, /sbin, /lib, and /lib64 are symbolic links to the /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64 directories, respectively. This is effective immediately for new packages, however, packagers are not required to implement this change for distributions older than Fedora 17. https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout --- A temporary bundling exception has been granted for libtdb_compat and libccan, but only for samba4 packages. This exception will last until F18 GA, or libtdb 2.x releases, whichever comes first. Samba4 packages which bundle libtdb_compat or libccan must include Provides: bundled(libtdb_compat) or Provides: bundled(libccan), until the bundling issue(s) are resolved. https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gran… --- A bundling exception has been granted for libreplace, but only if the package in question shares the same upstream as samba. This is because the libreplace library is developed by the application authors as common functionality shared between several applications. Being developers of both, they'll be intimately aware of both issues that arise in the libraries and know how to port to newer versions of the library as needed. Samba packages which bundle libreplace must include Provides: bundled(libreplace), until the bundling issue is resolved (if ever). https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gran… --- The Pre-Release packages section was improved significantly, with the intent of making it more clear through the use of specific examples in tables. https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packa… --- The Icon Tag in Desktop Files section in the Packaging Guidelines has been amended to include a link to the scriptlets to refresh the icon cache. https://fedoraproject.org/wiki/Packaging:Guidelines#Icon_tag_in_Desktop_Fil… --- The Emacs Packaging Guidelines have been clarified and simplified, with much unnecessary duplication removed. https://fedoraproject.org/wiki/Packaging:Emacs --- A new section containing tips and best practices for writing scriptlets for Fedora packages has been added. https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Writing_scriptle… --- The Guidelines section on Handling Locale Files has been updated to reflect the additional functionality in %find_lang. https://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files --- Ulrich Drepper's MD5 implementation, as found originally in gcc, was added to the list of MD5 exception cases permitted for bundling exceptions. https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gran… --- A link to the No Bundling Libraries page, which contains the steps necessary to request a Bundling exception, has been added to the "Bundling of multiple projects" section in the main Guidelines. https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_of_multiple_pr… --- The section on File and Directory Ownership has been updated to reflect the fact that while in most cases, it should not be necessary for multiple packages to contain identical copies of the same file, if it is necessary, multiple packages may contain identical copies of the same file, as long as the following requirements are met: * The packages sharing ownership of the identical files are built from a single SRPM. OR * The packages sharing ownership of the identical files are not in a dependency chain (e.g. if package A requires package B, they should not both contain identical files, either A or B must own the common files, but not both.) In addition, identical files are defined as files which are always identical in content, checksum, permissions, and location on the filesystem in each package. https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Owne… --- Announce Text: A new section has been added to the PHP Guidelines, documenting the PHP ZTS extension. https://fedoraproject.org/wiki/Packaging:PHP#PHP_ZTS_extension --- These guidelines (and changes) were approved by the Fedora Packaging Committee (FPC). Many thanks to Nick Clifton, Remi Collet, Frank R Dana Jr., Gilboa Davara, Kevin Fenzi, Stephen Gallagher, Harald Hoyer, Jan Kratochvil, Jussi Lehtola, Marcela Mašláňová, Panu Matilai, Vít Ondruch, Petr Pisar, Michael Schwendt, Kay Sievers, Chris Tyler, Jonathan Underwood, Karel Volný, Sami Wagiaalla, Christoph Wickert, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines. As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here: https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure Thanks, ~tom

1 0

Re: [Fedora-packaging] Time for Lua packaging guidelines?
by Michel Alexandre Salim 03 Feb '12

03 Feb '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tim, On 02/03/2012 07:32 PM, Tim Niemueller wrote: > Hi Michel. > > Yes, it might be time to come up with Lua packaging guidelines > (though I like to keep it at a minimal bureaucratic level. Certainly. I'm envisaging a rather stripped down version of the Python guidelines. > > Are you (or anyone else interested in this) at Fosdem by any > chance? I will be so it might give an opportunity to meet face to > face and get things started. We could also discuss Lua 5.2. > Sadly I'm not going to be there. But I'm normally on IRC or Jabber. Best, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: salimma(a)fedoraproject.org | GPG key ID: A36A937A Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8sPZ8ACgkQNd069XiIR3jntQCfXjVIpFylBqiWU4FehvcJfJhQ GyIAn0B5unC3KX0RiQMqfnImaSlzTfiE =azjm -----END PGP SIGNATURE-----

1 0

I want to edit the How to create an RPM package page
by Christopher Meng 03 Feb '12

03 Feb '12

https://fedoraproject.org/w/index.php?title=How_to_create_an_RPM_package Well.I want to update the example of eject(Fedora 9 is too old) Anybody can give me some advice? Best Regards, Christopher Meng------'Cicku' My personal blog is http://cicku.me,hope you can visit and say something about it. More Contact info see here:http://about.me/cicku

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging February 2012