packaging February 2007

packaging@lists.fedoraproject.org

40 participants
27 discussions

[Proposal] Spec file name revision
by Toshio Kuratomi 08 Feb '07

08 Feb '07

Here's a proposed policy change for spec file name matching the package name. Basically, it allows us to grandfather in specs from Core that use the %{name}%{MajorVer}.spec format until A) the spec can be renamed and keep its revision controlled history or B) the spec would have been renamed due to MajorVer upgrades in the package. = Spec File Naming = Draft: 0.1 This text will appear on: http://www.fedoraproject.org/wiki/Packaging/NamingGuidelines and be linked from: http://www.fedoraproject.org/wiki/Packaging/ReviewGuidelines It was discussed in this review bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225778 == Rationale == The name of a spec file currently has to match the name of the generated package. This is for two reasons: 1. Preserve history of changes to a spec file in the revision control system. 2. Make it easy for someone extracting an rpm to know what spec filename they need to look for. During the Core merge, some packages which are presently using the %{name}%{version}.spec format will lose history if forced to change. This change provides a temporary exception for those packages. == Text of Change == The spec file should be named using the %{name}.spec scheme. This is to make it easier for people to find the appropriate spec when they install a src.rpm. Example: {{{ If your package is named foo-1.0.0-1.src.rpm, then the spec file should be named foo.spec. }}} There is normally no need to include the %{version} in the spec file name. If you are packaging multiple versions of a package for simultaneous use, they should already reflect the version in the %{name}.spec scheme (refer to Multiple Packages with the same base name for details). In normal cases adding the version can cause the spec file's history to be lost when a package's version is upgraded. As a special exception, there are a few packages which are allowed to have a version in their spec filename. This is because they had the version in their name when they were merged from Fedora Core's cvs and removing the version at that time would *lose* history: * gcc * [Please ask the packaging committee to add your package if you think it should also fall under this exception.] This exception will go away when any of the following criteria are met: 1. We move the packages to a revision control system which is able to preserve history across a file rename. 1. The package spec file is going to be renamed anyway (for example, gcc41.spec is imported into cvs. When gcc is upgraded to gcc-4.2, the new spec will be created as gcc.spec '''not''' gcc42.spec)

1 0

plugin naming
by Till Maas 08 Feb '07

08 Feb '07

Hiyas, I want to ask for a Guideline on how to name plugins for a program/package. Here are some examples of current plugin names: xfce4-wavelan-plugin thunar-media-tags-plugin nagios-plugins-real p7zip-plugins lineak-xosdplugin digikamimageplugins childsplay_plugins audacious-docklet I want to propose to use <package>-plugin-<pluginname> for rpms that contain one special plugin and <package>-plugins or <package>-plugins-<pluginscollectionname> for rpms that contain several plugins. This would make it a lot easier for a user to install or look for all plugins of a given package, e.g. with yum list audacious-plugin\* yum install audacious-plugin\* Regards, Till

2 1

Clarification/ammendment to the "non-numeric characters are permitted in the Version: field" clause
by Fernando Nasser 08 Feb '07

08 Feb '07

Hi, the Naming Guidelines has the following provision in http://fedoraproject.org/wiki/Packaging/NamingGuidelines?highlight=%28Packa… "Post-release packages: Packages released after a "final" version. This usually is due to a quick bugfix release, such as openssl-0.9.6b or gkrellm-2.1.7a. In this case, the non-numeric characters are permitted in the Version: field." Actually there is another case where the upstream version has non-numeric characters: when they have dual-license and name each of their releases with a letter to discriminate under which license that tar ball is. This is not described above. Furthermore, there may be additional complications (see below). The letters vary, but here is an example: The Saxon library has two tar balls for their 8.8 release http://prdownloads.sourceforge.net/saxon/saxonb8-8j.zip where B is the Open Source licensed one (and I believe and "A" marks the non-free one). If the version gets the letters in this order we would have: saxon-B8.7-1jpp.src.rpm That broke my scripts that separate the VR from the package name (perhaps my regexp is not good enough). What is the better way to handle this: 1) Do not mention the "B" at all, as we only release Open Source licensed software anyway. But what if the two licenses are GPL and ASL for instance? or GPL and BSD... 2) Add the letter to the name of the package (like saxon-b) and add a virtual provides for 'saxon' (Argh! I find it ugly) 3) Leave it in the version field, but not as the first character. But in that case, moving it to the end may get it mixed up with the case described in the guidelines: "Packages released after a "final" version. This usually is due to a quick bugfix release, such as openssl-0.9.6b or gkrellm-2.1.7a" 4) Leave it in the version field in the position where it was upstream (and Fernando has to improve his regexps, *if* he is the only one affected and not mock for instance). Any ideas, suggestions, comments? Regards to all, Fernando

3 3

some comments on the desktop files section and proposed amendmends
by Matthias Clasen 08 Feb '07

08 Feb '07

