packaging March 2005

packaging@lists.fedoraproject.org

24 participants
23 discussions

Device node packaging question
by Ville Skyttä 19 Mar '05

19 Mar '05

tpb from Extras fails to build on FC4 due to rpmbuild 4.4 not liking the way the device node is created. https://bugzilla.redhat.com/151527 tpb needs the /dev/nvram node in order to function, and the users using tpb will need to be able to read from /dev/nvram. Opinions how to create the device node and ensure the correct permissions? Some approaches: Place the device node in /etc/udev/devices, own it in the package, use udev permissions.d for the permissions. This is what is currently done, but it fails due to rpmbuild no longer liking that (see the above bug report). And it's not that pretty anyway. I could %ghost the node and create it in %post, but that's even a bit uglier IMO. How about using the /etc/udev/makedev.d functionality for creating the node? This has the problem that stuff in /etc/udev/permissions.d doesn't apply to /etc/udev/makedev.d nodes (is this a bug?); instead the node is being created with the too restrictive 0600,root,root permissions from /etc/makedev.d/{00macros,linux-2.6.x}. A workaround would be to place an override in /etc/makedev.d/$something, overriding the permissions for the nvram node in linux-2.6.x. The MAKEDEV man page doesn't describe how to accomplish that override or if it's possible, but I guess naming the file something like 01-tpb-nvram would work. The ideal way would be to create the node with restrictive permissions as in the above, and use console.perms for granting users logged on to the console access to the device. However, I'm not going to do that in the tpb package by sed'ing /etc/security/console.perms, because doing so could have "effects" when later upgrading pam. Instructing users to make that modification would have essentially the same drawback. And console.perms.d doesn't exist :( https://bugzilla.redhat.com/135093 So, maybe suggest adding nvram to the console.perms shipped with pam? Comments, other solutions?

1 0

Re: GConf schema packaging guidelines
by Toshio Kuratomi 15 Mar '05

15 Mar '05

From rom the Fedora-maintainers list Code in question: > Le mardi 01 mars 2005 à 14:42 -0500, David Malcolm a écrit : > > Some spec files try to uninstall the schema e.g. from > > evolution-connector: > > %preun > > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` > > gconftool-2 --makefile-uninstall-rule \ > > %{_sysconfdir}/gconf/schemas/apps_evolution_exchange.schemas > > >/dev/null || : The problem: > On Sat, 2005-03-12 at 15:11 +0100, Dams wrote: > This is a packaging bug if you dont test the upgrade case. > If you uninstall schemas you just *must* have an `if' statement > surrounding the gconf schema un-installation in %preun, to test if we're > being upgraded or un-installed. > > Remember that, when upgrading, %preun of the old package is ran after > the new package %post. > I think the intent is to remove the old schema from gconf before installing the new schema. So I think this %pre script would work:: %pre # For GConf apps if [ "$1" -gt 1]; then export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-uninstall-rule \ %{_sysconfdir}/gconf/schemas/%{name}.schemas >/dev/null || : fi Is that wrong (or my assumption that we're trying to clean up the old schema?) If it's good, then maybe the scriptlets in the spectemplates (fedora-rpmdevtools) should be changed. > And anyway, we have a problem in cases like: > > * foo-1 which has foo.schema is installed > * you upgrade to foo-2 which has foo2.schema, but has no > foo.schema. > > foo.schema will never be uninstalled, as foo-2 knows nothing about it. > (Yes, that sort of things has already happened). The packager should know about foo.schema... So one inelegant solution would be to put uninstall rules for both foo.schema and foo2.schema with discarded error conditions into the %pre. -Toshio --

2 3

Re: note about packaging init scripts
by seth vidal 10 Mar '05

10 Mar '05

