Device node packaging question
by Ville Skyttä
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?
18 years
Re: GConf schema packaging guidelines
by Toshio Kuratomi
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
--
18 years
Re: note about packaging init scripts
by seth vidal
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
18 years
X-Fedora vs. X-Fedora-Extra vs. X-Fedora-Extras
by Michael Schwendt
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.
18 years
No modifying %{SOURCE} during rpmbuild
by Warren Togami
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
18 years
Removing all zero epochs from spec files in devel branch
by Matthias Saou
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
18 years
Conflicts
by Michael Schwendt
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?
18 years
kernel-module rpm's - final decision?
by Troy Dawson
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
__________________________________________________
18 years
Naming Policy (first draft)
by Tom Callaway
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!
18 years