> If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes > of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that > window. This is just not right. xeyes draws an X window - do you want a desktop file for it ?! xev draws an X window, too. nautilus is certainly a GUI application - do you want to see it in the menus ? On the other hand, I can easily imagine non-GUI applications that may deserve a place on the menus. IMO this whole sentence should be nuked and replaced by something like: If a package contains an application that users would expect to find in the panel menus, it needs to include a properly installed .desktop file. > Installed .desktop files MUST follow the [[WWW] desktop-entry-spec <http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-late…>], paying particular attention to validating correct usage > of Name, GenericName <http://fedoraproject.org/wiki/GenericName>, [[WWW] Categories <http://standards.freedesktop.org/menu-spec/latest/apa.html>], [[WWW] StartupNotify <http://www.freedesktop.org/Standards/startup-notification-spec>] entries. A number of comments on this: 1) The desktop-entry-spec doesn't acutally define correct usage of Name and GenericName, all it does is giving a single example of how you could use these fields. 2) While I can see where this is coming from, and may even sympathize with a "correct usage" of Name and GenericName, simply decreeing that it has to be so is not going to make it happen. Packagers really cannot do anything to enforce "correct usage", because doing so would require them to speak all the 40+ languages in which these locale strings are typically translated. Finally, I think it would be beneficial to mention nimetypes and update-desktop-database in this section.

8 11

filing ExclusiveArch bugs when it's HW architectural
by Matt Domsch 05 Feb '07

05 Feb '07

Packaging Guidelines say: - MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding ExcludeArch line. New packages will not have bugzilla entries during the review process, so they should put this description in the comment until the package is approved, then file the bugzilla entry, and replace the long explanation with the bug number. (Extras Only) The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues: [WWW] FE-ExcludeArch-x86, [WWW] FE-ExcludeArch-x64, [WWW] FE-ExcludeArch-ppc My question: Why file a bug when it's clearly a hardware architectural issue? e.g. the hardware arch does not provide the capability that the package uses. Seems like a waste of a bug that won't be fixed. For example, the libsmbios spec uses ExclusiveArch i386 x86_64 ia64, with a nice comment on how the tables this uses are only provided by BIOS of those architectures. ppc and sparc most likely won't ever change in this respect. So why file the bug? Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com

1 0

User IDs in Core packages?
by Sarantis Paskalis 01 Feb '07

01 Feb '07

Hello, Is there any recommendation for mandating/enforcing/changing etc. user IDs in (previously) Core packages? There are some rpm packages in the upcomming merge that hardcode a specific UID in the specfile to use (I was looking at privoxy, which hardcodes the number 73). The documentation at http://fedoraproject.org/wiki/PackageUserCreation recommends fedora-usermgmt but the text seemed to imply that it were for Extras packages only. Is it implied that the default /etc/passwd file should contain the predefined values for the most important packages and the rest should find an alternative way? What is the procedure of allocating UIDs/GIDs to those system users (examples are haldaemon, apache, dbus, sshd, rpc to name a few). Should the packages to be reviewed maintain their existing UIDs/GIDs hardcoded and document it somewhere? The default values in /etc/passwd and /etc/group are the following (taken from setup-2.6.2-1.fc7.src.rpm in rawhide): #/etc/passwd root:*:0:0:root:/root:/bin/bash bin:*:1:1:bin:/bin:/sbin/nologin daemon:*:2:2:daemon:/sbin:/sbin/nologin adm:*:3:4:adm:/var/adm:/sbin/nologin lp:*:4:7:lp:/var/spool/lpd:/sbin/nologin sync:*:5:0:sync:/sbin:/bin/sync shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown halt:*:7:0:halt:/sbin:/sbin/halt mail:*:8:12:mail:/var/spool/mail:/sbin/nologin news:*:9:13:news:/etc/news: uucp:*:10:14:uucp:/var/spool/uucp:/sbin/nologin operator:*:11:0:operator:/root:/sbin/nologin games:*:12:100:games:/usr/games:/sbin/nologin gopher:*:13:30:gopher:/var/gopher:/sbin/nologin ftp:*:14:50:FTP User:/var/ftp:/sbin/nologin nobody:*:99:99:Nobody:/:/sbin/nologin #/etc/group root::0:root bin::1:root,bin,daemon daemon::2:root,bin,daemon sys::3:root,bin,adm adm::4:root,adm,daemon tty::5: disk::6:root lp::7:daemon,lp mem::8: kmem::9: wheel::10:root mail::12:mail news::13:news uucp::14:uucp man::15: games::20: gopher::30: dip::40: ftp::50: lock::54: nobody::99: users::100: Thanks, -- Sarantis

2 5

Re: [Fedora-packaging] Re: Exception for JPackage
by Nicolas Mailhot 01 Feb '07

01 Feb '07

Le Jeu 1 février 2007 13:30, Ralf Corsepius a écrit : > * Empower me with arguments why Fedora's java needs the jpp suffix? > * Empower me with arguments why jpp package can't be merge into Fedora? This has been answered many times already. 1. There is already a bidirectionnal merge process between Fedora and JPP (Fedora gets the results of JPP work, JPP gets the results of Fedora work, and everyone cross-checks the other). 2. The java team can "fix" a jpp package at the jpp level any time they need to. Any other Fedora contributor can get jpp access now by demontrating packaging skills, if he doesn't want to rely on Fernando Nasser 3. JPP is not a drag - it will go as fast and do as strict packaging as its contributors (including the fedora java team) allow. The "worst" scenarii that can happen are : - the Fedora Java team doing all the work there, at which point JPP policy would effectively be Fedora policy - the Fedora Java team offloading all the work @jpp, at which point JPP policy may not be aligned with Fedora policy at all but Fedora would get all its java packaging for free 4. Pulling packages in-Fedora without the back-merging means losing the packaging & review work that happens @jpp, and getting cross-distro namespace divergence for zero wins The jpp suffix is there to help the workflow of the java team by identifying packages participating to this process (because we've refused to fix rpm groups and only provided a comps alternative the anaconda guys do not want to share) -- Nicolas Mailhot

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging February 2007