[Proposal] Spec file name revision
by Toshio Kuratomi
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)
17 years, 2 months
plugin naming
by Till Maas
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
17 years, 2 months
Clarification/ammendment to the "non-numeric characters are permitted in the Version: field" clause
by Fernando Nasser
Hi, the Naming Guidelines has the following provision in
http://fedoraproject.org/wiki/Packaging/NamingGuidelines?highlight=%28Pac...
"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
17 years, 2 months
some comments on the desktop files section and proposed amendmends
by Matthias Clasen
> 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-la...>],
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.
17 years, 2 months
filing ExclusiveArch bugs when it's HW architectural
by Matt Domsch
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
17 years, 2 months
User IDs in Core packages?
by Sarantis Paskalis
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
17 years, 2 months
Re: [Fedora-packaging] Re: Exception for JPackage
by Nicolas Mailhot
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
17 years, 2 months