On Thu, 2005-03-10 at 14:42 -0500, Bill Nottingham wrote: > If you are packaging init scripts with a file path of > /etc/init.d/your_script > you *need* to either: > > a) prereq chkconfig (even if you don't call it) > b) package it in /etc/rc.d/init.d/your_script > > As /etc/init.d is a symlink, if you don't do one of > these, your package may be installed first, and this > will cause chkconfig to fail to install later. Thanks Bill, CCing this over to fedora-packaging to let Tom roll it into his docs. -sv

1 0

X-Fedora vs. X-Fedora-Extra vs. X-Fedora-Extras
by Michael Schwendt 08 Mar '05

08 Mar '05

X-Fedora : most packages imported from fedora.us use this in the desktop files X-Fedora-Extra : a dozen packages switched to it X-Fedora-Extras : package "logjam" uses it Which one do we use from now on? I would assume X-Red-Hat-Extras => X-Fedora-Extra, but it would sound dumb.

5 12

No modifying %{SOURCE} during rpmbuild
by Warren Togami 08 Mar '05

08 Mar '05

No modifying %{SOURCE*} during rpmbuild. Stuff included in %{SOURCE*} must not be modified during rpmbuild because the resulting .src.rpm will contain the modified version, not original. You should instead make a copy, then modify that copy. Example from gaim.spec: # If not using gnome-open, then default to htmlview +cp %{SOURCE1} prefs.xml if [ "%{gnome_open_integration}" == "0" ]; then - sed -i "s/gnome-open/custom/g" %{SOURCE1} - sed -i "s/pref name='command' type='string' value=''/pref name='command' type='string' value='htmlview'/" %{SOURCE1} + sed -i "s/gnome-open/custom/g" prefs.xml + sed -i "s/pref name='command' type='string' value=''/pref name='command' type='string' value='htmlview'/" prefs.xml fi Warren Togami wtogami(a)redhat.com

3 2

Removing all zero epochs from spec files in devel branch
by Matthias Saou 07 Mar '05

07 Mar '05

Hi, 'nuff of all this. The subject says it all. I already asked for it *before* *any* Extras builds would start taking place. It didn't happen. But now I *want* it to happen before any FC4 Extras builds do. And I'll go through every single spec file alone if I need to. If anyone is _opposed_ to this change, please voice yourself now. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.770_FC3 Load : 0.30 0.17 0.21

6 8

Conflicts
by Michael Schwendt 05 Mar '05

05 Mar '05

What is the official policy about packages in Fedora Extras which marked as conflicting with eachother? E.g. Sylpheed (dropped from Rawhide) and Sylpheed-claws share file names for main binary, manual page, pixmap file, desktop file. And since Sylpheed-claws is the feature-enhanced bleeding edge development fork of Sylpheed, there may be other conflicts. While this particular conflict could be resolved by renaming the files, this would be contrary to what upstream does. As another example, gpgme03-devel and gpgme-devel. Used to building in clean build environments where only the needed build requirements are pulled in, there was no need to relocate either package and make it possible to install both at once. I think there are other extras which conflict because they provide same or similar functionality, not limited to "leafnode" and "suck", "oidentd" and "pidentd" (core), "proftd" and "vsftpd anonftp" (core). Where do we go from here?

5 11

NewPackageProcess, comment on Patch0 vs Patch
by Michael Schwendt 04 Mar '05

04 Mar '05

http://fedoraproject.org/wiki/NewPackageProcess says: > Patches should start at Patch0, don't use Patch, even if you only have one > right now, because inevitably, you'll need another one at some point > before the sun explodes. What is the rationale? Patch: foo.patch Patch1: bar.patch # ... %patch -p1 -b .foo %patch1 -p1 -b .bar work just fine. 'Patch' == 'Patch0' is true.

3 3

kernel-module rpm's - final decision?
by Troy Dawson 03 Mar '05

03 Mar '05

Hello, As we are currently working on our openafs package, I want to make sure our kernel modules for it conform to what was agreed upon. But other than the naming, I didn't see a definate 'this is how to do them' list. (If I missed that, point me to it) Here's what I saw. My example will be openafs, but I am meaning this for others as well. Name: kernel-module-openafs Version: 1.3.9 Release: 2.6.9-5.0.3.EL.4 Requires: kernel = 2.6.9-5.0.3.EL Provides: kernel-module-openafs Then the discussion shifted to whether yum and apt would be able to handle this. And there seemed to be a rumble of "it can be done, but it won't be pretty" Am I missing a thread? Is this really the way we are planning on doing kernel-modules? Thanks Troy Dawson -- __________________________________________________ Troy Dawson dawson(a)fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________

4 7

Naming Policy (first draft)
by Tom Callaway 02 Mar '05

02 Mar '05

Working as fast as I can... here is the first draft of the Naming Policy for Fedora Extras. Its not 100% complete yet, there are at least two sections missing, but it covers the bases for most new packagers. http://fedoraproject.org/wiki/PackageNamingGuidelines Feedback is welcome, and encouraged. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!

14 77

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging March 2005