From rc040203 at freenet.de Mon Sep 5 15:31:01 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 Sep 2005 17:31:01 +0200 Subject: [Fedora-packaging] Who owns /usr/share/locale/? Message-ID: <1125934262.25892.101.camel@mccallum.corsepiu.local> Hi, Who is supposed to own /usr/share/locale/? rpm -qf /usr/share/locale/* on FC4, reveals ownership on these dirs being handled quite inconsistently. Many are unowned, several are owned by individual packages (gettext, hal, gawk ..., seems like packaging bugs to me), ... Ralf From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Sep 5 17:13:13 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 5 Sep 2005 19:13:13 +0200 Subject: [Fedora-packaging] Who owns /usr/share/locale/? In-Reply-To: <1125934262.25892.101.camel@mccallum.corsepiu.local> References: <1125934262.25892.101.camel@mccallum.corsepiu.local> Message-ID: <20050905191313.3586de0d@python2> Ralf Corsepius wrote : > Who is supposed to own /usr/share/locale/? > > rpm -qf /usr/share/locale/* > on FC4, reveals ownership on these dirs being handled quite > inconsistently. > > Many are unowned, several are owned by individual packages (gettext, > hal, gawk ..., seems like packaging bugs to me), ... For gawk it's indeed a bug, and I already filed a report (unanswered yet) : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167181 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1447_FC4 Load : 3.91 1.70 0.85 From notting at redhat.com Tue Sep 6 04:35:30 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Sep 2005 00:35:30 -0400 Subject: [Fedora-packaging] Who owns /usr/share/locale/? In-Reply-To: <1125934262.25892.101.camel@mccallum.corsepiu.local> References: <1125934262.25892.101.camel@mccallum.corsepiu.local> Message-ID: <20050906043530.GA15075@nostromo.devel.redhat.com> Ralf Corsepius (rc040203 at freenet.de) said: > Who is supposed to own /usr/share/locale/? There's a bug open on this. The problem is, of course, it's impossible to programatically own the union of all possible languages. Bill From rc040203 at freenet.de Tue Sep 6 05:58:28 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 Sep 2005 07:58:28 +0200 Subject: [Fedora-packaging] Who owns /usr/share/locale/? In-Reply-To: <20050906043530.GA15075@nostromo.devel.redhat.com> References: <1125934262.25892.101.camel@mccallum.corsepiu.local> <20050906043530.GA15075@nostromo.devel.redhat.com> Message-ID: <1125986308.25892.193.camel@mccallum.corsepiu.local> On Tue, 2005-09-06 at 00:35 -0400, Bill Nottingham wrote: > Ralf Corsepius (rc040203 at freenet.de) said: > > Who is supposed to own /usr/share/locale/? > > There's a bug open on this. The problem is, of course, it's > impossible to programatically own the union of all possible > languages. OK. So what is the current "official" packaging policy? * Let each package own the /usr/share/locale/ dirs it uses? * Let /usr/share/locale/ dirs be unowned? The former would be a clear approach, while the latter seems sloppy to me, nevertheless seems to be what has been favored so far. Ralf From notting at redhat.com Tue Sep 6 15:13:00 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Sep 2005 11:13:00 -0400 Subject: [Fedora-packaging] Who owns /usr/share/locale/? In-Reply-To: <1125986308.25892.193.camel@mccallum.corsepiu.local> References: <1125934262.25892.101.camel@mccallum.corsepiu.local> <20050906043530.GA15075@nostromo.devel.redhat.com> <1125986308.25892.193.camel@mccallum.corsepiu.local> Message-ID: <20050906151300.GE17845@nostromo.devel.redhat.com> Ralf Corsepius (rc040203 at freenet.de) said: > > > Who is supposed to own /usr/share/locale/? > > > > There's a bug open on this. The problem is, of course, it's > > impossible to programatically own the union of all possible > > languages. > OK. So what is the current "official" packaging policy? > * Let each package own the /usr/share/locale/ dirs it uses? > * Let /usr/share/locale/ dirs be unowned? > The former would be a clear approach, while the latter seems sloppy to > me, nevertheless seems to be what has been favored so far. I don't think there *is* a policy. The former seems more practical, of course, you'll have to make sure everything has the same perms, etc. Bill From tcallawa at redhat.com Tue Sep 6 21:39:26 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 06 Sep 2005 16:39:26 -0500 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050707035300.GA21070@jadzia.bu.edu> References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> Message-ID: <1126042766.17919.11.camel@localhost.localdomain> I hate to revive a dead thread, but I don't think we came to a decision on this. Someone recently pointed out to me the existence of useradd -r and groupadd -r (they're Red Hat added functionality). When used, these commands create the first available UID and GID below UID_MAX and GID_MAX, as defined in /etc/login.defs. This seems to be doing roughly the same thing as fedora-usermgt. Does this seem like an acceptable way to create system user/groups in %post? ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From steve at silug.org Tue Sep 6 21:52:21 2005 From: steve at silug.org (Steven Pritchard) Date: Tue, 6 Sep 2005 16:52:21 -0500 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1126042766.17919.11.camel@localhost.localdomain> References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> Message-ID: <20050906215221.GA4412@osiris.silug.org> On Tue, Sep 06, 2005 at 04:39:26PM -0500, Tom 'spot' Callaway wrote: > Someone recently pointed out to me the existence of useradd -r and > groupadd -r (they're Red Hat added functionality). When used, these > commands create the first available UID and GID below UID_MAX and > GID_MAX, as defined in /etc/login.defs. > > This seems to be doing roughly the same thing as fedora-usermgt. Does > this seem like an acceptable way to create system user/groups in %post? My personal feeling (as a sysadmin and a packager) is that doing something like this in %pre (not %post, if you want files owned by the new user) is the Right Thing: %pre if ! id foo > /dev/null 2>&1 ; then /usr/sbin/useradd -r -s /sbin/nologin -c 'BAR' [...] foo fi And then just *don't touch the account* on removal. If this is the stated policy, then no sysadmin can be surprised by it. If unused accounts bother them, they can do "userdel foo" manually. If for some reason useradd will not work, doing this in %pre should make package installation fail, right? Then the sysadmin can go add the user in LDAP/NIS/whatever and reinstall the package. IMHO trying to support anything more elaborate than this is going to cause more problems than it solves... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From tcallawa at redhat.com Tue Sep 6 22:03:44 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 06 Sep 2005 17:03:44 -0500 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050906215221.GA4412@osiris.silug.org> References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> Message-ID: <1126044224.17919.12.camel@localhost.localdomain> On Tue, 2005-09-06 at 16:52 -0500, Steven Pritchard wrote: > On Tue, Sep 06, 2005 at 04:39:26PM -0500, Tom 'spot' Callaway wrote: > > Someone recently pointed out to me the existence of useradd -r and > > groupadd -r (they're Red Hat added functionality). When used, these > > commands create the first available UID and GID below UID_MAX and > > GID_MAX, as defined in /etc/login.defs. > > > > This seems to be doing roughly the same thing as fedora-usermgt. Does > > this seem like an acceptable way to create system user/groups in %post? > > My personal feeling (as a sysadmin and a packager) is that doing > something like this in %pre (not %post, if you want files owned by the > new user) is the Right Thing: > > %pre > if ! id foo > /dev/null 2>&1 ; then > /usr/sbin/useradd -r -s /sbin/nologin -c 'BAR' [...] foo > fi > > And then just *don't touch the account* on removal. If this is the > stated policy, then no sysadmin can be surprised by it. If unused > accounts bother them, they can do "userdel foo" manually. > > If for some reason useradd will not work, doing this in %pre should > make package installation fail, right? Then the sysadmin can go add > the user in LDAP/NIS/whatever and reinstall the package. > > IMHO trying to support anything more elaborate than this is going to > cause more problems than it solves... This all seems to make sense to me. Agree or disagree? ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Sep 6 22:12:42 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 7 Sep 2005 00:12:42 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1126044224.17919.12.camel@localhost.localdomain> References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> <1126044224.17919.12.camel@localhost.localdomain> Message-ID: <20050907001242.0ca4e933@python2> Tom 'spot' Callaway wrote : > On Tue, 2005-09-06 at 16:52 -0500, Steven Pritchard wrote: > > On Tue, Sep 06, 2005 at 04:39:26PM -0500, Tom 'spot' Callaway wrote: > > > Someone recently pointed out to me the existence of useradd -r and > > > groupadd -r (they're Red Hat added functionality). When used, these > > > commands create the first available UID and GID below UID_MAX and > > > GID_MAX, as defined in /etc/login.defs. > > > > > > This seems to be doing roughly the same thing as fedora-usermgt. Does > > > this seem like an acceptable way to create system user/groups in %post? > > > > My personal feeling (as a sysadmin and a packager) is that doing > > something like this in %pre (not %post, if you want files owned by the > > new user) is the Right Thing: > > > > %pre > > if ! id foo > /dev/null 2>&1 ; then > > /usr/sbin/useradd -r -s /sbin/nologin -c 'BAR' [...] foo > > fi > > > > And then just *don't touch the account* on removal. If this is the > > stated policy, then no sysadmin can be surprised by it. If unused > > accounts bother them, they can do "userdel foo" manually. > > > > If for some reason useradd will not work, doing this in %pre should > > make package installation fail, right? Then the sysadmin can go add > > the user in LDAP/NIS/whatever and reinstall the package. > > > > IMHO trying to support anything more elaborate than this is going to > > cause more problems than it solves... > > This all seems to make sense to me. Agree or disagree? I tend to agree, and personally dislike the added complexity of this fedora-usermgmt that got imported from the fedora.us days. But I also think that in some cases, fixed uid/gids are best, most importantly when chances of having files shared across machines are high, like with apache (uid/gid 48) owned files for instance. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1447_FC4 Load : 0.14 0.39 0.21 From enrico.scholz at informatik.tu-chemnitz.de Tue Sep 6 22:13:05 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 07 Sep 2005 00:13:05 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1126042766.17919.11.camel@localhost.localdomain> (Tom Callaway's message of "Tue, 06 Sep 2005 16:39:26 -0500") References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> Message-ID: <87ll29hmku.fsf@kosh.bigo.ensc.de> tcallawa at redhat.com ("Tom 'spot' Callaway") writes: > Someone recently pointed out to me the existence of useradd -r and > groupadd -r (they're Red Hat added functionality). When used, these > commands create the first available UID and GID below UID_MAX and > GID_MAX, as defined in /etc/login.defs. > > This seems to be doing roughly the same thing as fedora-usermgt. fedora-usermgt does more. It can assign the same uid/gid for a user in the entire system. With plain 'useradd -r', users can/will have different ids on different machines which is very bad with NFS mounts or in chroot environments. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Tue Sep 6 22:29:56 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 07 Sep 2005 00:29:56 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050906215221.GA4412@osiris.silug.org> (Steven Pritchard's message of "Tue, 6 Sep 2005 16:52:21 -0500") References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> Message-ID: <87hdcxhlsr.fsf@kosh.bigo.ensc.de> steve at silug.org (Steven Pritchard) writes: > My personal feeling (as a sysadmin and a packager) is that doing > something like this in %pre (not %post, if you want files owned by > the new user) is the Right Thing: > > %pre > if ! id foo > /dev/null 2>&1 ; then > /usr/sbin/useradd -r -s /sbin/nologin -c 'BAR' [...] foo > fi This does not solve the problem that users will have different UIDs on different machines. > And then just *don't touch the account* on removal. This rule is ok with me. > If for some reason useradd will not work, doing this in %pre should > make package installation fail, right? Then the sysadmin can go add > the user in LDAP/NIS/whatever and reinstall the package. IMO, managing service-accounts with LDAP/NIS is a bad idea. It is ideal for normal users but I do not want to rely on them for services. You will run into bootstrap issues (e.g. think of slapd which tries to resolve the 'ldap' user), configuration errors like outdated TLS certificates (which make LDAP lookups impossible) or added complexity for critical services (I saw enough problems with nss_ldap and nscd). Additionally, there is no way to see whether users are created by an rpm package or which parameters are used for these users. So it is not possible to create users on the LDAP server *before* the package is installed. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Tue Sep 6 22:38:10 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 07 Sep 2005 00:38:10 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050907001242.0ca4e933@python2> (Matthias Saou's message of "Wed, 7 Sep 2005 00:12:42 +0200") References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> <1126044224.17919.12.camel@localhost.localdomain> <20050907001242.0ca4e933@python2> Message-ID: <87d5nlhlf1.fsf@kosh.bigo.ensc.de> thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes: >> > > Someone recently pointed out to me the existence of useradd -r and >> > > groupadd -r (they're Red Hat added functionality). When used, these >> > > commands create the first available UID and GID below UID_MAX and >> > > GID_MAX, as defined in /etc/login.defs. > ... > I tend to agree, and personally dislike the added complexity of this > fedora-usermgmt Which added complexity? Usage of fedora-usermgmt is very simple: 1. Register a user/uid pair at http://fedoraproject.org/wiki/PackageUserRegistry 2. Add a 'Requires(pre): fedora-usermgmt' (which replaces the shadowutils counterpart). Complains about this additional dependency are bogus in the age of smartpm or yum. 3. Call 'fedora-useradd' with an additional parameter (the uid) Additional configuration is very simple also; when you want semi-static uids: 1. just activate the mode with | /usr/sbin/update-alternatives --set fedora-usermgmt /etc/fedora/usermgmt/scripts.shadow-utils 2. configure your prefered baseuids/gids in /etc/fedora/usermgmt/base[gu]id (which are simple textfiles). This setup can be done easily e.g. with custom configuration-package or cfengine. > that got imported from the fedora.us days. But I also think that in > some cases, fixed uid/gids are best, most importantly when chances of > having files shared across machines are high, My experiences show that this applies to most packages. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Sep 6 22:37:54 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 7 Sep 2005 00:37:54 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <87hdcxhlsr.fsf@kosh.bigo.ensc.de> References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> <87hdcxhlsr.fsf@kosh.bigo.ensc.de> Message-ID: <20050907003754.62a7d5df@python2> Enrico Scholz wrote : > This does not solve the problem that users will have different UIDs on > different machines. Regarding fixed uid/gid pairs, I fail to see where fedora-usermgmt improves anything over a default useradd/groupadd. If it's the configurable offset, then it's the opposite : It brings back the possibility of having different uid/gid pairs on differently configured machines... ...or am I missing something? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1447_FC4 Load : 0.28 0.64 0.63 From enrico.scholz at informatik.tu-chemnitz.de Tue Sep 6 22:45:51 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 07 Sep 2005 00:45:51 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050907003754.62a7d5df@python2> (Matthias Saou's message of "Wed, 7 Sep 2005 00:37:54 +0200") References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> <87hdcxhlsr.fsf@kosh.bigo.ensc.de> <20050907003754.62a7d5df@python2> Message-ID: <878xy9hl28.fsf@kosh.bigo.ensc.de> thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes: >> This does not solve the problem that users will have different UIDs >> on different machines. > > Regarding fixed uid/gid pairs, I fail to see where fedora-usermgmt > improves anything over a default useradd/groupadd. If it's the > configurable offset, then it's the opposite : It brings back the > possibility of having different uid/gid pairs on differently configured > machines... > > ...or am I missing something? Yes... you can configure different machines in the same way (e.g. with cfengine or a custom 'setup(fedora-usermgmt)' package in the local repository which provides common base[ug]id files). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From rc040203 at freenet.de Wed Sep 7 05:32:58 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 Sep 2005 07:32:58 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <87hdcxhlsr.fsf@kosh.bigo.ensc.de> References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> <87hdcxhlsr.fsf@kosh.bigo.ensc.de> Message-ID: <1126071178.22372.146.camel@mccallum.corsepiu.local> On Wed, 2005-09-07 at 00:29 +0200, Enrico Scholz wrote: > steve at silug.org (Steven Pritchard) writes: > > > My personal feeling (as a sysadmin and a packager) is that doing > > something like this in %pre (not %post, if you want files owned by > > the new user) is the Right Thing: > > > > %pre > > if ! id foo > /dev/null 2>&1 ; then > > /usr/sbin/useradd -r -s /sbin/nologin -c 'BAR' [...] foo > > fi > > This does not solve the problem that users will have different UIDs on > different machines. Note the -r. We are talking about system accounts. I fail to see why system accounts should be shared across networks and why there is any need to force unique UIDs on them. IMO, system users must be local, only. > > And then just *don't touch the account* on removal. > > This rule is ok with me. Not OK with me. Cf. above. The only reason for not wanting to remove accounts on package removal to me is "accounts leaving stray files somewhere". However, rpms should have always have control over all files it owns. > > If for some reason useradd will not work, doing this in %pre should > > make package installation fail, right? Then the sysadmin can go add > > the user in LDAP/NIS/whatever and reinstall the package. > > IMO, managing service-accounts with LDAP/NIS is a bad idea. ACK. Ralf From Christian.Iseli at licr.org Wed Sep 7 06:32:17 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 07 Sep 2005 08:32:17 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: Your message of "Wed, 07 Sep 2005 07:32:58 +0200." <1126071178.22372.146.camel@mccallum.corsepiu.local> Message-ID: <200509070632.j876WWKI030653@mx1.redhat.com> rc040203 at freenet.de said: > I fail to see why system accounts should be shared across networks and why > there is any need to force unique UIDs on them. > IMO, system users must be local, only. +1 Looks like the opinions of the various people didn't change much since the last round :-) rc040203 at freenet.de said: > The only reason for not wanting to remove accounts on package removal to me > is "accounts leaving stray files somewhere". > However, rpms should have always have control over all files it owns. Well, there are many cases of packages producing some files while they run, which they will not own. E.g., root: rpm -qf /var/log/mysqld.log.4 file /var/log/mysqld.log.4 is not owned by any package root: ls -l /var/log/mysqld.log.4 -rw-r----- 1 mysql mysql 0 Aug 7 03:02 /var/log/mysqld.log.4 So I think the UID should stay... until the sysadm removes it. Cheers, Christian From rc040203 at freenet.de Wed Sep 7 08:37:06 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 Sep 2005 10:37:06 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <200509070632.j876WWKI030653@mx1.redhat.com> References: <200509070632.j876WWKI030653@mx1.redhat.com> Message-ID: <1126082226.22372.155.camel@mccallum.corsepiu.local> On Wed, 2005-09-07 at 08:32 +0200, Christian.Iseli at licr.org wrote: > rc040203 at freenet.de said: > > The only reason for not wanting to remove accounts on package removal to me > > is "accounts leaving stray files somewhere". > > > However, rpms should have always have control over all files it owns. > > Well, there are many cases of packages producing some files while they run, That's why I said "should". It is possible in many cases (%postun, %ghost or %triggerun scripts), but won't be possible or useful in all cases. E.g. I would not want an mysql update remove my mysql data bases. > which they will not own. E.g., > > root: rpm -qf /var/log/mysqld.log.4 > file /var/log/mysqld.log.4 is not owned by any package > root: ls -l /var/log/mysqld.log.4 > -rw-r----- 1 mysql mysql 0 Aug 7 03:02 /var/log/mysqld.log.4 > > So I think the UID should stay... until the sysadm removes it. IMO, this is an example where removing files is possible: E.g. %postun rm -f /var/log/mysqld.log* Ralf From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 7 09:11:57 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 07 Sep 2005 11:11:57 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> <87hdcxhlsr.fsf@kosh.bigo.ensc.de> <1126071178.22372.146.camel@mccallum.corsepiu.local> Message-ID: <87ek81kzs2.fsf@kosh.bigo.ensc.de> rc040203 at freenet.de (Ralf Corsepius) writes: >> > My personal feeling (as a sysadmin and a packager) is that doing >> > something like this in %pre (not %post, if you want files owned by >> > the new user) is the Right Thing: >> > >> > %pre >> > if ! id foo > /dev/null 2>&1 ; then >> > /usr/sbin/useradd -r -s /sbin/nologin -c 'BAR' [...] foo >> > fi >> >> This does not solve the problem that users will have different UIDs on >> different machines. > Note the -r. We are talking about system accounts. The '-r' makes only * that the generated UID is in a certain range; the exact values are unpredictable and it's highly probably that they differ on different machines * that there is no expiration date for the account (that's why '-r' should be used with fedora-usermgmt also) > I fail to see why system accounts should be shared across networks and > why there is any need to force unique UIDs on them. ok, some examples: * 'vdr' and 'vdradmin' (from livna) are running on different hosts as the 'vdr:video' user. Both share configuration files and data which is exported by NFS * some data in a shared filesystem which shall be read by apache only but not by other users -> all affected machines will need the same uid/gid for apache * programs (e.g. milters) which are installed in chroot environments and use unix-sockets as communication points. Access restrictions can be installed easily with filesystem permissions when all chroots are seeing the same user-uid pairs * backup/copying between hosts; when user does not exist at the destination yet, resulting files will be readable by the wrong user * the 'owner' module of iptables requires predictable uids * it is confusing and unesthetically when users are having different identities > IMO, system users must be local, only. Yes; but they can access/own files on shared filesystems so all systems should have the same view about them. It is easy to create users with predictable uids and fedora-usermgmt offers a simple method doing this. I am not aware of any drawbacks, it solves the problem of unpredictable uids and without explicit configuration it is transparent to users because it has the same behavior as plain 'useradd' then. So I do not see reasons why it should not be used. Enrico From Christian.Iseli at licr.org Wed Sep 7 09:18:02 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 07 Sep 2005 11:18:02 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: Your message of "Wed, 07 Sep 2005 10:37:06 +0200." <1126082226.22372.155.camel@mccallum.corsepiu.local> Message-ID: <200509070918.j879I2l0007908@ludwig-alpha.unil.ch> rc040203 at freenet.de said: > Christian.Iseli at licr.org wrote: > > rc040203 at freenet.de said: > > > The only reason for not wanting to remove accounts on package removal to me > > > is "accounts leaving stray files somewhere". > > > > > However, rpms should have always have control over all files it owns. > > > > Well, there are many cases of packages producing some files while they run, > That's why I said "should". > > It is possible in many cases (%postun, %ghost or %triggerun scripts), but > won't be possible or useful in all cases. > > E.g. I would not want an mysql update remove my mysql data bases. Which is precisely why I think the ID should not be automatically removed... Yes, I also used "should" :-) There certainly are packages where removing the ID is fine, but I think the general rule should be conservative. > > which they will not own. E.g., > > > > root: rpm -qf /var/log/mysqld.log.4 > > file /var/log/mysqld.log.4 is not owned by any package > > root: ls -l /var/log/mysqld.log.4 > > -rw-r----- 1 mysql mysql 0 Aug 7 03:02 /var/log/mysqld.log.4 > > > > So I think the UID should stay... until the sysadm removes it. > IMO, this is an example where removing files is possible: > > E.g. > > %postun > rm -f /var/log/mysqld.log* I agree. I only spent a few seconds looking for some valid example of unowned files. But I suspect there are tougher nuts. Christian From Christian.Iseli at licr.org Wed Sep 7 09:28:17 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 07 Sep 2005 11:28:17 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: Your message of "Wed, 07 Sep 2005 11:11:57 +0200." <87ek81kzs2.fsf@kosh.bigo.ensc.de> Message-ID: <200509070928.j879SHIh008060@ludwig-alpha.unil.ch> enrico.scholz at informatik.tu-chemnitz.de said: > It is easy to create users with predictable uids and fedora-usermgmt offers a > simple method doing this. IIUC, fedora-usermgmt looks the ID up on some wiki page somewhere ? So, you need a machine connected to the Internet. I think it's a problem. If you really want a fixed ID, why not hardcode it in the package itself ? Christian From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 7 09:55:26 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 07 Sep 2005 11:55:26 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <200509070928.j879SHIh008060@ludwig-alpha.unil.ch> (Christian Iseli's message of "Wed, 07 Sep 2005 11:28:17 +0200") References: <87ek81kzs2.fsf@kosh.bigo.ensc.de> <200509070928.j879SHIh008060@ludwig-alpha.unil.ch> Message-ID: <87acipkxrl.fsf@kosh.bigo.ensc.de> Christian.Iseli at licr.org writes: >> It is easy to create users with predictable uids and fedora-usermgmt >> offers a simple method doing this. > > IIUC, fedora-usermgmt looks the ID up on some wiki page somewhere ? No; you are telling the uid (ditto for gids) in a way like | %pre | fedora-useradd 23 -r ... foo The '23' was "requested" by adding a corresponding entry into the wiki (http://fedoraproject.org/wiki/PackageUserRegistry) and written statically into the spec-file. By default, this hint will be ignored. But when enabling it with /usr/sbin/update-alternatives --set fedora-usermgmt /etc/fedora/usermgmt/scripts.shadow-utils user 'foo' will get a static uid of BASE+23 where BASE is configured in /etc/fedora/usermgmt/baseuid. When you set BASE to the same value on all machines, user 'foo' will have the same uid everywhere. Making BASE configurable is necessary because there does not exist a free range for static uids; only 0-99 is reserved for static uids but too small for FE. All other uid ranges might fall under local policies and are not available. Enrico From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Sep 7 09:58:01 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 7 Sep 2005 11:58:01 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <200509070928.j879SHIh008060@ludwig-alpha.unil.ch> References: <87ek81kzs2.fsf@kosh.bigo.ensc.de> <200509070928.j879SHIh008060@ludwig-alpha.unil.ch> Message-ID: <20050907115801.6ca729c1@python2> Christian.Iseli at licr.org wrote : > enrico.scholz said: > > It is easy to create users with predictable uids and fedora-usermgmt offers a > > simple method doing this. > > IIUC, fedora-usermgmt looks the ID up on some wiki page somewhere ? > So, you need a machine connected to the Internet. > I think it's a problem. > If you really want a fixed ID, why not hardcode it in the package itself ? The fixed id is in the package itself (without the offset), which is why I fail to see any reason to add a dependency on some custom user management scripts when plain useradd/groupadd is sufficient. There are two mixed discussions here : - Should we rely on fedora-usermgmt from fedora.us to manage system users? - Should some system users have fixed uid/gid pairs? Those are two completely separate debates, to which I personally answer "no" and "yes" respectively. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1447_FC4 Load : 0.29 1.13 1.29 From rc040203 at freenet.de Wed Sep 7 10:06:37 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 Sep 2005 12:06:37 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <87ek81kzs2.fsf@kosh.bigo.ensc.de> References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> <87hdcxhlsr.fsf@kosh.bigo.ensc.de> <1126071178.22372.146.camel@mccallum.corsepiu.local> <87ek81kzs2.fsf@kosh.bigo.ensc.de> Message-ID: <1126087598.22372.199.camel@mccallum.corsepiu.local> On Wed, 2005-09-07 at 11:11 +0200, Enrico Scholz wrote: > rc040203 at freenet.de (Ralf Corsepius) writes: > > >> > My personal feeling (as a sysadmin and a packager) is that doing > >> > something like this in %pre (not %post, if you want files owned by > >> > the new user) is the Right Thing: > >> > > >> > %pre > >> > if ! id foo > /dev/null 2>&1 ; then > >> > /usr/sbin/useradd -r -s /sbin/nologin -c 'BAR' [...] foo > >> > fi > >> > >> This does not solve the problem that users will have different UIDs on > >> different machines. > > Note the -r. We are talking about system accounts. > > The '-r' makes only > > * that the generated UID is in a certain range; the exact values are > unpredictable and it's highly probably that they differ on different > machines Yes, but ... who cares? All that matters is using consistent ranges in a local network. > > I fail to see why system accounts should be shared across networks and > > why there is any need to force unique UIDs on them. > > ok, some examples: > > * 'vdr' and 'vdradmin' (from livna) are running on different hosts as > the 'vdr:video' user. Both share configuration files and data which is > exported by NFS Then these UID/GIDs probably better should be ordinary uids, instead of system-user ids. > * some data in a shared filesystem which shall be read by apache only > but not by other users -> all affected machines will need the same > uid/gid for apache To me this is a classical case of a customized network setup. It's the admin's responsibility to synchronize the uids. I am doing the same with other dirs on my local network. > * programs (e.g. milters) which are installed in chroot environments and > use unix-sockets as communication points. Access restrictions can be > installed easily with filesystem permissions when all chroots are > seeing the same user-uid pairs I can't comment on these. > * backup/copying between hosts; when user does not exist at the destination > yet, resulting files will be readable by the wrong user Yes, local network admin responsibility. > * the 'owner' module of iptables requires predictable uids I can't comment on this. > * it is confusing and unesthetically when users are having different > identities Let me turn this coin around: You are trying to be stylish and seem to be trying to project your personal conventions to the public. You are missing: * These points are irrelevant in heterogenious networks. Each OS has different conventions, so any convention is always somehow wrong and requires hand-crafting. * Using fixed uids unnecessarily restricts the number of available uids. You will sooner or later face the problems of all fixed-table based configuration approaches. * There is nothing which prevents you to generate consistent uids in your network. > > IMO, system users must be local, only. > > Yes; but they can access/own files on shared filesystems so all systems Depends on your setup. > should have the same view about them. I don't understand. > It is easy to create users with predictable uids and fedora-usermgmt > offers a simple method doing this. I am not aware of any drawbacks, > it solves the problem of unpredictable uids and without explicit > configuration it is transparent to users because it has the same > behavior as plain 'useradd' then. So I do not see reasons why it > should not be used. Frankly speaking, I am no friend of fedora-usermgmt. To the same extent it might help you, it interferes with my demands. Ralf From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 7 10:21:25 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 07 Sep 2005 12:21:25 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050907115801.6ca729c1@python2> (Matthias Saou's message of "Wed, 7 Sep 2005 11:58:01 +0200") References: <87ek81kzs2.fsf@kosh.bigo.ensc.de> <200509070928.j879SHIh008060@ludwig-alpha.unil.ch> <20050907115801.6ca729c1@python2> Message-ID: <8764tdkwka.fsf@kosh.bigo.ensc.de> thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes: >> > It is easy to create users with predictable uids and fedora-usermgmt >> > offers a simple method doing this. >> >> IIUC, fedora-usermgmt looks the ID up on some wiki page somewhere ? >> So, you need a machine connected to the Internet. >> I think it's a problem. >> If you really want a fixed ID, why not hardcode it in the package itself ? > > The fixed id is in the package itself (without the offset), which is why I > fail to see any reason to add a dependency on some custom user management > scripts when plain useradd/groupadd is sufficient. Ok, you could do | useradd -u $[ $(cat /etc/fedora/usermgmt/baseuid) + 23 ] ... in every %scriptlet also. But when adding sanity checks and fallback methods for the traditional 'useradd', this will end in >5 lines of complex and redundant code in the %scriptlets. 'fedora-usermgmt' provides a high grade of customization: by writing own backends, e.g. you can calculate the final uid/gid by ldap lookups (which might be needed in environments with a high uid-dense). Writing scripts like above restricts you to exactly one configuration scheme. Using the wrapper method (where fedora-usermgmt is a such one) simplifies the scriptlets significantly in other aspects also. Currently there are several methods how to add users. Some people use simple | useradd ... &>/dev/null || : other | grep '' /etc/password || useradd ... other | id '' || useradd ... or ... Using a wrapper like 'fedora-useradd' can do this steps in a common (and configurable) way. > There are two mixed discussions here : > - Should we rely on fedora-usermgmt from fedora.us to manage system users? I do not insist on this implementation, but IMO it is clean and offers lot of ways to adapt it to your needs. > - Should some system users have fixed uid/gid pairs? At the end, it will not make a difference if these are only 'some' or 'all' system users. Enrico From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 7 10:35:47 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 07 Sep 2005 12:35:47 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1126087598.22372.199.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Wed, 07 Sep 2005 12:06:37 +0200") References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> <87hdcxhlsr.fsf@kosh.bigo.ensc.de> <1126071178.22372.146.camel@mccallum.corsepiu.local> <87ek81kzs2.fsf@kosh.bigo.ensc.de> <1126087598.22372.199.camel@mccallum.corsepiu.local> Message-ID: <871x41kvwc.fsf@kosh.bigo.ensc.de> rc040203 at freenet.de (Ralf Corsepius) writes: >> > I fail to see why system accounts should be shared across networks and >> > why there is any need to force unique UIDs on them. >> >> ok, some examples: >> >> * 'vdr' and 'vdradmin' (from livna) are running on different hosts as >> the 'vdr:video' user. Both share configuration files and data which is >> exported by NFS > Then these UID/GIDs probably better should be ordinary uids, instead of > system-user ids. These users are created by an rpm, this package contains files owned by them and they are set in global configuration files. So, they must be system accounts. >> * some data in a shared filesystem which shall be read by apache only >> but not by other users -> all affected machines will need the same >> uid/gid for apache > To me this is a classical case of a customized network setup. It's the > admin's responsibility to synchronize the uids. There is no way to see whether an rpm package creates an account or to determine the parameters of this account. >> * it is confusing and unesthetically when users are having different >> identities > Let me turn this coin around: You are trying to be stylish and seem to > be trying to project your personal conventions to the public. > > You are missing: > * These points are irrelevant in heterogenious networks. Each OS has > different conventions, so any convention is always somehow wrong and > requires hand-crafting. The uid/gid concept exists on all Posix compliant systems. 'fedora-usermgmt' would work fine e.g. on Solaris also. > * Using fixed uids unnecessarily restricts the number of available uids. > You will sooner or later face the problems of all fixed-table based > configuration approaches. I do not expect that the number of registered UIDs reaches a range where this is critical. And when you have really an environment without a free range of perhaps 1000-2000 uids, then write your own 'fedora-usermgmt' backend which calculates the resulting UID in a clever way. >> It is easy to create users with predictable uids and fedora-usermgmt >> offers a simple method doing this. I am not aware of any drawbacks, >> it solves the problem of unpredictable uids and without explicit >> configuration it is transparent to users because it has the same >> behavior as plain 'useradd' then. So I do not see reasons why it >> should not be used. > > Frankly speaking, I am no friend of fedora-usermgmt. To the same extent > it might help you, it interferes with my demands. Where does it interferes with your demands? When you did nothing (used fedora-usermgmt out-of-the-box), there is no difference to the plain 'useradd'. When you did something, you did it wrong perhaps or encountered a bug in fedora-usermgmt. Enrico From Christian.Iseli at licr.org Wed Sep 7 11:48:23 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 07 Sep 2005 13:48:23 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: Your message of "Wed, 07 Sep 2005 12:21:25 +0200." <8764tdkwka.fsf@kosh.bigo.ensc.de> Message-ID: <200509071148.j87BmNIv009707@ludwig-alpha.unil.ch> enrico.scholz at informatik.tu-chemnitz.de said: > you could do > | useradd -u $[ $(cat /etc/fedora/usermgmt/baseuid) + 23 ] ... Hmm. If all you're trying to achieve is to have a default fixed UID, but still allow for some local customization, why not something along the lines of: | %{name}_UID=${%{name}_UID:-23} | useradd -u $%{name}_UID And then the admin who wants to customize package foo can run: $ foo_UID=1012 rpm -ivh foo-1.0-1.blah.rpm or $ foo_UID=1012 yum install foo (Note that I haven't tested this...) Christian From aoliva at redhat.com Wed Sep 7 13:20:20 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 07 Sep 2005 10:20:20 -0300 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <871x41kvwc.fsf@kosh.bigo.ensc.de> References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> <87hdcxhlsr.fsf@kosh.bigo.ensc.de> <1126071178.22372.146.camel@mccallum.corsepiu.local> <87ek81kzs2.fsf@kosh.bigo.ensc.de> <1126087598.22372.199.camel@mccallum.corsepiu.local> <871x41kvwc.fsf@kosh.bigo.ensc.de> Message-ID: On Sep 7, 2005, Enrico Scholz wrote: > These users are created by an rpm, this package contains files owned by > them and they are set in global configuration files. So, they must be > system accounts. Err... The rpm cpio payload contains user ids encoded in the form of user/group names, not numbers, I hope, just like tar. Doesn't it? If so, all it takes to get a single, consistent uid is to add the username to the central uid database before installing the rpms anywhere, then the system will find the users to exist and install the contents with the right uid. If you have your hosts configured to trust the database over local user info, and you've already installed rpms before that chose random uids, then you might have to remove the local user by hand and reinstall the packages. > There is no way to see whether an rpm package creates an account or to > determine the parameters of this account. Should we perhaps think of abstracting out user ids into separate rpm packages? It sounds yucky at first, but it would be a clean way to address the issue of removing lingering accounts or not. The account would be brought in as a dependency of the actual package, but wouldn't be removed automatically when the package is removed, but there would be a clean, simple, standard way to remove it. > The uid/gid concept exists on all Posix compliant systems. 'fedora-usermgmt' > would work fine e.g. on Solaris also. Heck, it would probably work even on Cygwin :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Wed Sep 7 13:23:11 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 07 Sep 2005 10:23:11 -0300 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1126071178.22372.146.camel@mccallum.corsepiu.local> References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> <87hdcxhlsr.fsf@kosh.bigo.ensc.de> <1126071178.22372.146.camel@mccallum.corsepiu.local> Message-ID: On Sep 7, 2005, Ralf Corsepius wrote: > The only reason for not wanting to remove accounts on package removal to > me is "accounts leaving stray files somewhere". > However, rpms should have always have control over all files it owns. Unfortunately rpms can't hunt for backup tapes containing and wipe content out of them just to keep them consistent. When you restore data from a backup tape, wouldn't it be nice to still have the user that owned that data? That's why it's policy on several locations to never ever reuse uids. If you need a new account, get the next available uid. If you need to close an account, change its password and shell to something unusable, and that's it. Leave the user information alone. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 7 14:07:19 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 07 Sep 2005 16:07:19 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: (Alexandre Oliva's message of "07 Sep 2005 10:20:20 -0300") References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> <87hdcxhlsr.fsf@kosh.bigo.ensc.de> <1126071178.22372.146.camel@mccallum.corsepiu.local> <87ek81kzs2.fsf@kosh.bigo.ensc.de> <1126087598.22372.199.camel@mccallum.corsepiu.local> <871x41kvwc.fsf@kosh.bigo.ensc.de> Message-ID: <87k6htas4o.fsf@kosh.bigo.ensc.de> aoliva at redhat.com (Alexandre Oliva) writes: >> These users are created by an rpm, this package contains files owned >> by them and they are set in global configuration files. So, they must >> be system accounts. > > Err... The rpm cpio payload contains user ids encoded in the form of > user/group names, not numbers, I hope, just like tar. Doesn't it? If > so, all it takes to get a single, consistent uid is to add the > username to the central uid database "central uid database" implicates something like LDAP or NIS. But as explained in previous postings, LDAP/NIS is a bad idea for service accounts. > before installing the rpms anywhere, When doing an 'yum install ' which adds 100 new packages, it is impossible to determine which users will be created in this transaction. > then the system will find the users to exist and install the contents > with the right uid. If you have your hosts configured to trust the > database over local user info, and you've already installed rpms > before that chose random uids, then you might have to remove the > local user by hand and reinstall the packages. Yes, I remember some 'find -uid ... | xargs chown'. Such actions are tending to evolve to a huge mess, especially when a '-h' flag was forgotten or already assigned uids were used... That's why I prefer (semi)static uids for all service accounts. >> There is no way to see whether an rpm package creates an account or to >> determine the parameters of this account. > > Should we perhaps think of abstracting out user ids into separate rpm > packages? Ok with me, but there are enough people who will complain about added dependencies... IMO; created users should be declared in rpm in a way like files and their creation should be done without explicit scriptlets. But this enhancement will not happen in the near future. Enrico From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 7 14:21:13 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 07 Sep 2005 16:21:13 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <200509071148.j87BmNIv009707@ludwig-alpha.unil.ch> (Christian Iseli's message of "Wed, 07 Sep 2005 13:48:23 +0200") References: <8764tdkwka.fsf@kosh.bigo.ensc.de> <200509071148.j87BmNIv009707@ludwig-alpha.unil.ch> Message-ID: <87fysharhi.fsf@kosh.bigo.ensc.de> Christian.Iseli at licr.org writes: >> | useradd -u $[ $(cat /etc/fedora/usermgmt/baseuid) + 23 ] ... > > Hmm. If all you're trying to achieve is to have a default fixed UID, but > still allow for some local customization, why not something along the lines of: > > | %{name}_UID=${%{name}_UID:-23} > | useradd -u $%{name}_UID Interesting idea. But it suffers from the same complex-scriptlet problem which was explained later in the cited posting. It has the additional problem that it is difficultly to handle; you will have to write wrappers for all rpm aware tools so that the *_UID environment is set for them (e.g. think on system initialization which adds 400-500 packages and 20-30 new users in one 'yum install' transaction). It requires high maintenance also because it will miss new accounts else. 'fedora-usermgmt' has to be configured only once (or keep it as-is, when the functionality is not needed) and has very simple %scriptlets. Enrico From jspaleta at gmail.com Wed Sep 7 15:43:39 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 7 Sep 2005 11:43:39 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <200509071148.j87BmNIv009707@ludwig-alpha.unil.ch> References: <8764tdkwka.fsf@kosh.bigo.ensc.de> <200509071148.j87BmNIv009707@ludwig-alpha.unil.ch> Message-ID: <604aa79105090708433fde52b8@mail.gmail.com> On 9/7/05, Christian.Iseli at licr.org wrote: > And then the admin who wants to customize package foo can run: > $ foo_UID=1012 rpm -ivh foo-1.0-1.blah.rpm > or > $ foo_UID=1012 yum install foo this very much assumes that you know exactly what packages by name you want to install. When using rpm on the cmdline that might very well be the case, since you are forced to explictly add deps to the calling command. Using yum groupinstall or yum install which pulls in deps is going to quickly lead to problems unless you do a lot of work reviewing exactly which packages are going to be installed so you can setup the environment variables for each package that might be pulled in via an install request. Fragile very very fragile. And as soon as we start seeing gui yum-aware tools mature, having to manipulate environment variables is going to seem a bit more arcane. I can only imagine how much fun playing with all those per package environment variables would be in a kickstarted yum-aware install. Ideally a solution that will work equally well for whatever rpm-aware/yum-aware tool that local admin wants to use. Packages that use the fedora-usermgmt approach should work equally well for whatever package mangement tool you choose to use. Assuming there is no perfect solution here..exactly what is the drawback with the fedora-usermgmt approach compared to other approaches. Is complexity the only percieved problem? Its going to be a much bigger maintainence problem over time trying to have each packager write and maintain their own scriplet logic.... especially when there is no clear policy on the specifics on uid/gid creation to follow moving forward. The more logic you can shove off into an on-system script the more freedom you have to adjust the default policy on down the road without having to rebuild the world to adjust each specfile. Having individual packagers implement the full script in individual specfiles is asking for the approach to be cast-in-stone. Considering the lack of consensous so far among the informed people in this discussion, I would strongly encourage avoiding hardwiring this policy into individual specfiles to avoid more "historical" problems in the future. Pick a wrapper solution, adjust the wrapper as needed as thoughts on the specifics evolve. -jef From dominik at greysector.net Wed Sep 7 17:58:24 2005 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 7 Sep 2005 19:58:24 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <871x41kvwc.fsf@kosh.bigo.ensc.de> References: <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> <87hdcxhlsr.fsf@kosh.bigo.ensc.de> <1126071178.22372.146.camel@mccallum.corsepiu.local> <87ek81kzs2.fsf@kosh.bigo.ensc.de> <1126087598.22372.199.camel@mccallum.corsepiu.local> <871x41kvwc.fsf@kosh.bigo.ensc.de> Message-ID: <20050907175824.GC29841@rathann.pekin.waw.pl> On Wednesday, 07 September 2005 at 12:35, Enrico Scholz wrote: > rc040203 at freenet.de (Ralf Corsepius) writes: [...] > >> * some data in a shared filesystem which shall be read by apache only > >> but not by other users -> all affected machines will need the same > >> uid/gid for apache > > To me this is a classical case of a customized network setup. It's the > > admin's responsibility to synchronize the uids. > > There is no way to see whether an rpm package creates an account or to > determine the parameters of this account. What about adding Provides: username(uid) Provides: groupname(gid) or something along these lines? Regards, R. -- APT/YUM RPM repository for Fedora http://rpm.greysector.net/ mpg321, xmp, faad2, lame, mad, *mplayer*, rdesktop, tin, xvid, mks, mutt "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From aoliva at redhat.com Wed Sep 7 18:38:18 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 07 Sep 2005 15:38:18 -0300 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <87k6htas4o.fsf@kosh.bigo.ensc.de> References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> <87hdcxhlsr.fsf@kosh.bigo.ensc.de> <1126071178.22372.146.camel@mccallum.corsepiu.local> <87ek81kzs2.fsf@kosh.bigo.ensc.de> <1126087598.22372.199.camel@mccallum.corsepiu.local> <871x41kvwc.fsf@kosh.bigo.ensc.de> <87k6htas4o.fsf@kosh.bigo.ensc.de> Message-ID: On Sep 7, 2005, Enrico Scholz wrote: > "central uid database" implicates something like LDAP or NIS. Nah... It might as well be something based on GNU Ad HoC, cfengine or something even simpler based on rdist. > Yes, I remember some 'find -uid ... | xargs chown'. Such actions are > tending to evolve to a huge mess, especially when a '-h' flag was > forgotten or already assigned uids were used... Yuck -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From Christian.Iseli at licr.org Wed Sep 7 19:57:14 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 07 Sep 2005 21:57:14 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: Your message of "Wed, 07 Sep 2005 11:43:39 EDT." <604aa79105090708433fde52b8@mail.gmail.com> Message-ID: <200509071957.j87JvQNF031256@mx1.redhat.com> jspaleta at gmail.com said: > Assuming there is no perfect solution here..exactly what is the drawback with > the fedora-usermgmt approach compared to other approaches. Is complexity the > only percieved problem? My opinion (all mine :-) ): 1. I haven't seen a convincing argument why FE packages need to add fixed IDs 2. If it is deemed so important to have fixed IDs, why doesn't Fedora Core provide a mechanism to add them ? Even if I can be convinced at some point that fixed IDs are really needed, I doubt the proper place for the mechanism is in FE. Christian From jspaleta at gmail.com Wed Sep 7 20:42:18 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 7 Sep 2005 16:42:18 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <431f4625.5bd0daa3.4f95.fffff4a0SMTPIN_ADDED@mx.gmail.com> References: <604aa79105090708433fde52b8@mail.gmail.com> <431f4625.5bd0daa3.4f95.fffff4a0SMTPIN_ADDED@mx.gmail.com> Message-ID: <604aa791050907134221f5165@mail.gmail.com> On 9/7/05, Christian.Iseli at licr.org wrote: > 1. I haven't seen a convincing argument why FE packages need to add fixed IDs I'll send over Uncle Nikko with his wide array of "convincing" arguments. Which would you prefer tire-iron,wrench, wooden baseball bat or perhaps crowbar. > > 2. If it is deemed so important to have fixed IDs, why doesn't Fedora Core > provide a mechanism to add them ? Even if I can be convinced at some point > that fixed IDs are really needed, I doubt the proper place for the > mechanism is in FE. Fine..eventually it should be in Core or not... but a particularly shallow packaging problem... that can be addressed by moving the solution into Core later. Remember Extras a path to inclusion in Core for "important" items. We aren't going to get anywhere at all if we collectively hold our breath, stick our head in the sand, and wait for someone inside redhat to deem this important or not-important and decide to add the optimal solution to Core. We get much further by building a flexible solution in Extras and adjust it based on growing experience using the solution. -jef From Christian.Iseli at licr.org Thu Sep 8 06:20:19 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 08 Sep 2005 08:20:19 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: Your message of "Wed, 07 Sep 2005 16:42:18 EDT." <604aa791050907134221f5165@mail.gmail.com> Message-ID: <200509080620.j886KUvD000646@mx1.redhat.com> jspaleta at gmail.com said: > I'll send over Uncle Nikko with his wide array of "convincing" arguments. > Which would you prefer tire-iron,wrench, wooden baseball bat or perhaps > crowbar. Ah, bring them all :-) I'm the official FE crack dealer now, remember ? So I'm ready for anything ;-) > Remember Extras a path to inclusion in Core for "important" items. > We aren't going to get anywhere at all if we collectively hold our breath, > stick our head in the sand, and wait for someone inside redhat to deem this > important or not-important and decide to add the optimal solution to Core. We > get much further by building a flexible solution in Extras and adjust it > based on growing experience using the solution. No doubt about that. But up to now, IMHO requesting fedora-usermgt in pre/post scriptlets is a solution in search of a real problem. Time for a vote ? We love to vote in Switzerland... :-) Cheers, Christian From jspaleta at gmail.com Thu Sep 8 14:16:07 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 8 Sep 2005 10:16:07 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <431fd824.2cf8b50c.7fa2.1dd4SMTPIN_ADDED@mx.gmail.com> References: <604aa791050907134221f5165@mail.gmail.com> <431fd824.2cf8b50c.7fa2.1dd4SMTPIN_ADDED@mx.gmail.com> Message-ID: <604aa791050908071642ccf732@mail.gmail.com> On 9/8/05, Christian.Iseli at licr.org wrote: > No doubt about that. But up to now, IMHO requesting fedora-usermgt in > pre/post scriptlets is a solution in search of a real problem. Hmm... well usually when i see many people offering replacement implementations to replace the existing tool implementation..i see this as disagreement on exactly what the problem is... not that there is a lack of a problem. You did offer a competing implementation in this thread. The one thing I know for sure.. is that everyone seems to be confused. Perhaps its best to dial back this conversation and ask Enrico to give a "brief" summary as to primary problem being addressed... with one or two common example situations. And if he can dig up an old fedora.us mailinglist thread for reference where the original design and of the wrapper implementation was discussed that might help everyone refresh their memories as to the original reasons this was created. We aren't going to get anywhere if we aren't all on the same page. -jef From veguilla at gmail.com Fri Sep 9 20:32:30 2005 From: veguilla at gmail.com (Ricardo Veguilla Gonzalez) Date: Fri, 09 Sep 2005 16:32:30 -0400 Subject: [Fedora-packaging] gnome-screensaver packaging problem Message-ID: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> Hi, I was going to submit gnome-screensaver to Fedora Extras, and while checking the spec file[1] for submission, I found the following problems: Problem #1 - Since gnome-screensaver is a gnome replacement for xscreensaver, I decided to add "Provide: xscreensaver" but then to the spec file. The problem is that upgrading xscreensaver will remove gnome-screensaver (xscreensaver obsoletes itself). Problem #2 - gnome-screensaver can use xscreensaver hacks if xscreensaver-extras or xscreensaver-gl-extras are installed, but they depend on xscreensaver-base, which introduces problem #1. I think the user should be able to install: gnome-screensaver xscreensaver xscreensaver-extras or gnome-screensaver xscreensaver-extras Any suggestions? [1] Related files available at: http://ece.uprm.edu/~veguilla/fedora/gnome-screensaver/ -- Ricardo Veguilla Gonzalez From jspaleta at gmail.com Fri Sep 9 20:46:37 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 9 Sep 2005 16:46:37 -0400 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> Message-ID: <604aa791050909134655f17c00@mail.gmail.com> On 9/9/05, Ricardo Veguilla Gonzalez wrote: > > Hi, I was going to submit gnome-screensaver to Fedora Extras, and while > checking the spec file[1] for submission, I found the following > problems: > > Problem #1 - Since gnome-screensaver is a gnome replacement for > xscreensaver, I decided to add "Provide: xscreensaver" but then to the > spec file. The problem is that upgrading xscreensaver will remove > gnome-screensaver (xscreensaver obsoletes itself). > > Problem #2 - gnome-screensaver can use xscreensaver hacks if > xscreensaver-extras or xscreensaver-gl-extras are installed, but they > depend on xscreensaver-base, which introduces problem #1. why do you need to provide "xscreensaver"? Can you not provide "xscreensaver-base" to solve the problem you want to solve? -jef From veguilla at gmail.com Fri Sep 9 21:17:57 2005 From: veguilla at gmail.com (Ricardo Veguilla =?ISO-8859-1?Q?Gonz=E1lez?=) Date: Fri, 09 Sep 2005 17:17:57 -0400 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: <604aa791050909134655f17c00@mail.gmail.com> References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> <604aa791050909134655f17c00@mail.gmail.com> Message-ID: <1126300677.15591.38.camel@netlab04.ece.uprm.edu> On Fri, 2005-09-09 at 16:46 -0400, Jeff Spaleta wrote: > On 9/9/05, Ricardo Veguilla Gonzalez wrote: > > > > Hi, I was going to submit gnome-screensaver to Fedora Extras, and while > > checking the spec file[1] for submission, I found the following > > problems: > > > > Problem #1 - Since gnome-screensaver is a gnome replacement for > > xscreensaver, I decided to add "Provide: xscreensaver" but then to the > > spec file. The problem is that upgrading xscreensaver will remove > > gnome-screensaver (xscreensaver obsoletes itself). > > > > Problem #2 - gnome-screensaver can use xscreensaver hacks if > > xscreensaver-extras or xscreensaver-gl-extras are installed, but they > > depend on xscreensaver-base, which introduces problem #1. > > why do you need to provide "xscreensaver"? Can you not provide > "xscreensaver-base" to solve the problem you want to solve? Because control-center requires xscreensaver. If I also provide xscreensaver-base, it will allow gnome-screensaver + xscreensaver-extras, but upgrading xscreensaver would still remove gnome-screensaver if both are installed. I could simply make gnome-screensaver provide and obsolete both "xscreensaver" and "xscreensaver-base", but I was trying to find a way to allow both of them installed at the same time. -- Ricardo Veguilla Gonz?lez From jspaleta at gmail.com Fri Sep 9 21:53:02 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 9 Sep 2005 17:53:02 -0400 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: <1126300677.15591.38.camel@netlab04.ece.uprm.edu> References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> <604aa791050909134655f17c00@mail.gmail.com> <1126300677.15591.38.camel@netlab04.ece.uprm.edu> Message-ID: <604aa791050909145327c4fce8@mail.gmail.com> On 9/9/05, Ricardo Veguilla Gonz?lez wrote: > Because control-center requires xscreensaver. perhaps control-center needs to be requiring xscreensaver-base instead now. I think control-center still requiring xscreensaver is an oversight. > If I also provide xscreensaver-base, Here's what I'm getting at... what you want to do cannot involve providing "xscreensaver" as long as xscreensaver-base is obsoleting "xscreensaver" I can't see a good reason for control-center to still be requiring xscreensaver over xscreensaver-base. If you want the parallel install of both to work you avoid providing "xscreensaver" and you provide "xscreensaver-base" instead. If you want people to be able to remove xscreensaver and use gnome-screensaver exclusively, I think you'll have to convince the control-center packager to require xscreensaver-base instead of xscreensaver... assume there are no actual file conflicts and the only problem really is the obsoleting action. how xscreensaver-base provides and obsoletes "xscreensaver" is there to provide some measure of backwards compatibility. Moving forward...nothing new should be built providing or requring "xscreensaver". What you are seeing is one of the side-effects of this approach. As soon as control-center catches up and starts requiring "xscreensaver-base" you can have both cases that you are looking for. -jef From aoliva at redhat.com Sat Sep 10 13:56:25 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 10 Sep 2005 10:56:25 -0300 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> Message-ID: On Sep 9, 2005, Ricardo Veguilla Gonzalez wrote: > Problem #1 - Since gnome-screensaver is a gnome replacement for > xscreensaver If it's a replacement for something in Core, it seems to me that it should not be in Extras, but rather in an Alternatives repository, no? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From steve at silug.org Sat Sep 10 15:10:39 2005 From: steve at silug.org (Steven Pritchard) Date: Sat, 10 Sep 2005 10:10:39 -0500 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> Message-ID: <20050910151039.GA13232@osiris.silug.org> On Sat, Sep 10, 2005 at 10:56:25AM -0300, Alexandre Oliva wrote: > If it's a replacement for something in Core, it seems to me that it > should not be in Extras, but rather in an Alternatives repository, no? Maybe if such a thing existed. Isn't this essentially the same problem as GNU Emacs vs. XEmacs? XEmacs is in Extras these days... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From ville.skytta at iki.fi Sat Sep 10 15:54:28 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 10 Sep 2005 18:54:28 +0300 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: <20050910151039.GA13232@osiris.silug.org> References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> <20050910151039.GA13232@osiris.silug.org> Message-ID: <1126367668.3260.121.camel@localhost.localdomain> On Sat, 2005-09-10 at 10:10 -0500, Steven Pritchard wrote: > On Sat, Sep 10, 2005 at 10:56:25AM -0300, Alexandre Oliva wrote: > > If it's a replacement for something in Core, it seems to me that it > > should not be in Extras, but rather in an Alternatives repository, no? > > Maybe if such a thing existed. > > Isn't this essentially the same problem as GNU Emacs vs. XEmacs? How so? GNU Emacs and XEmacs coexist just fine, neither is a replacement for the other. From jspaleta at gmail.com Sat Sep 10 16:42:45 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 10 Sep 2005 12:42:45 -0400 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> Message-ID: <604aa79105091009424ecd6308@mail.gmail.com> On 10 Sep 2005 10:56:25 -0300, Alexandre Oliva wrote: > On Sep 9, 2005, Ricardo Veguilla Gonzalez wrote: > > > Problem #1 - Since gnome-screensaver is a gnome replacement for > > xscreensaver > > If it's a replacement for something in Core, it seems to me that it > should not be in Extras, but rather in an Alternatives repository, no? Its not clear to me whether or not gnome-screensaver is actually mutually exclusive with xscreensaver. It might be more like mozilla/firefox like relationship. with the xscreensaver-extras are "plugins" that both can use. If there are no explict file conflicts users might very well be able to have both installed...or replace one with the other for similar functionality. Certaintly users will not be able to run both xscreensaver and gnome-screensaver at the same time..but I don't think that sort of thing is a blocker from extras. I haven't actually tried to mock up his specfile yet to see if there are file conflicts though. If the intent is to have installation of gnome-screensaver to always remove xscreensaver-base automatically..then no..thats not extras appropriate. -jef From tcallawa at redhat.com Sat Sep 10 19:41:45 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 10 Sep 2005 14:41:45 -0500 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> Message-ID: <1126381305.25031.21.camel@localhost.localdomain> On Sat, 2005-09-10 at 10:56 -0300, Alexandre Oliva wrote: > On Sep 9, 2005, Ricardo Veguilla Gonzalez wrote: > > > Problem #1 - Since gnome-screensaver is a gnome replacement for > > xscreensaver > > If it's a replacement for something in Core, it seems to me that it > should not be in Extras, but rather in an Alternatives repository, no? There is no such thing as Fedora Alternatives, nor do I really see a reason for it. Many of the items in Extras qualify as "Alternatives" to things in Core. Rather than segmenting these packages off into some sort of special repository (which doesn't solve the problems that gnome-screensaver faces), it would be easier to fix packages which hardcode on name (in this case control-center), and possibly use alternatives to manage it (similar to how sendmail/postfix are handled). IMHO, of course. :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From veguilla at gmail.com Sat Sep 10 21:20:09 2005 From: veguilla at gmail.com (Ricardo Veguilla =?ISO-8859-1?Q?Gonz=E1lez?=) Date: Sat, 10 Sep 2005 17:20:09 -0400 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: <604aa79105091009424ecd6308@mail.gmail.com> References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> <604aa79105091009424ecd6308@mail.gmail.com> Message-ID: <1126387209.28993.7.camel@netlab04.ece.uprm.edu> On Sat, 2005-09-10 at 12:42 -0400, Jeff Spaleta wrote: > Its not clear to me whether or not gnome-screensaver is actually > mutually exclusive with xscreensaver. It might be more like > mozilla/firefox like relationship. with the xscreensaver-extras are > "plugins" that both can use. > No, they aren't mutually exclusive. > If there are no explict file conflicts users might very well be able > to have both installed...or replace one with the other for similar > functionality. Certaintly users will not be able to run both > xscreensaver and gnome-screensaver at the same time..but I don't think > that sort of thing is a blocker from extras. I haven't actually tried > to mock up his specfile yet to see if there are file conflicts though. No file conflicts. > If the intent is to have installation of gnome-screensaver to always > remove xscreensaver-base automatically..then no..thats not extras > appropriate. That's not my intend, but until the xscreensaver requirement in the control-center rpm is changed, I don't see another way installing both at the same time. -- Ricardo Veguilla Gonz?lez From jspaleta at gmail.com Sat Sep 10 22:14:09 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 10 Sep 2005 18:14:09 -0400 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: <1126387209.28993.7.camel@netlab04.ece.uprm.edu> References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> <604aa79105091009424ecd6308@mail.gmail.com> <1126387209.28993.7.camel@netlab04.ece.uprm.edu> Message-ID: <604aa79105091015146a079e0e@mail.gmail.com> On 9/10/05, Ricardo Veguilla Gonz?lez wrote: > That's not my intend, but until the xscreensaver requirement in the > control-center rpm is changed, I don't see another way installing > both at the same time. I think you have it backwards... if they dont inherently conflict.. then you can easily have both installed at the same time. Just have gnome-screensaver provide "xscreensaver-base" forget about providing "xscreensaver" or obsoleting anything. But instead of trying to explain this.. I'd like to just edit your spec file and give you some binary packages that show exactly what im talking about by rebuilding this with mock. Unfortunately the spec file you have available right now isnt rebuilding cleanly in mock for fc4 nor for fedora core development. The build process is failing out in the configuration process.. can you look into that? -jef From veguilla at gmail.com Sat Sep 10 22:40:36 2005 From: veguilla at gmail.com (Ricardo Veguilla =?ISO-8859-1?Q?Gonz=E1lez?=) Date: Sat, 10 Sep 2005 18:40:36 -0400 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: <604aa79105091015146a079e0e@mail.gmail.com> References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> <604aa79105091009424ecd6308@mail.gmail.com> <1126387209.28993.7.camel@netlab04.ece.uprm.edu> <604aa79105091015146a079e0e@mail.gmail.com> Message-ID: <1126392036.32688.4.camel@netlab04.ece.uprm.edu> On Sat, 2005-09-10 at 18:14 -0400, Jeff Spaleta wrote: > On 9/10/05, Ricardo Veguilla Gonz?lez wrote: > > That's not my intend, but until the xscreensaver requirement in the > > control-center rpm is changed, I don't see another way installing > > both at the same time. > I think you have it backwards... if they dont inherently conflict.. > then you can easily have both installed at the same time. Just have > gnome-screensaver provide "xscreensaver-base" forget about providing > "xscreensaver" or obsoleting anything. > I see what you mean, and it will clearly work if both are installed at the same time, but if you only want gnome-screensaver, then it won't work because control-center requires xscreensaver (not xscreensaver-base). > But instead of trying to explain this.. I'd like to just edit your > spec file and give you some binary packages that show exactly what im > talking about by rebuilding this with mock. Unfortunately the spec > file you have available right now isnt rebuilding cleanly in mock for > fc4 nor for fedora core development. The build process is failing out > in the configuration process.. can you look into that? I'll check it out. -- Ricardo Veguilla Gonz?lez From rdieter at math.unl.edu Sun Sep 11 00:11:15 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 10 Sep 2005 19:11:15 -0500 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: <1126392036.32688.4.camel@netlab04.ece.uprm.edu> References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> <604aa79105091009424ecd6308@mail.gmail.com> <1126387209.28993.7.camel@netlab04.ece.uprm.edu> <604aa79105091015146a079e0e@mail.gmail.com> <1126392036.32688.4.camel@netlab04.ece.uprm.edu> Message-ID: <43237623.9010201@math.unl.edu> Ricardo Veguilla Gonz?lez wrote: > On Sat, 2005-09-10 at 18:14 -0400, Jeff Spaleta wrote: > >>On 9/10/05, Ricardo Veguilla Gonz?lez wrote: >> >>>That's not my intend, but until the xscreensaver requirement in the >>>control-center rpm is changed, I don't see another way installing >>>both at the same time. >> >>I think you have it backwards... if they dont inherently conflict.. >>then you can easily have both installed at the same time. Just have >>gnome-screensaver provide "xscreensaver-base" forget about providing >>"xscreensaver" or obsoleting anything. >> > > > I see what you mean, and it will clearly work if both are installed at > the same time, but if you only want gnome-screensaver, then it won't > work because control-center requires xscreensaver (not > xscreensaver-base). That's an issue to take up with control-center and it's packaging, which, IMO, you shouldn't try to fix or workaround here (in gnome-screensaver), especially since your Obsoletes/Provides hackery could very well break kdeartwork's use/Require's of xscreensaver. -- Rex From veguilla at gmail.com Sun Sep 11 00:13:33 2005 From: veguilla at gmail.com (Ricardo Veguilla =?ISO-8859-1?Q?Gonz=E1lez?=) Date: Sat, 10 Sep 2005 20:13:33 -0400 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: <604aa79105091015146a079e0e@mail.gmail.com> References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> <604aa79105091009424ecd6308@mail.gmail.com> <1126387209.28993.7.camel@netlab04.ece.uprm.edu> <604aa79105091015146a079e0e@mail.gmail.com> Message-ID: <1126397613.32688.14.camel@netlab04.ece.uprm.edu> On Sat, 2005-09-10 at 18:14 -0400, Jeff Spaleta wrote: > Unfortunately the spec > file you have available right now isnt rebuilding cleanly in mock for > fc4 nor for fedora core development. The build process is failing out > in the configuration process.. can you look into that? > Ok, first of all, I forgot to set the gtk2-devel requirement to 2.7.0 or newer, which means that gnome-screensaver won't build in FC4. The pam-devel requirement was also missing. The configure error was cause the libgnome-devel rpm missing the gnome-keyring-devel requirement. I explicitly added the gnome-keyring-devel requirement to gnome-screensaver as a workaround. Please try again. http://ece.uprm.edu/~veguilla/fedora/gnome-screensaver/gnome-screensaver.spec http://ece.uprm.edu/~veguilla/fedora/gnome-screensaver/gnome-screensaver-0.0.12-2.src.rpm -- Ricardo Veguilla Gonz?lez From jspaleta at gmail.com Sun Sep 11 00:56:40 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 10 Sep 2005 20:56:40 -0400 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: <1126397613.32688.14.camel@netlab04.ece.uprm.edu> References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> <604aa79105091009424ecd6308@mail.gmail.com> <1126387209.28993.7.camel@netlab04.ece.uprm.edu> <604aa79105091015146a079e0e@mail.gmail.com> <1126397613.32688.14.camel@netlab04.ece.uprm.edu> Message-ID: <604aa7910509101756446b8ba7@mail.gmail.com> On 9/10/05, Ricardo Veguilla Gonz?lez wrote: >http://ece.uprm.edu/~veguilla/fedora/gnome-screensaver/gnome-screensaver.spec Okay... i made the small change in the Specfile and I got a binary that installs in parallel with xscreensaver. I also made an example rebuild of control-center with the requires change. If you use update to that control-center binary.. you can then remove xscreensaver-base if gnome-screensaver is installed. Thats basically how you solve the problems in the original post to this thread. We'd actually be better off if we could drop that screensaver "packagename" requirement in control-center completely.. since its sort of abusing "requirement" in the strict sense...but thats a long debate to be had with the Core desktop developers and its not going to be solved in this thread. rawhide synced rpms and srpms are located at: jef.is-a-geek.com/downloads/gnome-screensaver/ I'll note however gnome-screensaver doesn't appear to actually work as advertised on my initial attempt to use it and isnt seeing xscreensaver-extras. And you are going to have to do something to make it obvious which entry in the prefs menu is gnome-screensaver instead of xscreensaver. But I'll leave further exploration of these topics for the bugzilla review process. -jef From nicolas.mailhot at laposte.net Mon Sep 12 09:32:41 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 Sep 2005 11:32:41 +0200 (CEST) Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1126087598.22372.199.camel@mccallum.corsepiu.local> References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> <20050707005259.GA14794@jadzia.bu.edu> <1120702663.2744.40.camel@locolhost.localdomain> <20050707030213.GA19518@jadzia.bu.edu> <20050707035300.GA21070@jadzia.bu.edu> <1126042766.17919.11.camel@localhost.localdomain> <20050906215221.GA4412@osiris.silug.org> <87hdcxhlsr.fsf@kosh.bigo.ensc.de> <1126071178.22372.146.camel@mccallum.corsepiu.local> <87ek81kzs2.fsf@kosh.bigo.ensc.de> <1126087598.22372.199.camel@mccallum.corsepiu.local> Message-ID: <27977.192.54.193.25.1126517561.squirrel@rousalka.dyndns.org> On Mer 7 septembre 2005 12:06, Ralf Corsepius wrote: >> * 'vdr' and 'vdradmin' (from livna) are running on different hosts as >> the 'vdr:video' user. Both share configuration files and data which is >> exported by NFS > Then these UID/GIDs probably better should be ordinary uids, instead of > system-user ids. Except "ordinary IDs" can and will be put into LDAP/kerberos/whatever. Come on folks, the sad truth is - user and system ID ranges need to be kept separate in any medium-to-big network. Any mixed system is an admin nightmare, and they're not kept in the same ID databases - system IDs must be fixed (fixed as in same in all the nodes of a local network) for lots of people (maybe not you but don't make life miserable for others just because you don't need something) - the current "official" fixed system ID range is much too small So you need a fedora.us-style solution to create a bigger local fixed system ID range. If the original system ID range were ~500 entries instead of 100 we wouldn't be writing about it today (later though...) And the problem is more accute for FE than FC because FE ships a lot more stuff with system IDs *and* the current fixed system ID range is almost fully used by FC packages. That being said, I've no special love for the fedora.us way, but the problem needs to be solved somehow and claiming there is not problem when lots of people say there is won't help solving it faster. Regards, -- Nicolas Mailhot From jamatos at fc.up.pt Mon Sep 12 11:41:49 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Mon, 12 Sep 2005 12:41:49 +0100 Subject: [Fedora-packaging] Name of x11 applet packages (common preffix?) Message-ID: <200509121241.49339.jamatos@fc.up.pt> Hi all, I have reviewed before wmacpi, a small x11 applet that shows the status of the laptop battery. There are several other packages waiting for review in Extras that are also small applications to report other kind of information, disk activity, weather reports,... A list of possible packages that follow in to this class can be found here: http://dockapps.org/ Since those are small applications I propose to place them under a common prefix, something like any of the following alternatives: - x11-applets-... - x11-dockapps-... - x11-pluggins-... My question to the list is if this is appropriate or am I trying to be more papist than the Pope? Probably what I am trying to do unifying the package in a single namespace is better done in metadata... Is this senseless and we should try to abide to the upstream name? Best regards, -- Jos? Ab?lio From tcallawa at redhat.com Mon Sep 12 14:01:20 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 12 Sep 2005 09:01:20 -0500 Subject: [Fedora-packaging] Name of x11 applet packages (common preffix?) In-Reply-To: <200509121241.49339.jamatos@fc.up.pt> References: <200509121241.49339.jamatos@fc.up.pt> Message-ID: <1126533680.25031.59.camel@localhost.localdomain> On Mon, 2005-09-12 at 12:41 +0100, Jose' Matos wrote: > My question to the list is if this is appropriate or am I trying to be more > papist than the Pope? Probably what I am trying to do unifying the package in > a single namespace is better done in metadata... I really don't think this is common enough to merit its own namespace, however, final naming decisions fall on the maintainer. If you've got 20 of these that you're planning on packaging, then perhaps it makes sense for you to name it "x11-applet-*", but I won't force you down that road. > Is this senseless and we should try to abide to the upstream name? Probably a good idea. :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jamatos at fc.up.pt Mon Sep 12 14:33:34 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Mon, 12 Sep 2005 15:33:34 +0100 Subject: [Fedora-packaging] Name of x11 applet packages (common preffix?) In-Reply-To: <1126533680.25031.59.camel@localhost.localdomain> References: <200509121241.49339.jamatos@fc.up.pt> <1126533680.25031.59.camel@localhost.localdomain> Message-ID: <200509121533.35015.jamatos@fc.up.pt> On Monday 12 September 2005 15:01, Tom 'spot' Callaway wrote: > > ??????Is this senseless and we should try to abide to the upstream name? > > Probably a good idea. :) I can live with that. ;-) > ~spot -- Jos? Ab?lio From bugs.michael at gmx.net Thu Sep 15 10:28:01 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Sep 2005 12:28:01 +0200 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: <604aa7910509101756446b8ba7@mail.gmail.com> References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> <604aa79105091009424ecd6308@mail.gmail.com> <1126387209.28993.7.camel@netlab04.ece.uprm.edu> <604aa79105091015146a079e0e@mail.gmail.com> <1126397613.32688.14.camel@netlab04.ece.uprm.edu> <604aa7910509101756446b8ba7@mail.gmail.com> Message-ID: <20050915122801.32ace369.bugs.michael@gmx.net> On Sat, 10 Sep 2005 20:56:40 -0400, Jeff Spaleta wrote: > On 9/10/05, Ricardo Veguilla Gonz?lez wrote: > >http://ece.uprm.edu/~veguilla/fedora/gnome-screensaver/gnome-screensaver.spec > > Okay... i made the small change in the Specfile and I got a binary > that installs in parallel with xscreensaver. I also made an example > rebuild of control-center with the requires change. > If you use update to that control-center binary.. you can then remove > xscreensaver-base if gnome-screensaver is installed. Thats basically > how you solve the problems in the original post to this thread. We'd > actually be better off if we could drop that screensaver "packagename" > requirement in control-center completely.. since its sort of abusing > "requirement" in the strict sense...but thats a long debate to be had > with the Core desktop developers and its not going to be solved in > this thread. > > rawhide synced rpms and srpms are located at: > jef.is-a-geek.com/downloads/gnome-screensaver/ The whole discussion is pointless as long as there are virtual provides in the Extras package which interfere with Core package names. This is a show-stopper. Upgrading xscreensaver-base currently removes gnome-screensaver, simply because gnome-screensaver "Provides: xscreensaver-base". -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.13-1.1549_FC5 loadavg: 1.90 1.51 1.33 From jspaleta at gmail.com Thu Sep 15 13:06:12 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 15 Sep 2005 09:06:12 -0400 Subject: [Fedora-packaging] gnome-screensaver packaging problem In-Reply-To: <20050915122801.32ace369.bugs.michael@gmx.net> References: <1126297950.15591.21.camel@netlab04.ece.uprm.edu> <604aa79105091009424ecd6308@mail.gmail.com> <1126387209.28993.7.camel@netlab04.ece.uprm.edu> <604aa79105091015146a079e0e@mail.gmail.com> <1126397613.32688.14.camel@netlab04.ece.uprm.edu> <604aa7910509101756446b8ba7@mail.gmail.com> <20050915122801.32ace369.bugs.michael@gmx.net> Message-ID: <604aa79105091506062b6a24ea@mail.gmail.com> On 9/15/05, Michael Schwendt wrote: > The whole discussion is pointless as long as there are virtual provides > in the Extras package which interfere with Core package names. This is a > show-stopper. Upgrading xscreensaver-base currently removes > gnome-screensaver, simply because gnome-screensaver "Provides: > xscreensaver-base". damn it, you're right. So basically there needs to be a seperate virtual provides that is not keyed to a packagename that both xscreensavers-base and gnome-screensaver can provide that xscreensavers-extras can require. Like the "webclient" provides shared by several core packages. -jef From christoph.wickert at gmx.de Fri Sep 16 12:24:09 2005 From: christoph.wickert at gmx.de (Christoph Wickert) Date: Fri, 16 Sep 2005 14:24:09 +0200 Subject: [Fedora-packaging] Name of Gnome applet packages (was: RE: Name of x11 applet packages (common preffix?)) In-Reply-To: <1126533680.25031.59.camel@localhost.localdomain> References: <200509121241.49339.jamatos@fc.up.pt> <1126533680.25031.59.camel@localhost.localdomain> Message-ID: <1126873449.3835.38.camel@hal9000.local.lan> Am Montag, den 12.09.2005, 09:01 -0500 schrieb Tom 'spot' Callaway: > On Mon, 2005-09-12 at 12:41 +0100, Jose' Matos wrote: > > > My question to the list is if this is appropriate or am I trying to be more > > papist than the Pope? Probably what I am trying to do unifying the package in > > a single namespace is better done in metadata... > > I really don't think this is common enough to merit its own namespace, > however, final naming decisions fall on the maintainer. If you've got 20 > of these that you're planning on packaging, then perhaps it makes sense > for you to name it "x11-applet-*", but I won't force you down that road. > > > Is this senseless and we should try to abide to the upstream name? > > Probably a good idea. :) Is there any _official_ statement on this topic now? I have a similar question about the name of gnome-applets, in my case (#168032) it's gnome-timer-applet vs. gnome-applet timer. The upstream package ist called timer-applet, I think we need at least gnome as prefix. But I'm still unsure, whether to name the package applet-foo or foo-applet :/ On the hand there are: * gnome-applets * gnome-applet-netspeed * gnome-applet-rhythmbox * gnome-applet-sensors and on the other: * contact-lookup-applet * deskbar-applet * lock-keys-applet * glunarclock (no prefix at all) Any ideas and comments? > ~spot Christoph From tcallawa at redhat.com Fri Sep 16 14:20:39 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 16 Sep 2005 09:20:39 -0500 Subject: [Fedora-packaging] Name of Gnome applet packages (was: RE: Name of x11 applet packages (common preffix?)) In-Reply-To: <1126873449.3835.38.camel@hal9000.local.lan> References: <200509121241.49339.jamatos@fc.up.pt> <1126533680.25031.59.camel@localhost.localdomain> <1126873449.3835.38.camel@hal9000.local.lan> Message-ID: <1126880439.6762.83.camel@localhost.localdomain> On Fri, 2005-09-16 at 14:24 +0200, Christoph Wickert wrote: > Is there any _official_ statement on this topic now? > I have a similar question about the name of gnome-applets, in my case > (#168032) it's gnome-timer-applet vs. gnome-applet timer. The upstream > package ist called timer-applet, I think we need at least gnome as > prefix. But I'm still unsure, whether to name the package applet-foo or > foo-applet :/ Ultimately, this is your decision. If you're asking for my opinion, I'd say: gnome-applet-foo (due to the fact that there are no gnome-foo-applet packages). ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From christoph.wickert at gmx.de Fri Sep 16 16:19:58 2005 From: christoph.wickert at gmx.de (Christoph Wickert) Date: Fri, 16 Sep 2005 18:19:58 +0200 Subject: [Fedora-packaging] Name of Gnome applet packages (was: RE: Name of x11 applet packages (common preffix?)) In-Reply-To: <1126880439.6762.83.camel@localhost.localdomain> References: <200509121241.49339.jamatos@fc.up.pt> <1126533680.25031.59.camel@localhost.localdomain> <1126873449.3835.38.camel@hal9000.local.lan> <1126880439.6762.83.camel@localhost.localdomain> Message-ID: <1126887598.4041.2.camel@hal9000.local.lan> Am Freitag, den 16.09.2005, 09:20 -0500 schrieb Tom 'spot' Callaway: > On Fri, 2005-09-16 at 14:24 +0200, Christoph Wickert wrote: > > > Is there any _official_ statement on this topic now? > > I have a similar question about the name of gnome-applets, in my case > > (#168032) it's gnome-timer-applet vs. gnome-applet timer. The upstream > > package ist called timer-applet, I think we need at least gnome as > > prefix. But I'm still unsure, whether to name the package applet-foo or > > foo-applet :/ > > Ultimately, this is your decision. If you're asking for my opinion, I'd > say: > > gnome-applet-foo > Thanks, that's my choice, too. Christoph From symbiont at berlios.de Sat Sep 17 07:07:24 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sat, 17 Sep 2005 15:07:24 +0800 Subject: [Fedora-packaging] Python Packaging Hints Message-ID: <200509171507.24916.symbiont@berlios.de> Hi: Just some hints for packaging Python (iow, makes my life easier at http://python.org/pyvault). 1. Use %{__python} as opposed to python in any scriptlets. Especially be wary of the %pyver definitions using a call to python to grab the version. 2. Also, I need opinions on #!/usr/bin/python vs. #!/usr/bin/pythonX.Y. Because if a package installs into /usr/lib/pythonX.Y/site-packages, then any old /usr/bin/python won't work, it'd have to be the version specific /usr/bin/pythonX.Y. This might be a problem specific to my stuff, so you can ignore it if it is. http://groups.google.com/group/linux.debian.maint.python/browse_thread/thread/8d68b4c5434daa6a/703315fed09e0c18%23703315fed09e0c18?sa=X&oi=groupsr&start=0&num=3 thoughts? -- -jeff From alan at balclutha.org Sat Sep 17 16:27:28 2005 From: alan at balclutha.org (Alan Milligan) Date: Sun, 18 Sep 2005 02:27:28 +1000 Subject: [Fedora-packaging] Python Packaging Hints In-Reply-To: <20050917160033.528DE73589@hormel.redhat.com> References: <20050917160033.528DE73589@hormel.redhat.com> Message-ID: <432C43F0.5090409@balclutha.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Hi: > > Just some hints for packaging Python (iow, makes my life easier at > http://python.org/pyvault). > thoughts? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120635 represents a number of thoughts by critically interested parties about this issue. This request has been open for almost eighteen months now :( Some of the respondents seem to think that only one or two macros are necessary, I still beg to differ. We need to do this once, and do it to please the widest possible audience. A case in point is that we presently cannot migrate to Python2.4 until Zope Corporation sign off a security audit on their app server. If people didn't hard-code 2.4 into the build scripts, and if they use the include macros for C-based python code, then we could almost certainly backport any FC4 python SRPM's to our FC3 target without *any* modification required. This is simply not the case. We've already had to manage upgrades for 2.1, 2.2, and 2.3. A lot of things associated with Fedora development are still retentive and frustrating. Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDLEPvCfroLk4EZpkRAvBHAKDaP2NtfzIMns+OTc5OEJrA9tXhRgCbBgQh ZEM8QWaIM1bKoing17S37g4= =xbsS -----END PGP SIGNATURE----- From toshio at tiki-lounge.com Sat Sep 17 17:14:39 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 17 Sep 2005 10:14:39 -0700 Subject: [Fedora-packaging] Python Packaging Hints In-Reply-To: <432C43F0.5090409@balclutha.org> References: <20050917160033.528DE73589@hormel.redhat.com> <432C43F0.5090409@balclutha.org> Message-ID: <1126977280.26991.24.camel@localhost> On Sun, 2005-09-18 at 02:27 +1000, Alan Milligan wrote: > A case in point is that we presently cannot migrate to Python2.4 until > Zope Corporation sign off a security audit on their app server. If > people didn't hard-code 2.4 into the build scripts, and if they use the > include macros for C-based python code, then we could almost certainly > backport any FC4 python SRPM's to our FC3 target without *any* > modification required. Could you attach an FC4 spec that doesn't backport to FC3 without modification so we can see the mentioned issue? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Sat Sep 17 15:56:55 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 17 Sep 2005 08:56:55 -0700 Subject: [Fedora-packaging] Python Packaging Hints In-Reply-To: <200509171507.24916.symbiont@berlios.de> References: <200509171507.24916.symbiont@berlios.de> Message-ID: <1126972616.26991.20.camel@localhost> On Sat, 2005-09-17 at 15:07 +0800, Jeff Pitman wrote: > Hi: > > Just some hints for packaging Python (iow, makes my life easier at > http://python.org/pyvault). > > 1. Use %{__python} as opposed to python in any scriptlets. Especially be > wary of the %pyver definitions using a call to python to grab the > version. What's the justification for the %pyver wariness? > 2. Also, I need opinions on #!/usr/bin/python vs. > #!/usr/bin/pythonX.Y. Because if a package installs > into /usr/lib/pythonX.Y/site-packages, then any old /usr/bin/python > won't work, it'd have to be the version specific /usr/bin/pythonX.Y. > This might be a problem specific to my stuff, so you can ignore it if > it is. > http://groups.google.com/group/linux.debian.maint.python/browse_thread/thread/8d68b4c5434daa6a/703315fed09e0c18%23703315fed09e0c18?sa=X&oi=groupsr&start=0&num=3 > #!/usr/bin/pythonX.Y needs more package maintainer work than #!/usr/bin/python In Fedora Extras, we use a mock chroot build environment to build a different package for each Fedora Core release so we use a %pyver construct in order to find out which python version is appropriate for the Fedora Core version being built for. Look, for instance, at the qa-assistant spec file for how this is done. This allows us to leave the spec file basically unchanged between the different FC releases even though the python version has bumped numbers and locations. Note that FC4 (I believe) introduced an automatic, rpm-added "python(abi) = X.Y" for python packages. So for FC4 and later the versioning in the rpm Requires: is taken care of for you. In your % files section you'd then use: %files %{_libdir}/python?.?/site-packages/[MODULEDIR] to get the proper files with different python versions. If you're using a chroot in pyvault this method may work for you as well. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at balclutha.org Mon Sep 19 00:17:28 2005 From: alan at balclutha.org (Alan Milligan) Date: Mon, 19 Sep 2005 10:17:28 +1000 Subject: [Fedora-packaging] Python Packaging Hints In-Reply-To: <20050918160022.C98287381B@hormel.redhat.com> References: <20050918160022.C98287381B@hormel.redhat.com> Message-ID: <432E0398.6050406@balclutha.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Toshio Kuratomi wrote: > Could you attach an FC4 spec that doesn't backport to FC3 without > modification so we can see the mentioned issue? Take rhpl.spec for example. In order to build this across python versions, we need: make PYTHON=python%{pythonversion} PYTHONINCLUDE=%{pythoninclude} LIBDIR=/lib Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDLgOYCfroLk4EZpkRAhLRAJ9LRGaRX3jHNuUrgi2FxHxleCXpXACeLnAU 8eEnYlaSIuTiAyPLgw1PTLE= =mV4W -----END PGP SIGNATURE----- From toshio at tiki-lounge.com Mon Sep 19 09:38:00 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 19 Sep 2005 02:38:00 -0700 Subject: [Fedora-packaging] Python Packaging Hints In-Reply-To: <432E0398.6050406@balclutha.org> References: <20050918160022.C98287381B@hormel.redhat.com> <432E0398.6050406@balclutha.org> Message-ID: <1127122681.30924.36.camel@localhost> On Mon, 2005-09-19 at 10:17 +1000, Alan Milligan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Toshio Kuratomi wrote: > > > Could you attach an FC4 spec that doesn't backport to FC3 without > > modification so we can see the mentioned issue? > > Take rhpl.spec for example. In order to build this across python > versions, we need: Hmmm... Yes; rhpl's Makefiles seem to make some rather problematic assumptions. What other packages do you know have similarly fragile upstream build scripts? > make PYTHON=python%{pythonversion} PYTHONINCLUDE=%{pythoninclude} > LIBDIR=/lib Why the LIBDIR? That would seems to break things for x86_64 with no apparent gain. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at balclutha.org Mon Sep 19 16:31:58 2005 From: alan at balclutha.org (Alan Milligan) Date: Tue, 20 Sep 2005 02:31:58 +1000 Subject: [Fedora-packaging] Python Packaging Hints In-Reply-To: <20050919160038.8B91873792@hormel.redhat.com> References: <20050919160038.8B91873792@hormel.redhat.com> Message-ID: <432EE7FE.6010505@balclutha.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Toshio Kuratomi wrote: >Hmmm... Yes; rhpl's Makefiles seem to make some rather problematic >assumptions. What other packages do you know have similarly fragile >upstream build scripts? Since we're not accepting python-2.4, I've not downloaded very much of the FC4 stack to discover exactly what's still broken. In this case, I think I was curious to see if https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135657 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135657 had been released as we need a proper extended url basic http authentication syntax to allow up2date to connect to our servers. Again, these patches were submitted almost a year ago, and we still have to maintain our own forks :( >>make PYTHON=python%{pythonversion} PYTHONINCLUDE=%{pythoninclude} >>LIBDIR=/lib >Why the LIBDIR? That would seems to break things for x86_64 with no >apparent gain. Dunno - there was obviously something screwed with the link-edit step. I'm a little surpised that /lib is not on the default link-library path in the first place ... Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDLuf+CfroLk4EZpkRAluiAKDQPrvl1+dzlC/4cVU+j4XF9/WNdACfVRdC zJ6eqgT+rBOTm+ZFXh2w4k0= =IfYK -----END PGP SIGNATURE----- From tcallawa at redhat.com Mon Sep 19 16:39:55 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 19 Sep 2005 11:39:55 -0500 Subject: [Fedora-packaging] Python Packaging Hints In-Reply-To: <432EE7FE.6010505@balclutha.org> References: <20050919160038.8B91873792@hormel.redhat.com> <432EE7FE.6010505@balclutha.org> Message-ID: <1127147995.2639.56.camel@localhost.localdomain> On Tue, 2005-09-20 at 02:31 +1000, Alan Milligan wrote: > Since we're not accepting python-2.4, I've not downloaded very much of > the FC4 stack to discover exactly what's still broken. In this case, I > think I was curious to see if > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135657 and > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135657 had been > released as we need a proper extended url basic http authentication > syntax to allow up2date to connect to our servers. 135657 has been resolved since April... ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From toshio at tiki-lounge.com Mon Sep 19 17:43:56 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 19 Sep 2005 10:43:56 -0700 Subject: [Fedora-packaging] Python Packaging Hints In-Reply-To: <432EE7FE.6010505@balclutha.org> References: <20050919160038.8B91873792@hormel.redhat.com> <432EE7FE.6010505@balclutha.org> Message-ID: <1127151837.30924.59.camel@localhost> On Tue, 2005-09-20 at 02:31 +1000, Alan Milligan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Toshio Kuratomi wrote: > > >Hmmm... Yes; rhpl's Makefiles seem to make some rather problematic > >assumptions. What other packages do you know have similarly fragile > >upstream build scripts? > You can build rhpl on different FC's with just the pythonversion: %define pyver %(%{__python} -c 'import sys; from string import split, join; print join(split(split(sys.version)[0], ".")[:2], ".")') %prep %setup -q make PYTHON=python%{pyver} [...] make install DESTDIR=$RPM_BUILD_ROOT PYTHON=python%{pyver} This isn't the "right" solution, though. I think this should be fixed in the rhpl Makefile instead. Jeremy, it looks like you're in charge of the build scripts for rhpl: if I file a bug and work on a patch, what would you like it to do? 1) Patch the spec file like above 2) Do something similar in Makefile.inc to detect the correct pythonversion to use 3) Use autoconf > Since we're not accepting python-2.4, I've not downloaded very much of > the FC4 stack to discover exactly what's still broken. In this case, I > think I was curious to see if > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135657 and > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135657 had been > released as we need a proper extended url basic http authentication > syntax to allow up2date to connect to our servers. Again, these patches > were submitted almost a year ago, and we still have to maintain our own > forks :( > > >>make PYTHON=python%{pythonversion} PYTHONINCLUDE=%{pythoninclude} > >>LIBDIR=/lib > > >Why the LIBDIR? That would seems to break things for x86_64 with no > >apparent gain. > > Dunno - there was obviously something screwed with the link-edit step. > I'm a little surpised that /lib is not on the default link-library path > in the first place ... > LIBDIR isn't used for linking in this case, only as a location to install the python files to:: Makefile.inc:PYDIR=${PYTHONLIBDIR}/rhpl Makefile.inc:PYTHONLIBDIR = /usr/$(LIBDIR)/$(PYTHON)/site-packages -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Mon Sep 19 17:50:01 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 19 Sep 2005 10:50:01 -0700 Subject: [Fedora-packaging] Python Packaging Hints In-Reply-To: <1127147995.2639.56.camel@localhost.localdomain> References: <20050919160038.8B91873792@hormel.redhat.com> <432EE7FE.6010505@balclutha.org> <1127147995.2639.56.camel@localhost.localdomain> Message-ID: <1127152202.30924.63.camel@localhost> On Mon, 2005-09-19 at 11:39 -0500, Tom 'spot' Callaway wrote: > On Tue, 2005-09-20 at 02:31 +1000, Alan Milligan wrote: > > > Since we're not accepting python-2.4, I've not downloaded very much of > > the FC4 stack to discover exactly what's still broken. In this case, I > > think I was curious to see if > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135657 and > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135657 had been > > released as we need a proper extended url basic http authentication > > syntax to allow up2date to connect to our servers. > > 135657 has been resolved since April... From the context, I'm guessing Alan is watching three bugs to get things working. 13567 and: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135660 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135659 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Tue Sep 27 16:10:19 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 27 Sep 2005 18:10:19 +0200 Subject: [Fedora-packaging] Installing man pages Message-ID: <1127837419.25763.40.camel@mccallum.corsepiu.local> Hi, A question: Are packages legitimated to install man pages into arbitrary /usr/share/man/man* directories outside those provided by the "filesystem" package? Background: - the man-pages rpm installs its man-pages into /usr/share/man/man0p /usr/share/man/man1p /usr/share/man/man3p - the blas and lapack rpms install into /usr/share/man/manl Additionally, all these packages leave their man page installation directories unowned: # rpm -qf /usr/share/man/man?p /usr/share/man/manl file /usr/share/man/man0p is not owned by any package file /usr/share/man/man1p is not owned by any package file /usr/share/man/man3p is not owned by any package file /usr/share/man/manl is not owned by any package I checked the FHS, but it once again seems intentionally vague to me wrt. this topic, so I think we need a convention, here. Ralf From tcallawa at redhat.com Tue Sep 27 17:09:00 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 27 Sep 2005 12:09:00 -0500 Subject: [Fedora-packaging] Installing man pages In-Reply-To: <1127837419.25763.40.camel@mccallum.corsepiu.local> References: <1127837419.25763.40.camel@mccallum.corsepiu.local> Message-ID: <1127840940.17700.3.camel@localhost.localdomain> On Tue, 2005-09-27 at 18:10 +0200, Ralf Corsepius wrote: > Hi, > > A question: > > Are packages legitimated to install man pages into > arbitrary /usr/share/man/man* directories outside those provided by the > "filesystem" package? Short answer: Yes, but only in specific cases. > I checked the FHS, but it once again seems intentionally vague to me > wrt. this topic, so I think we need a convention, here. OK... so the FHS says: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREMANMANUALPAGES "Manual pages are stored in //man
/." Where = /usr/share/man "Systems which use a unique language and code set for all manual pages may omit the substring and store all manual pages in . For example, systems which only have English manual pages coded with ASCII, may store manual pages (the man
directories) directly in /usr/share/man. (That is the traditional circumstance and arrangement, in fact.)" "Similarly, provision must be made for manual pages which are architecture-dependent, such as documentation on device-drivers or low-level system administration commands. These must be placed under an directory in the appropriate man
directory; for example, a man page for the i386 ctrlaltdel(8) command might be placed in /usr/share/man//man8/i386/ctrlaltdel.8." Or, to put it in plain english: If you have man pages that are only in EN (the most common case), then you need to put them in %{_mandir}/man
, where the section matches the section in the man pages. This is what lapack/blas does. If you have man pages that are provided in multiple locales, then they need to be put in %{_mandir}//man
, where the locale and section matches the section in the man pages. Man does this for some of its translated man pages. If you have man pages that are architecture-dependent (aka, only true for a specific architecture), then they should be placed in %{_mandir}//man
/. I'm not aware of anything doing this, but this is not surprising, since this is a very obscure case. FE Packages should not own any directories under %{_mandir}. I'm also aware that many directories under /usr/share/man are not owned. This should be filed as a bug against the "man" package, IMHO, but this seems to be a point of much contention inside Red Hat. Again, I can't control FC packaging policy (unfortunately), just FE. If nothing else, we'll set a good example for Red Hat. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From rc040203 at freenet.de Wed Sep 28 02:00:15 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 28 Sep 2005 04:00:15 +0200 Subject: [Fedora-packaging] Installing man pages In-Reply-To: <1127840940.17700.3.camel@localhost.localdomain> References: <1127837419.25763.40.camel@mccallum.corsepiu.local> <1127840940.17700.3.camel@localhost.localdomain> Message-ID: <1127872815.25763.68.camel@mccallum.corsepiu.local> On Tue, 2005-09-27 at 12:09 -0500, Tom 'spot' Callaway wrote: > On Tue, 2005-09-27 at 18:10 +0200, Ralf Corsepius wrote: > > Hi, > > > > A question: > > > > Are packages legitimated to install man pages into > > arbitrary /usr/share/man/man* directories outside those provided by the > > "filesystem" package? > > Short answer: Yes, but only in specific cases. > > > I checked the FHS, but it once again seems intentionally vague to me > > wrt. this topic, so I think we need a convention, here. > > OK... so the FHS says: > > http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREMANMANUALPAGES > > "Manual pages are stored in //man
/." > > Where = /usr/share/man > > "Systems which use a unique language and code set for all manual pages > may omit the substring and store all manual pages in . > For example, systems which only have English manual pages coded with > ASCII, may store manual pages (the man
directories) directly > in /usr/share/man. (That is the traditional circumstance and > arrangement, in fact.)" > > "Similarly, provision must be made for manual pages which are > architecture-dependent, such as documentation on device-drivers or > low-level system administration commands. These must be placed under an > directory in the appropriate man
directory; for example, > a man page for the i386 ctrlaltdel(8) command might be placed > in /usr/share/man//man8/i386/ctrlaltdel.8." > > Or, to put it in plain english: > > If you have man pages that are only in EN (the most common case), then > you need to put them in %{_mandir}/man
, where the section > matches the section in the man pages. This is what lapack/blas does. > > If you have man pages that are provided in multiple locales, then they > need to be put in %{_mandir}//man
, where the locale and > section matches the section in the man pages. Man does this for some of > its translated man pages. > > If you have man pages that are architecture-dependent (aka, only true > for a specific architecture), then they should be placed in > %{_mandir}//man
/. I'm not aware of anything doing > this, but this is not surprising, since this is a very obscure case. > > FE Packages should not own any directories under %{_mandir}. That's the crucial point. IMO, packages must own directories if they install their manpages outside of those directories provided by "filesystem". > I'm also > aware that many directories under /usr/share/man are not owned. This > should be filed as a bug against the "man" package, IMHO, but this seems > to be a point of much contention inside Red Hat. > > Again, I can't control FC packaging policy (unfortunately), just FE. If > nothing else, we'll set a good example for Red Hat. blas and lapack are FE packages. Ralf From mpeters at mac.com Wed Sep 28 03:41:28 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 27 Sep 2005 20:41:28 -0700 Subject: [Fedora-packaging] Installing man pages In-Reply-To: <1127840940.17700.3.camel@localhost.localdomain> References: <1127837419.25763.40.camel@mccallum.corsepiu.local> <1127840940.17700.3.camel@localhost.localdomain> Message-ID: <1127878889.2743.7.camel@locolhost.localdomain> On Tue, 2005-09-27 at 12:09 -0500, Tom 'spot' Callaway wrote: > I'm not aware of anything doing > this, but this is not surprising, since this is a very obscure case. and I think would be better handled better %ifarch ... From mpeters at mac.com Wed Sep 28 04:03:11 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 27 Sep 2005 21:03:11 -0700 Subject: [Fedora-packaging] Installing man pages In-Reply-To: <1127878889.2743.7.camel@locolhost.localdomain> References: <1127837419.25763.40.camel@mccallum.corsepiu.local> <1127840940.17700.3.camel@localhost.localdomain> <1127878889.2743.7.camel@locolhost.localdomain> Message-ID: <1127880191.2743.9.camel@locolhost.localdomain> On Tue, 2005-09-27 at 20:41 -0700, Michael A. Peters wrote: > On Tue, 2005-09-27 at 12:09 -0500, Tom 'spot' Callaway wrote: > > I'm not aware of anything doing > > this, but this is not surprising, since this is a very obscure case. > > and I think would be better handled better %ifarch ... Nevermind - I'm an idiot - /usr/share is often nfs mounted. From symbiont at berlios.de Wed Sep 28 06:36:21 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Wed, 28 Sep 2005 14:36:21 +0800 Subject: [Fedora-packaging] Installing man pages In-Reply-To: <1127872815.25763.68.camel@mccallum.corsepiu.local> References: <1127837419.25763.40.camel@mccallum.corsepiu.local> <1127840940.17700.3.camel@localhost.localdomain> <1127872815.25763.68.camel@mccallum.corsepiu.local> Message-ID: <200509281436.21990.symbiont@berlios.de> On Wednesday 28 September 2005 10:00, Ralf Corsepius wrote: > IMO, packages must own directories if they install their manpages > outside of those directories provided by "filesystem". Just thought I'd throw my 2c in here: making sure that there is a 1:1 mapping for pkg to directory is a bit pedantic. What problem are we (as in packagers) actually trying to solve? rmdir will always fail upon package removal if a directory is in the %files section. This is silent and not visible to the user. Requires based on directories are founded on a fragile footing. If requires based on directories were sufficiently robust, then, things like python-abi or python(abi) never really needed to come out of the framework. Thoughts? -- -jeff From rc040203 at freenet.de Wed Sep 28 06:55:55 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 28 Sep 2005 08:55:55 +0200 Subject: [Fedora-packaging] Installing man pages In-Reply-To: <200509281436.21990.symbiont@berlios.de> References: <1127837419.25763.40.camel@mccallum.corsepiu.local> <1127840940.17700.3.camel@localhost.localdomain> <1127872815.25763.68.camel@mccallum.corsepiu.local> <200509281436.21990.symbiont@berlios.de> Message-ID: <1127890555.25763.176.camel@mccallum.corsepiu.local> On Wed, 2005-09-28 at 14:36 +0800, Jeff Pitman wrote: > On Wednesday 28 September 2005 10:00, Ralf Corsepius wrote: > > IMO, packages must own directories if they install their manpages > > outside of those directories provided by "filesystem". > > Just thought I'd throw my 2c in here: making sure that there is a 1:1 > mapping for pkg to directory is a bit pedantic. That's not the problem, ... the problem is "unowned files/dirs" ... > What problem are we > (as in packagers) actually trying to solve? ... the problem is "unowned files/dirs contradict maintainability". As RH handles directories pretty lax, when looking closely into your system, you permanently find unowned files and directories, and permanently are facing the question like * Is this empty directory still in use or did a temporarily/formerly installed package leave it around? * What has caused this dangling symlink? * Where does this unowned file stem from? etc. etc. To check, you'd normally apply "rpm -qf ". However due to RH's policy this is of very limited use and forces you to dig deeply into your file system. > rmdir will always fail upon package removal if a directory is in the > %files section. This is silent and not visible to the user. That's news to me - How that? I aware that rpm has problems in scheduling directory removals and scheduling multiple package removals, which can cause "rmdir" to fail sometimes, because they are not handled in correct order. But in any case, rpm should be able to handle "rpm -e " correctly. Ralf From fedora at leemhuis.info Thu Sep 29 14:58:13 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 29 Sep 2005 16:58:13 +0200 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests Message-ID: <1128005893.4188.39.camel@localhost.localdomain> ?Hi All! I (once again) played a bit around with kernel-modules and a scheme for packaging those for fedora-extras. A patch for mock to pass the kernel-version for which the kernel-module-pkg should be build and a discussion about it and its usage in plague currently happens on fedora-buildsys-list. I also did some experiments with binary packages based on the KernelModuleProposal 2 ( http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal ) and how yum handles those. To make my life easier I hacked up a test-script that creates a kernel-module testing-repo for yum. Those interested can find everything needed at http://www.leemhuis.info/files/fedorarpms/MISC.fdr/km-testing-yum Warning, use at your own risk. create_testrepo.sh creates a testrepo with ndiswrapper-rpms build from the two SRPMS (they are nearly identical with those from the KernelModuleProposal 2 with some slightly changes to simplify testing) in that dir. You need to install the SRPMS to your rpmbuild folder manually. You probably also need to adjust some variables in the script and copy two kernels from updates-testing over. The problems that showed up during the tests (on a fresh FC4, only UP-Kernel installed and yum updated to the latest version from updates-released [no other update]) are described below. Note, this is not meant as a rant against yum. I really like yum. It just meant as a "that the state with kernel-module{s,-proposal} and yum ATM -- if we like it or not". Seth (or anybody else), if you're interested in more details, debug output or even bug reports filled: just say and I'll do what I can. If anybody else has ideas what also could or should be tested send a mail and I'll add it. ####################### Adding a repo with > ndiswrapper-1.1-1.i386.rpm > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4.i686.rpm > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4smp.i686.rpm in it and typing ># yum --disablerepo=updates-released --enablerepo=step_1 install 'kernel-module-ndiswrapper' will result in: > [...] > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository > Size > ============================================================================= > Installing: > kernel-module-ndiswrapper i686 1.1-1.2.6.11_1.1369_FC4smp > step_1 3.3 k > Installing for dependencies: > kernel-smp i686 2.6.11-1.1369_FC4 base > 13 M > ndiswrapper i386 1.1-1 step_1 > 22 k > > Transaction Summary > ============================================================================= > Install 3 Package(s)his > [...] Seems yum prefers to install the kernel-module for the smp kernel and therefor also installs that kernel even when a UP-Kernel is installed already. Not very nice :-( ####################### Nearly the same problem as above happened when I used ># yum --disablerepo=updates-released --enablerepo=step_1 ndiswrapper > [...] > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository > Size > ============================================================================= > Installing: > ndiswrapper i386 1.1-1 step_1 > 22 k > Installing for dependencies: > kernel-module-ndiswrapper i686 1.1-1.2.6.11_1.1369_FC4smp > step_1 3.3 k > kernel-smp i686 2.6.11-1.1369_FC4 base > 13 M > > Transaction Summary > ============================================================================= > Install 3 Package(s) > [...] > ####################### Okay, next test; Both UP- and SMP-Kernel are installed now (as it normally is the case on SMP-Systems). typing > # yum --disablerepo=updates-released --enablerepo=step_1 install 'kernel-module-ndiswrapper' or > # yum --disablerepo=updates-released --enablerepo=step_1 ndiswrapper will result in something like this: > [...] > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository > Size > ============================================================================= > Installing: > kernel-module-ndiswrapper i686 1.1-1.2.6.11_1.1369_FC4smp > step_1 3.3 k > Installing for dependencies: > ndiswrapper i386 1.1-1 step_1 > 22 k > > Transaction Summary > ============================================================================= > Install 2 Package(s) > [...] In and ideal world yum would install modules for both up and smp in that case. Note: The problems described up until here probably can happen with the naming schemes currently used by Livna (where uname is in the name of the package, e.g. kernel-module-ndiswrapper-2.6.11_1.1369_FC4smp-1.1-1.i686.rpm), too. We had some of those problems in the past. ####################### Next test (only with SMP-kernel): New Ndiswrapper-Version. This is in the repo now: > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4.i686.rpm > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4smp.i686.rpm > kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4.i686.rpm > kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp.i686.rpm > ndiswrapper-1.1-1.i386.rpm > ndiswrapper-1.1-2.i386.rpm Works now! Did not with older yum version. Problem was: kernel-modules normally are installed, not updated. But in this case the pgk needs to be updated cause the files in the package would conflict otherwise. > [...] > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository > Size > ============================================================================= > Installing: > kernel-module-ndiswrapper i686 1.1-2.2.6.11_1.1369_FC4smp > step_2 3.3 k > Updating: > ndiswrapper i386 1.1-2 step_2 > 21 k > Removing: > kernel-module-ndiswrapper i686 1.1-1.2.6.11_1.1369_FC4smp > installed 11 > > Transaction Summary > ============================================================================= > Install 1 Package(s) > Update 1 Package(s) > Remove 1 Package(s) > [...] ####################### I did two further test it this point (also only with SMP-kernel) and they worked like they should: - I added a new kernel (2.6.12-1.1447_FC4) to the repo but the ndiswrapper-module was not yet in the repo -- yum updated the kernel - later I added the module (kernel-module-ndiswrapper-1.1-2.2.6.12_1.1447_FC4smp); yum installed it ####################### Last Test (for now). I placed another updated kernel and (at the same time) a update of ndiswrapper itself in the repo: > kernel-2.6.12-1.1447_FC4.i686.rpm > kernel-2.6.12-1.1456_FC4.i686.rpm > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4.i686.rpm > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4smp.i686.rpm > kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4.i686.rpm > kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp.i686.rpm > kernel-module-ndiswrapper-1.1-2.2.6.12_1.1447_FC4.i686.rpm > kernel-module-ndiswrapper-1.1-2.2.6.12_1.1447_FC4smp.i686.rpm > kernel-module-ndiswrapper-1.2-1.2.6.12_1.1456_FC4.i686.rpm > kernel-module-ndiswrapper-1.2-1.2.6.12_1.1456_FC4smp.i686.rpm > kernel-smp-2.6.12-1.1447_FC4.i686.rpm > kernel-smp-2.6.12-1.1456_FC4.i686.rpm > ndiswrapper-1.1-1.i386.rpm > ndiswrapper-1.1-2.i386.rpm > ndiswrapper-1.2-1.i386.rpm Yum installs the new kernel, new ndiswrapper and new kernel-module-ndiswrapper (as it should). But here we hit a problem with our proposal. Older kernel-module-versions stay installed, but they probably won't work with the new ndiswrapper-utils-package (maybe not in the case of ndiswrapper, but ati-fglrx, nvidia-glx, qemu and other pkg. likely will have this problem). I thought a Obsoletes in the kernel-module-ndiswraper.spec like the following might help: >Obsoletes: kernel-module-%{mainpkgname} < %{version}-%{release} And it did -- a bit: > [...] > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository > Size > ============================================================================= > Installing: > kernel-module-ndiswrapper i686 1.2-1.2.6.12_1.1456_FC4smp > step_5 3.4 k > replacing kernel-module-ndiswrapper.i686 > 1.1-2.2.6.11_1.1369_FC4smp > > kernel-smp i686 2.6.12-1.1456_FC4 step_5 > 14 M > Updating: > ndiswrapper i386 1.2-1 step_5 > 21 k > > Transaction Summary > ============================================================================= > Install 2 Package(s) > Update 1 Package(s) > Remove 0 Package(s) > > Is this ok [y/N]: y > Downloading Packages: > Running Transaction Test > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > Installing: kernel-smp ######################### > [1/4] > Installing: kernel-module-ndiswrapper ######################### > [2/4] > Updating : ndiswrapper ######################### > [3/4] > Cleanup : ndiswrapper ######################### > [4/4] > > Installed: kernel-module-ndiswrapper.i686 0:1.2-1.2.6.12_1.1456_FC4smp > kernel-smp.i686 0:2.6.12-1.1456_FC4 > Updated: ndiswrapper.i386 0:1.2-1 > Replaced: kernel-module-ndiswrapper.i686 0:1.1-2.2.6.11_1.1369_FC4smp > kernel-module-ndiswrapper.i686 0:1.1-2.2.6.12_1.1447_FC4smp > Complete! But huuuh, why are they still installed? afterwards? > $ rpm -qa 'kernel-module-ndiswrapper*' > kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp > kernel-module-ndiswrapper-1.1-2.2.6.12_1.1447_FC4smp > kernel-module-ndiswrapper-1.2-1.2.6.12_1.1456_FC4smp > $ rpm -Va 'kernel-module-ndiswrapper*' && echo okay > okay Something seems wrong here. Anybody any idea what? -- Thorsten Leemhuis From skvidal at phy.duke.edu Thu Sep 29 15:31:56 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 29 Sep 2005 11:31:56 -0400 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests In-Reply-To: <1128005893.4188.39.camel@localhost.localdomain> References: <1128005893.4188.39.camel@localhost.localdomain> Message-ID: <1128007916.26377.14.camel@cutter> > If anybody else has ideas what also could or should be tested send a > mail and I'll add it. > > ####################### > Adding a repo with > > > ndiswrapper-1.1-1.i386.rpm > > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4.i686.rpm > > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4smp.i686.rpm > > in it and typing > > ># yum --disablerepo=updates-released --enablerepo=step_1 install 'kernel-module-ndiswrapper' > > will result in: > > > [...] > > Dependencies Resolved > > > > ============================================================================= > > Package Arch Version Repository > > Size > > ============================================================================= > > Installing: > > kernel-module-ndiswrapper i686 1.1-1.2.6.11_1.1369_FC4smp > > step_1 3.3 k > > Installing for dependencies: > > kernel-smp i686 2.6.11-1.1369_FC4 base > > 13 M > > ndiswrapper i386 1.1-1 step_1 > > 22 k > > > > Transaction Summary > > ============================================================================= > > Install 3 Package(s)his > > [...] > > Seems yum prefers to install the kernel-module for the smp kernel and > therefor also installs that kernel even when a UP-Kernel is installed > already. Not very nice :-( how should yum have known which of those two you wanted? what are the clues it should use to know which of those to install? They're both named the same thing. > ####################### > Nearly the same problem as above happened when I used > > ># yum --disablerepo=updates-released --enablerepo=step_1 ndiswrapper > > > [...] > > Dependencies Resolved > > > > ============================================================================= > > Package Arch Version Repository > > Size > > ============================================================================= > > Installing: > > ndiswrapper i386 1.1-1 step_1 > > 22 k > > Installing for dependencies: > > kernel-module-ndiswrapper i686 1.1-1.2.6.11_1.1369_FC4smp > > step_1 3.3 k > > kernel-smp i686 2.6.11-1.1369_FC4 base > > 13 M > > > > Transaction Summary > > ============================================================================= > > Install 3 Package(s) > > [...] > > > > ####################### > Okay, next test; Both UP- and SMP-Kernel are installed now (as it > normally is the case on SMP-Systems). typing > > > # yum --disablerepo=updates-released --enablerepo=step_1 install 'kernel-module-ndiswrapper' > or > > # yum --disablerepo=updates-released --enablerepo=step_1 ndiswrapper > will result in something like this: > > > [...] > > Dependencies Resolved > > > > ============================================================================= > > Package Arch Version Repository > > Size > > ============================================================================= > > Installing: > > kernel-module-ndiswrapper i686 1.1-1.2.6.11_1.1369_FC4smp > > step_1 3.3 k > > Installing for dependencies: > > ndiswrapper i386 1.1-1 step_1 > > 22 k > > > > Transaction Summary > > ============================================================================= > > Install 2 Package(s) > > [...] > > In and ideal world yum would install modules for both up and smp in that > case. okay but HOW can it know? You've described what you see as problem but you haven't described any way yum can know about what's you think _should_ be going on. > Note: The problems described up until here probably can happen with the > naming schemes currently used by Livna (where uname is in the name of > the package, e.g. > kernel-module-ndiswrapper-2.6.11_1.1369_FC4smp-1.1-1.i686.rpm), too. We > had some of those problems in the past. > > ####################### > Next test (only with SMP-kernel): New Ndiswrapper-Version. This is in > the repo now: > > > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4.i686.rpm > > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4smp.i686.rpm > > kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4.i686.rpm > > kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp.i686.rpm > > ndiswrapper-1.1-1.i386.rpm > > ndiswrapper-1.1-2.i386.rpm > > Works now! Did not with older yum version. Problem was: kernel-modules > normally are installed, not updated. But in this case the pgk needs to > be updated cause the files in the package would conflict otherwise. is this item marked as provided 'kernel-module'? > Yum installs the new kernel, new ndiswrapper and new > kernel-module-ndiswrapper (as it should). But here we hit a problem with > our proposal. Older kernel-module-versions stay installed, but they > probably won't work with the new ndiswrapper-utils-package (maybe not in > the case of ndiswrapper, but ati-fglrx, nvidia-glx, qemu and other pkg. > likely will have this problem). I thought a Obsoletes in the > kernel-module-ndiswraper.spec like the following might help: > so you think yum should remove other, older kernel modules even though it doesn't have the info available to know to do that? > But huuuh, why are they still installed? afterwards? I'm not sure I understand the case you're describing here. the biggest problem with the kernel-module packaging discussion is that all of the solutions y'all have come up with have been excruciatingly complex. We've discussed them on the yum-devel list and the result is 'ugh, these are painful' both to implement the code for and to develop the packages themselves. I'm not sure any solution will match up to everyone's concept of 'correct'. -sv From ivazquez at ivazquez.net Thu Sep 29 15:36:58 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 29 Sep 2005 11:36:58 -0400 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests In-Reply-To: <1128005893.4188.39.camel@localhost.localdomain> References: <1128005893.4188.39.camel@localhost.localdomain> Message-ID: <1128008218.8471.3.camel@ignacio.lan> On Thu, 2005-09-29 at 16:58 +0200, Thorsten Leemhuis wrote: > > [...] > > Dependencies Resolved > > > > ============================================================================= > > Package Arch Version Repository > > Size > > ============================================================================= > > Installing: > > kernel-module-ndiswrapper i686 1.1-1.2.6.11_1.1369_FC4smp > > step_1 3.3 k > > Installing for dependencies: > > kernel-smp i686 2.6.11-1.1369_FC4 base > > 13 M > > ndiswrapper i386 1.1-1 step_1 > > 22 k > > > > Transaction Summary > > ============================================================================= > > Install 3 Package(s)his > > [...] > > Seems yum prefers to install the kernel-module for the smp kernel and > therefor also installs that kernel even when a UP-Kernel is installed > already. Not very nice :-( But not surprising. The SMP module has a higher version and so yum will prefer it over the "older" one. This is one of the reasons for putting the kernel version in %name instead. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Thu Sep 29 15:53:22 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 29 Sep 2005 17:53:22 +0200 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests In-Reply-To: <1128008218.8471.3.camel@ignacio.lan> References: <1128005893.4188.39.camel@localhost.localdomain> <1128008218.8471.3.camel@ignacio.lan> Message-ID: <1128009202.4188.49.camel@localhost.localdomain> Am Donnerstag, den 29.09.2005, 11:36 -0400 schrieb Ignacio Vazquez-Abrams: > On Thu, 2005-09-29 at 16:58 +0200, Thorsten Leemhuis wrote: > > > [...] > > > Dependencies Resolved > > > > > > ============================================================================= > > > Package Arch Version Repository > > > Size > > > ============================================================================= > > > Installing: > > > kernel-module-ndiswrapper i686 1.1-1.2.6.11_1.1369_FC4smp > > > step_1 3.3 k > > > Installing for dependencies: > > > kernel-smp i686 2.6.11-1.1369_FC4 base > > > 13 M > > > ndiswrapper i386 1.1-1 step_1 > > > 22 k > > > > > > Transaction Summary > > > ============================================================================= > > > Install 3 Package(s)his > > > [...] > > > > Seems yum prefers to install the kernel-module for the smp kernel and > > therefor also installs that kernel even when a UP-Kernel is installed > > already. Not very nice :-( > > But not surprising. The SMP module has a higher version and so yum will > prefer it over the "older" one. This is one of the reasons for putting > the kernel version in %name instead. No, it is not. If the kernel-version is in %name you probably have Requires: kernel-module-ndiswrapper = 1.1-1 in your ndiswrapper-package and Provides: kernel-module-ndiswrapper = 1.1-1 in the module package. This is needed to get the kernel-module when you type yum install ndiswrapper Then the same thing can happen. See for example: http://bugzilla.livna.org/show_bug.cgi?id=392#c9 Here yum installed the UP-kernel and the UP-kernel-module on a machine that only had a SMP-Kernel before. -- Thorsten Leemhuis From symbiont at berlios.de Thu Sep 29 15:59:48 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 29 Sep 2005 23:59:48 +0800 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests In-Reply-To: <1128007916.26377.14.camel@cutter> References: <1128005893.4188.39.camel@localhost.localdomain> <1128007916.26377.14.camel@cutter> Message-ID: <200509292359.49213.symbiont@berlios.de> On Thursday 29 September 2005 23:31, seth vidal wrote: > I'm not sure any solution will match up to > everyone's concept of 'correct'. I'll admit I haven't read through all the proposals, but, I'll throw out a couple of thoughts. I actually have a similar packaging scenario with multiple Pythons on the system. The best method I have devised is usage of a base package name that Requires a version-specific package name. In the case of Python it would be: python-foo Requires python24-foo. Where python-foo would essentially be an empty placeholder. Subsequent upgrades to python-foo could then Require python25-foo. While this doesn't guarantee removal of python24-foo, that's okay. Because as soon as user does remove python24, then all python24-* packages go into lala land with a "yum remove". A potential similar mapping could be made with kernels and kernel-modules: kernel-module-widget Requires kernel-module-widget-%{kver}. Then subsequent upgrades to kernel-module-widget can change that Requires bringing with it the new kernel-module-widget-%{kver}. When user removes the old kernel, then the old kernel-module-widget-%{kver} will leave with it. Others probably have thought of the same... but, it doesn't really require that much magic and no changes to yum are required. I'd like to know if there are any holes in the logic, before I get too far with my Python stuff... :P -- -jeff From fedora at leemhuis.info Thu Sep 29 16:47:10 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 29 Sep 2005 18:47:10 +0200 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests In-Reply-To: <1128007916.26377.14.camel@cutter> References: <1128005893.4188.39.camel@localhost.localdomain> <1128007916.26377.14.camel@cutter> Message-ID: <1128012430.4188.95.camel@localhost.localdomain> Am Donnerstag, den 29.09.2005, 11:31 -0400 schrieb seth vidal: > > ####################### > > Adding a repo with > > > > > ndiswrapper-1.1-1.i386.rpm > > > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4.i686.rpm > > > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4smp.i686.rpm > > > > in it and typing > > > > ># yum --disablerepo=updates-released --enablerepo=step_1 install 'kernel-module-ndiswrapper' > > > > will result in: > > > > [...] > > > > Seems yum prefers to install the kernel-module for the smp kernel and > > therefor also installs that kernel even when a UP-Kernel is installed > > already. Not very nice :-( > > how should yum have known which of those two you wanted? what are the > clues it should use to know which of those to install? They're both > named the same thing. >[...] > ####################### > > Okay, next test; Both UP- and SMP-Kernel are installed now (as it > > normally is the case on SMP-Systems). typing > > [...] > > In and ideal world yum would install modules for both up and smp in that > > case. > > okay but HOW can it know? You've described what you see as problem but > you haven't described any way yum can know about what's you think > _should_ be going on. But it is a problem and we should (read: need to) solve it imho. How? I'm not sure. We could - package modules for all kernels in one package (I don't really like this idea, but if this is the only solution we need to go it imho) - fix our proposal so it works better with yum (hint's from you are greatly appreciated) - add support for yum somehow so it can resolve the dep correctly. I unfortunately don't know neither yum nor python enough to fix that myself :-| > > ####################### > > Next test (only with SMP-kernel): New Ndiswrapper-Version. This is in > > the repo now: > > > > > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4.i686.rpm > > > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4smp.i686.rpm > > > kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4.i686.rpm > > > kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp.i686.rpm > > > ndiswrapper-1.1-1.i386.rpm > > > ndiswrapper-1.1-2.i386.rpm > > > > Works now! Did not with older yum version. Problem was: kernel-modules > > normally are installed, not updated. But in this case the pgk needs to > > be updated cause the files in the package would conflict otherwise. > > is this item marked as provided 'kernel-module'? Yes, both 'kernel-module' and 'kernel-modules'. But while at it: What of those two is the correct one? I see both in different areas of yum: $ grep kernel-module $(rpm -ql yum | grep -v -e ChangeLog -e '.pyc$' ) /usr/lib/python2.4/site-packages/yum/config.py: 'kernel-modules', /usr/lib/python2.4/site-packages/yum/depsolve.py: if txmbr.po.name.startswith("kernel-module-"): > > Yum installs the new kernel, new ndiswrapper and new > > kernel-module-ndiswrapper (as it should). But here we hit a problem with > > our proposal. Older kernel-module-versions stay installed, but they > > probably won't work with the new ndiswrapper-utils-package (maybe not in > > the case of ndiswrapper, but ati-fglrx, nvidia-glx, qemu and other pkg. > > likely will have this problem). I thought a Obsoletes in the > > kernel-module-ndiswraper.spec like the following might help: > > so you think yum should remove other, older kernel modules even though > it doesn't have the info available to know to do that? If there is something like Obsoletes: kernel-module-%{mainpkgname} < %{version}-%{release} then IMHO yes. This (or something similar) afaics is needed when for example kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4.i686.rpm works with this ndiswrapper-1.1-2.i386.rpm userland package. But after a kernel update and a pgk-update this might be installed: kernel-module-ndiswrapper-1.1-2.2.6.12_1.1447_FC4.i686.rpm ndiswrapper-1.2-1.i386.rpm But ndiswrapper-1.2 might not work with the kernel-module from ndiswrapper-1.1 (in case you boot 2.6.11_1.1369_FC4 now) One solution to avoid this would be to rebuild the kernel-module for all kernels ever released. But yum needs to install all those kenrel-module-pgk. for all kernels then, too. > > But huuuh, why are they still installed? afterwards? > I'm not sure I understand the case you're describing here. Look, it works if you use just rpm: > [thl at localhost step_5]$ rpm -qa '*ndiswrapper*' > [thl at localhost step_5]$ sudo rpm -Uvh ndiswrapper-1.1-2.i386.rpm kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp.i686.rpm > Preparing... ########################################### [100%] > 1:kernel-module-ndiswrapp########################################### [ 50%] > WARNING: Module /lib/modules/2.6.11-1.1369_FC4smp/extra/ndiswrapper/ndiswrapper.ko is not an elf object > 2:ndiswrapper ########################################### [100%] > [thl at localhost step_5]$ rpm -qa '*ndiswrapper*' > kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp > ndiswrapper-1.1-2 > [thl at localhost step_5]$ sudo rpm -Uvh ndiswrapper-1.2-1.i386.rpm kernel-module-ndiswrapper-1.2-1.2.6.12_1.1456_FC4smp.i686.rpm > Preparing... ########################################### [100%] > 1:kernel-module-ndiswrapp########################################### [ 50%] > 2:ndiswrapper ########################################### [100%] > [thl at localhost step_5]$ rpm -qa '*ndiswrapper*' > kernel-module-ndiswrapper-1.2-1.2.6.12_1.1456_FC4smp > ndiswrapper-1.2-1 > [thl at localhost step_5]$ rpm -qp --obsoletes kernel-module-ndiswrapper-1.2-1.2.6.12_1.1456_FC4smp.i686.rpm > kernel-module-ndiswrapper < 1.2-1 > [thl at localhost step_5]$ But not in yum (even if it says it removes the old stuff): > [thl at localhost step_5]$ rpm -qa '*ndiswrapper*' > kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp > ndiswrapper-1.1-2 > [thl at localhost step_5]$ sudo yum --disablerepo=updates-released --enablerepo=step_5 update > Setting up Update Process > Setting up repositories > step_5 100% |=========================| 951 B 00:00 > extras 100% |=========================| 1.1 kB 00:00 > base 100% |=========================| 1.0 kB 00:00 > Reading repository metadata in from local files > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Package kernel-module-ndiswrapper.i686 0:1.2-1.2.6.12_1.1456_FC4smp set to be installed > ---> Package ndiswrapper.i386 0:1.2-1 set to be updated > --> Running transaction check > > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository Size > ============================================================================= > Installing: > kernel-module-ndiswrapper i686 1.2-1.2.6.12_1.1456_FC4smp step_5 3.4 k > replacing kernel-module-ndiswrapper.i686 1.1-2.2.6.11_1.1369_FC4smp ^^^^^^^^ <-- ??? > Updating: > ndiswrapper i386 1.2-1 step_5 21 k > > Transaction Summary > ============================================================================= > Install 1 Package(s) > Update 1 Package(s) > Remove 0 Package(s) > Total download size: 25 k > Is this ok [y/N]: y > Downloading Packages: > Running Transaction Test > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > Installing: kernel-module-ndiswrapper ######################### [1/3] > Updating : ndiswrapper ######################### [2/3] > Cleanup : ndiswrapper ######################### [3/3] > > Installed: kernel-module-ndiswrapper.i686 0:1.2-1.2.6.12_1.1456_FC4smp > Updated: ndiswrapper.i386 0:1.2-1 > Replaced: kernel-module-ndiswrapper.i686 0:1.1-2.2.6.11_1.1369_FC4smp ^^^^^^^^ <-- ??? > Complete! > [thl at localhost step_5]$ rpm -qa '*ndiswrapper*' > kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp still there ??? > kernel-module-ndiswrapper-1.2-1.2.6.12_1.1456_FC4smp > ndiswrapper-1.2-1 > [thl at localhost step_5]$ Hope this makes things clearer. > the biggest problem with the kernel-module packaging discussion is that > all of the solutions y'all have come up with have been excruciatingly > complex. We've discussed them on the yum-devel list and the result is > 'ugh, these are painful' both to implement the code for and to develop > the packages themselves. I'm not sure any solution will match up to > everyone's concept of 'correct'. Sure -- afaics everyone involved in this endless kernel-module-proposal-discussion for fedora-extras had to accept some things that he did not (and still does not) like (me, too). But we came to no end. And I'd like to get this resolved even if I have to accept more things I don't like -- as long as they work. I'm open for suggestions. So -- Thorsten Leemhuis From rc040203 at freenet.de Thu Sep 29 16:57:26 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 29 Sep 2005 18:57:26 +0200 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests In-Reply-To: <1128008218.8471.3.camel@ignacio.lan> References: <1128005893.4188.39.camel@localhost.localdomain> <1128008218.8471.3.camel@ignacio.lan> Message-ID: <1128013047.19544.75.camel@mccallum.corsepiu.local> On Thu, 2005-09-29 at 11:36 -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2005-09-29 at 16:58 +0200, Thorsten Leemhuis wrote: > > > > Seems yum prefers to install the kernel-module for the smp kernel and > > therefor also installs that kernel even when a UP-Kernel is installed > > already. Not very nice :-( > > But not surprising. The SMP module has a higher version and so yum will > prefer it over the "older" one. This is one of the reasons for putting > the kernel version in %name instead. What I have never understood about this: Why aren't kernel-smp modules names chosen after the corresponding kernel? I.e. UP: kernel- => kernel-module-XXX- SMP: kernel-smp- => kernel-smp-module-XXX- IMO, then such a conflict as described above would not happen, because "kernel-smp-module" would require "kernel-smp" and "kernel-module" would require "kernel" Ralf From jjneely at pams.ncsu.edu Thu Sep 29 17:12:16 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Thu, 29 Sep 2005 13:12:16 -0400 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests In-Reply-To: <1128007916.26377.14.camel@cutter> References: <1128005893.4188.39.camel@localhost.localdomain> <1128007916.26377.14.camel@cutter> Message-ID: <20050929171216.GX28270@anduril.pams.ncsu.edu> > > the biggest problem with the kernel-module packaging discussion is that > all of the solutions y'all have come up with have been excruciatingly > complex. We've discussed them on the yum-devel list and the result is > 'ugh, these are painful' both to implement the code for and to develop > the packages themselves. I'm not sure any solution will match up to > everyone's concept of 'correct'. > > -sv > Agreed. This is most of the reason I haven't done any more work with added kernel module functionality to Yum. Complexity should be in the tools rather than depend on each packager to make a complex package "correctly." Jack -- Jack Neely Campus Linux Services Project Lead PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From jjneely at pams.ncsu.edu Thu Sep 29 17:16:38 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Thu, 29 Sep 2005 13:16:38 -0400 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests In-Reply-To: <1128012430.4188.95.camel@localhost.localdomain> References: <1128005893.4188.39.camel@localhost.localdomain> <1128007916.26377.14.camel@cutter> <1128012430.4188.95.camel@localhost.localdomain> Message-ID: <20050929171638.GY28270@anduril.pams.ncsu.edu> > > okay but HOW can it know? You've described what you see as problem but > > you haven't described any way yum can know about what's you think > > _should_ be going on. > > But it is a problem and we should (read: need to) solve it imho. How? > I'm not sure. We could > > - package modules for all kernels in one package (I don't really like > this idea, but if this is the only solution we need to go it imho) > - fix our proposal so it works better with yum (hint's from you are > greatly appreciated) > - add support for yum somehow so it can resolve the dep correctly. I > unfortunately don't know neither yum nor python enough to fix that > myself :-| > All kernel-modules packages require the exact kernel they are built against. Yum does/will use this information to figure out which one of the kernel-module packages are the best for your system. However, I need to figure out and change some of the more un-fun code in Yum to support this. Its not as easy as it sounds. Jack -- Jack Neely Campus Linux Services Project Lead PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From skvidal at phy.duke.edu Thu Sep 29 17:18:17 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 29 Sep 2005 13:18:17 -0400 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests In-Reply-To: <20050929171638.GY28270@anduril.pams.ncsu.edu> References: <1128005893.4188.39.camel@localhost.localdomain> <1128007916.26377.14.camel@cutter> <1128012430.4188.95.camel@localhost.localdomain> <20050929171638.GY28270@anduril.pams.ncsu.edu> Message-ID: <1128014298.26377.26.camel@cutter> On Thu, 2005-09-29 at 13:16 -0400, Jack Neely wrote: > > > okay but HOW can it know? You've described what you see as problem but > > > you haven't described any way yum can know about what's you think > > > _should_ be going on. > > > > But it is a problem and we should (read: need to) solve it imho. How? > > I'm not sure. We could > > > > - package modules for all kernels in one package (I don't really like > > this idea, but if this is the only solution we need to go it imho) > > - fix our proposal so it works better with yum (hint's from you are > > greatly appreciated) > > - add support for yum somehow so it can resolve the dep correctly. I > > unfortunately don't know neither yum nor python enough to fix that > > myself :-| > > > > All kernel-modules packages require the exact kernel they are built > against. Yum does/will use this information to figure out which one of > the kernel-module packages are the best for your system. > > However, I need to figure out and change some of the more un-fun code in > Yum to support this. Its not as easy as it sounds. > what things need to be changed or are you talking about mostly code in your patch? -sv From jjneely at pams.ncsu.edu Thu Sep 29 17:28:23 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Thu, 29 Sep 2005 13:28:23 -0400 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests In-Reply-To: <1128014298.26377.26.camel@cutter> References: <1128005893.4188.39.camel@localhost.localdomain> <1128007916.26377.14.camel@cutter> <1128012430.4188.95.camel@localhost.localdomain> <20050929171638.GY28270@anduril.pams.ncsu.edu> <1128014298.26377.26.camel@cutter> Message-ID: <20050929172823.GA28270@anduril.pams.ncsu.edu> On Thu, Sep 29, 2005 at 01:18:17PM -0400, seth vidal wrote: > On Thu, 2005-09-29 at 13:16 -0400, Jack Neely wrote: > > > > okay but HOW can it know? You've described what you see as problem but > > > > you haven't described any way yum can know about what's you think > > > > _should_ be going on. > > > > > > But it is a problem and we should (read: need to) solve it imho. How? > > > I'm not sure. We could > > > > > > - package modules for all kernels in one package (I don't really like > > > this idea, but if this is the only solution we need to go it imho) > > > - fix our proposal so it works better with yum (hint's from you are > > > greatly appreciated) > > > - add support for yum somehow so it can resolve the dep correctly. I > > > unfortunately don't know neither yum nor python enough to fix that > > > myself :-| > > > > > > > All kernel-modules packages require the exact kernel they are built > > against. Yum does/will use this information to figure out which one of > > the kernel-module packages are the best for your system. > > > > However, I need to figure out and change some of the more un-fun code in > > Yum to support this. Its not as easy as it sounds. > > > > what things need to be changed or are you talking about mostly code in > your patch? > > -sv I need to work on the code that finds all the available packages and all packages to be updated/installed to special case the kernel modules. Jack > > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Campus Linux Services Project Lead PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From skvidal at phy.duke.edu Thu Sep 29 17:29:16 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 29 Sep 2005 13:29:16 -0400 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests In-Reply-To: <20050929172823.GA28270@anduril.pams.ncsu.edu> References: <1128005893.4188.39.camel@localhost.localdomain> <1128007916.26377.14.camel@cutter> <1128012430.4188.95.camel@localhost.localdomain> <20050929171638.GY28270@anduril.pams.ncsu.edu> <1128014298.26377.26.camel@cutter> <20050929172823.GA28270@anduril.pams.ncsu.edu> Message-ID: <1128014956.26377.31.camel@cutter> > I need to work on the code that finds all the available packages and all > packages to be updated/installed to special case the kernel modules. special case how? All that available stuff is just available. -sv From jjneely at pams.ncsu.edu Thu Sep 29 17:33:37 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Thu, 29 Sep 2005 13:33:37 -0400 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests In-Reply-To: <1128014956.26377.31.camel@cutter> References: <1128005893.4188.39.camel@localhost.localdomain> <1128007916.26377.14.camel@cutter> <1128012430.4188.95.camel@localhost.localdomain> <20050929171638.GY28270@anduril.pams.ncsu.edu> <1128014298.26377.26.camel@cutter> <20050929172823.GA28270@anduril.pams.ncsu.edu> <1128014956.26377.31.camel@cutter> Message-ID: <20050929173337.GD28270@anduril.pams.ncsu.edu> On Thu, Sep 29, 2005 at 01:29:16PM -0400, seth vidal wrote: > > I need to work on the code that finds all the available packages and all > > packages to be updated/installed to special case the kernel modules. > > special case how? All that available stuff is just available. > > > -sv > > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging Let me look at it again and I'll tell you. :-) Will be next week probably... -- Jack Neely Campus Linux Services Project Lead PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From ville.skytta at iki.fi Thu Sep 29 18:04:36 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 29 Sep 2005 21:04:36 +0300 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests In-Reply-To: <1128013047.19544.75.camel@mccallum.corsepiu.local> References: <1128005893.4188.39.camel@localhost.localdomain> <1128008218.8471.3.camel@ignacio.lan> <1128013047.19544.75.camel@mccallum.corsepiu.local> Message-ID: <1128017076.2458.24.camel@localhost.localdomain> On Thu, 2005-09-29 at 18:57 +0200, Ralf Corsepius wrote: > UP: kernel- => kernel-module-XXX- > SMP: kernel-smp- => kernel-smp-module-XXX- > > IMO, then such a conflict as described above would not happen, A package that requires the kernel modules in question will need to be able to pull them in by just one NEVR, it cannot list all of the variants nor hardcode just one of them. So same Provides of some kind would then be needed in all UP/SMP/$foo variants which I think would eventually lead to the same problem. yum/rpmlib could be "smarter" when resolving dependency trees so that it'd prefer the one which results in the smallest number of _new_ packages installed if there are multiple choices, at least in some configured cases. There's (was?) the pkgpolicy functionality in yum, dunno if it has this already implemented. But I guess that'd be a partial solution anyway. From fedora at leemhuis.info Thu Sep 29 17:37:54 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 29 Sep 2005 19:37:54 +0200 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests In-Reply-To: <1128013047.19544.75.camel@mccallum.corsepiu.local> References: <1128005893.4188.39.camel@localhost.localdomain> <1128008218.8471.3.camel@ignacio.lan> <1128013047.19544.75.camel@mccallum.corsepiu.local> Message-ID: <1128015474.4188.99.camel@localhost.localdomain> Am Donnerstag, den 29.09.2005, 18:57 +0200 schrieb Ralf Corsepius: > On Thu, 2005-09-29 at 11:36 -0400, Ignacio Vazquez-Abrams wrote: > > On Thu, 2005-09-29 at 16:58 +0200, Thorsten Leemhuis wrote: > > > > > > > Seems yum prefers to install the kernel-module for the smp kernel and > > > therefor also installs that kernel even when a UP-Kernel is installed > > > already. Not very nice :-( > > > > But not surprising. The SMP module has a higher version and so yum will > > prefer it over the "older" one. This is one of the reasons for putting > > the kernel version in %name instead. > What I have never understood about this: Why aren't kernel-smp modules > names chosen after the corresponding kernel? > > I.e. > UP: kernel- => kernel-module-XXX- > SMP: kernel-smp- => kernel-smp-module-XXX- > > IMO, then such a conflict as described above would not happen, > because "kernel-smp-module" would require "kernel-smp" and > "kernel-module" would require "kernel" That could be done but doesn't help here cause ndiswrapper needs to depend on kernel{,-smp}-module-ndiswrapper. Yum would still not know if it shall install the kernel-module for up or for smp. -- Thorsten Leemhuis From pmatilai at laiskiainen.org Thu Sep 29 18:52:09 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 29 Sep 2005 21:52:09 +0300 Subject: [Fedora-packaging] kernel-module-proposal 2 and yum: some tests In-Reply-To: <1128015474.4188.99.camel@localhost.localdomain> References: <1128005893.4188.39.camel@localhost.localdomain> <1128008218.8471.3.camel@ignacio.lan> <1128013047.19544.75.camel@mccallum.corsepiu.local> <1128015474.4188.99.camel@localhost.localdomain> Message-ID: <1128019929.12668.8.camel@weasel.turre.laiskiainen.org> On Thu, 2005-09-29 at 19:37 +0200, Thorsten Leemhuis wrote: > Am Donnerstag, den 29.09.2005, 18:57 +0200 schrieb Ralf Corsepius: > > On Thu, 2005-09-29 at 11:36 -0400, Ignacio Vazquez-Abrams wrote: > > > On Thu, 2005-09-29 at 16:58 +0200, Thorsten Leemhuis wrote: > > > > > > > > > > Seems yum prefers to install the kernel-module for the smp kernel and > > > > therefor also installs that kernel even when a UP-Kernel is installed > > > > already. Not very nice :-( > > > > > > But not surprising. The SMP module has a higher version and so yum will > > > prefer it over the "older" one. This is one of the reasons for putting > > > the kernel version in %name instead. > > What I have never understood about this: Why aren't kernel-smp modules > > names chosen after the corresponding kernel? > > > > I.e. > > UP: kernel- => kernel-module-XXX- > > SMP: kernel-smp- => kernel-smp-module-XXX- This scheme was discussed back in the fedora.us days, what I remember of this particular topic is that people couldn't agree on whether the name should be kernel-smp-foo or kernel-foo-smp. :) Also with that scenario you'll loose the direct uname-r relationship complicating some other things while solving another. As typically happens with kernel module packages... > > > > IMO, then such a conflict as described above would not happen, > > because "kernel-smp-module" would require "kernel-smp" and > > "kernel-module" would require "kernel" > > That could be done but doesn't help here cause ndiswrapper needs to > depend on kernel{,-smp}-module-ndiswrapper. Yum would still not know if > it shall install the kernel-module for up or for smp. Hmm.. if yum would just prefer installed packages providing something instead of "whatever happens to be available in whatever order they happen to be encountered" it would solve at least part of this problem. Oh and if you have both up and smp kernels, well you probably should have both kernel-module variants. And then there's the question of what kernel version yum should install the module for - whatever is currently running isn't necessarily the latest etc. No matter what path I've followed with these, I've always ended up *something* requiring some naming hacks depending on uname -r output :-/ - Panu -