From mattdm at mattdm.org Fri Jul 1 20:47:09 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 1 Jul 2005 16:47:09 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? Message-ID: <20050701204709.GA23498@jadzia.bu.edu> Is there an official policy for what packages that add users for their processes to run as ought to do? I notice the recent clamav package still uses fedora-usrmgmt, but I can't find any reference to that in the current wiki, and that package still has the obsolete fedora.us wiki as its URL. What's the Right Thing here? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From tcallawa at redhat.com Fri Jul 1 23:51:50 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 18:51:50 -0500 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050701204709.GA23498@jadzia.bu.edu> References: <20050701204709.GA23498@jadzia.bu.edu> Message-ID: <1120261910.27103.29.camel@localhost.localdomain> On Fri, 2005-07-01 at 16:47 -0400, Matthew Miller wrote: > Is there an official policy for what packages that add users for their > processes to run as ought to do? I notice the recent clamav package still > uses fedora-usrmgmt, but I can't find any reference to that in the current > wiki, and that package still has the obsolete fedora.us wiki as its URL. > > What's the Right Thing here? It seems like all fedora-usermgmt was doing is as follows: - Reserve a UID for a package to use. - Add 30000 to that UID. Why don't we just have packagers request a UID for a package on a wiki page, starting at 30012 (fedora.us had 30000 - 30011)? Then, use the normal tools to create the user. Alternately, we could just keep using fedora-usermgmt. I'd assume it made its way into the FE repo, since clamav is using it? We just need to migrate the wiki pages. ~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 mattdm at mattdm.org Sat Jul 2 02:35:52 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 1 Jul 2005 22:35:52 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1120261910.27103.29.camel@localhost.localdomain> References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> Message-ID: <20050702023552.GA462@jadzia.bu.edu> On Fri, Jul 01, 2005 at 06:51:50PM -0500, Tom 'spot' Callaway wrote: > - Reserve a UID for a package to use. > - Add 30000 to that UID. > Why don't we just have packagers request a UID for a package on a wiki > page, starting at 30012 (fedora.us had 30000 - 30011)? Then, use the > normal tools to create the user. While I'm in favor of just having a registry rather than the added complication of the wrapper tool, I'd really, really, really like to use a different range, because those 30000-range UIDs already belong to people at BU and it will make using Fedora a Vast Pain. Since Extras is now "not a second class citizen", maybe we could use something in the 100-499 numbers? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From notting at redhat.com Sat Jul 2 02:57:55 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 Jul 2005 22:57:55 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050702023552.GA462@jadzia.bu.edu> References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <20050702023552.GA462@jadzia.bu.edu> Message-ID: <20050702025755.GA21115@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > Since Extras is now "not a second class citizen", maybe we could use > something in the 100-499 numbers? Sounds good to me. Bill From skvidal at phy.duke.edu Sat Jul 2 03:03:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 01 Jul 2005 23:03:06 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050702023552.GA462@jadzia.bu.edu> References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <20050702023552.GA462@jadzia.bu.edu> Message-ID: <1120273386.4617.4.camel@cutter> On Fri, 2005-07-01 at 22:35 -0400, Matthew Miller wrote: > On Fri, Jul 01, 2005 at 06:51:50PM -0500, Tom 'spot' Callaway wrote: > > - Reserve a UID for a package to use. > > - Add 30000 to that UID. > > Why don't we just have packagers request a UID for a package on a wiki > > page, starting at 30012 (fedora.us had 30000 - 30011)? Then, use the > > normal tools to create the user. > > While I'm in favor of just having a registry rather than the added > complication of the wrapper tool, I'd really, really, really like to use a > different range, because those 30000-range UIDs already belong to people at > BU and it will make using Fedora a Vast Pain. > > Since Extras is now "not a second class citizen", maybe we could use > something in the 100-499 numbers? +1. agreed. let's keep the range low - and in the area we expect to be for 'system accounts' -sv From rc040203 at freenet.de Sat Jul 2 05:05:45 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 02 Jul 2005 07:05:45 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050702023552.GA462@jadzia.bu.edu> References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <20050702023552.GA462@jadzia.bu.edu> Message-ID: <1120280745.3741.305.camel@mccallum.corsepiu.local> On Fri, 2005-07-01 at 22:35 -0400, Matthew Miller wrote: > On Fri, Jul 01, 2005 at 06:51:50PM -0500, Tom 'spot' Callaway wrote: > > - Reserve a UID for a package to use. > > - Add 30000 to that UID. > > Why don't we just have packagers request a UID for a package on a wiki > > page, starting at 30012 (fedora.us had 30000 - 30011)? Then, use the > > normal tools to create the user. > > While I'm in favor of just having a registry rather than the added > complication of the wrapper tool, I'd really, really, really like to use a > different range, because those 30000-range UIDs already belong to people at > BU and it will make using Fedora a Vast Pain. > > Since Extras is now "not a second class citizen", maybe we could use > something in the 100-499 numbers? +1 In standard configurations, this also avoid these accounts infecting yppasswd uid-space (The standard yp config in Fedora use MINUID=500) Ralf From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 2 08:01:26 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 02 Jul 2005 10:01:26 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1120261910.27103.29.camel@localhost.localdomain> (Tom Callaway's message of "Fri, 01 Jul 2005 18:51:50 -0500") References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> Message-ID: <871x6hwsa1.fsf@kosh.bigo.ensc.de> tcallawa at redhat.com ("Tom 'spot' Callaway") writes: >> Is there an official policy for what packages that add users for their >> processes to run as ought to do? I notice the recent clamav package still >> uses fedora-usrmgmt, but I can't find any reference to that in the current >> wiki, and that package still has the obsolete fedora.us wiki as its URL. >> >> What's the Right Thing here? Good question... IMO, in mid- to longterm, this should be abstracted by some rpm mechanism. Another question might be whether created users shall be removed at package removal or not. > It seems like all fedora-usermgmt was doing is as follows: > > - Reserve a UID for a package to use. > - Add 30000 to that UID. Not exactly 30000... but see below. > Why don't we just have packagers request a UID for a package on a wiki > page, starting at 30012 (fedora.us had 30000 - 30011)? Then, use the > normal tools to create the user. That's not possible. Only the range 0-99 is reserved for fixed user ids. All other ranges are free for local uses. For example the range 100-499 mentioned in another posting: every third party package which adds user, or just a simple 'useradd -r' will assign the next unused uid in this area. So you can not assign fixed UIDs in this range as it *will* cause conflicts. Using another UID range will be similarly; it may be/is possible that this range is used on some system. That's why, fedora-usermgmt was written. It creates an UID relative to a configurable base (the value in /etc/fedora/usermgmt/base[gu]id). How you fill an entry into this file is your thing... I use cfengine for it and it works well. > Alternately, we could just keep using fedora-usermgmt. I'd assume it > made its way into the FE repo, since clamav is using it? I created it for other packages also. See http://www.fedora.us/wiki/PackageUserRegistry for list of packages and http://www.fedora.us/wiki/PackageUserCreation http://www.fedora.us/wiki/PackageDynamicUserCreationConsideredBad for other information about fedora-usermgmt. 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 Sat Jul 2 08:08:34 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 02 Jul 2005 10:08:34 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050702023552.GA462@jadzia.bu.edu> (Matthew Miller's message of "Fri, 1 Jul 2005 22:35:52 -0400") References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <20050702023552.GA462@jadzia.bu.edu> Message-ID: <87wto9vddp.fsf@kosh.bigo.ensc.de> mattdm at mattdm.org (Matthew Miller) writes: > While I'm in favor of just having a registry rather than the added > complication of the wrapper tool, I'd really, really, really like to > use a different range, because those 30000-range UIDs already belong > to people at BU and it will make using Fedora a Vast Pain. As told in another posting, | echo 63000 >/etc/fedora/usermgmt/basegid | echo 63000 >/etc/fedora/usermgmt/baseuid would change the used range to 63000-.... But somebody seems to have configured it already as: * the predefined base-ids are '300' in the fedora-usermgmt-setup package * the 'predictable uid' mechanism is turned off by default and users will be created dynamically. You have to turn it on explicitly by | /usr/sbin/update-alternatives --set fedora-usermgmt /etc/fedora/usermgmt/scripts.shadow-utils Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From fedora at leemhuis.info Sat Jul 2 12:20:03 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 02 Jul 2005 14:20:03 +0200 Subject: [Fedora-packaging] kver in release (was: Re: rpms/kernel-module-thinkpad/devel kernel-module-thinkpad-console.perms, NONE, 1.1 kernel-module-thinkpad.modules, NONE, 1.1 kernel-module-thinkpad.spec, 1.7, 1.8 kernel-module-thinkpad-README.Fedora, 1.1, NONE" In-Reply-To: <200507021128.j62BSots018406@cvs-int.fedora.redhat.com> References: <200507021128.j62BSots018406@cvs-int.fedora.redhat.com> Message-ID: <1120306803.8090.59.camel@notebook.thl.home> Not really important, but imho important enough to send this mail: Am Samstag, den 02.07.2005, 07:28 -0400 schrieb Ville Skytta: >[...] > +Release: 2.%(echo %{kver} | tr - _) >[...] I'm still wondering if another character would be better. "_" is already used in the %{release} of the kernel -- imho it's a bit confusing. And it's not easy to convert the result or this tr"" back to the original output of "uname -r" if someone wants to do that. -- Thorsten Leemhuis From manowar at zapo.net Sat Jul 2 13:08:06 2005 From: manowar at zapo.net (Adrian Chelar) Date: Sat, 2 Jul 2005 16:08:06 +0300 Subject: [Fedora-packaging] what about fedora? Message-ID: <015401c57f07$166f2ad0$0c0aa8c0@yo2lux> What is fedora? a new linux project? Is newer than rumanian dracula linux? Sad but i need to say dracula package manager is better than fedora. RPM = bullshit in my opinion. You need to use dracula package manager to obtain new features !!! Adrian Chelar Home : iulian at create.ro Office : office at create.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcallawa at redhat.com Sat Jul 2 13:10:50 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 02 Jul 2005 08:10:50 -0500 Subject: [Fedora-packaging] kver in release (was: Re: rpms/kernel-module-thinkpad/devel kernel-module-thinkpad-console.perms, NONE, 1.1 kernel-module-thinkpad.modules, NONE, 1.1 kernel-module-thinkpad.spec, 1.7, 1.8 kernel-module-thinkpad-README.Fedora, 1.1, NONE" In-Reply-To: <1120306803.8090.59.camel@notebook.thl.home> References: <200507021128.j62BSots018406@cvs-int.fedora.redhat.com> <1120306803.8090.59.camel@notebook.thl.home> Message-ID: <1120309850.27103.39.camel@localhost.localdomain> On Sat, 2005-07-02 at 14:20 +0200, Thorsten Leemhuis wrote: > Not really important, but imho important enough to send this mail: > > Am Samstag, den 02.07.2005, 07:28 -0400 schrieb Ville Skytta: > >[...] > > +Release: 2.%(echo %{kver} | tr - _) > >[...] > > I'm still wondering if another character would be better. "_" is already > used in the %{release} of the kernel -- imho it's a bit confusing. And > it's not easy to convert the result or this tr"" back to the original > output of "uname -r" if someone wants to do that. What would you suggest instead? Alternately, we could make the Provides: kernel-module = %{kver}, then you'd have a guaranteed way of having the value spit out in its original output. ~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 tcallawa at redhat.com Sat Jul 2 13:13:01 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 02 Jul 2005 08:13:01 -0500 Subject: [Fedora-packaging] what about fedora? In-Reply-To: <015401c57f07$166f2ad0$0c0aa8c0@yo2lux> References: <015401c57f07$166f2ad0$0c0aa8c0@yo2lux> Message-ID: <1120309981.27103.42.camel@localhost.localdomain> On Sat, 2005-07-02 at 16:08 +0300, Adrian Chelar wrote: > What is fedora? a new linux project? Is newer than rumanian dracula > linux? > > Sad but i need to say dracula package manager is better than fedora. > > RPM = bullshit in my opinion. > You need to use dracula package manager to obtain new features !!! Isn't it a little early to be trolling? Slashdot is two doors down, on the left. ~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 mattdm at mattdm.org Sat Jul 2 13:34:38 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 2 Jul 2005 09:34:38 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <87wto9vddp.fsf@kosh.bigo.ensc.de> References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <20050702023552.GA462@jadzia.bu.edu> <87wto9vddp.fsf@kosh.bigo.ensc.de> Message-ID: <20050702133438.GA16344@jadzia.bu.edu> On Sat, Jul 02, 2005 at 10:08:34AM +0200, Enrico Scholz wrote: > As told in another posting, > > | echo 63000 >/etc/fedora/usermgmt/basegid > | echo 63000 >/etc/fedora/usermgmt/baseuid > > would change the used range to 63000-.... We're already using those too. As I imagine a lot of large instituations are. > But somebody seems to have configured it already as: > * the predefined base-ids are '300' in the fedora-usermgmt-setup package > * the 'predictable uid' mechanism is turned off by default and users > will be created dynamically. You have to turn it on explicitly by Hmmm. I think we *do* need some consistent system. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From mattdm at mattdm.org Sat Jul 2 13:44:10 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 2 Jul 2005 09:44:10 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <871x6hwsa1.fsf@kosh.bigo.ensc.de> References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> Message-ID: <20050702134410.GB16344@jadzia.bu.edu> On Sat, Jul 02, 2005 at 10:01:26AM +0200, Enrico Scholz wrote: > That's not possible. Only the range 0-99 is reserved for fixed user > ids. All other ranges are free for local uses. For example the range > 100-499 mentioned in another posting: every third party package which > adds user, or just a simple 'useradd -r' will assign the next unused > uid in this area. So you can not assign fixed UIDs in this range as it > *will* cause conflicts. > > Using another UID range will be similarly; it may be/is possible that > this range is used on some system. Yes, but the range under 500 is already defined as "special". I don't think it's unreasonable for a certain subset of that to be now marked as reserved for Fedora Extras packages. We could make it start at 300 to be less likely to conflict with random "useradd -r" done earlier. (Does useradd -r still use the wacky logic of picking the next-highest UID instead of the lowest available? That should be fixed if so -- I have a patch to change the general behavior but haven't checked if useradd -r follows its own logic.) > That's why, fedora-usermgmt was written. It creates an UID relative to a > configurable base (the value in /etc/fedora/usermgmt/base[gu]id). How > you fill an entry into this file is your thing... I use cfengine for it > and it works well. We can't have a *default* that breaks in large environments. I guess I'm not terribly opposed to continuing to use the abstraction tools so someone can pick another range if they've already got many non-standard system accounts. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From fedora at leemhuis.info Sat Jul 2 14:02:22 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 02 Jul 2005 16:02:22 +0200 Subject: [Fedora-packaging] kver in release (was: Re: rpms/kernel-module-thinkpad/devel kernel-module-thinkpad-console.perms, NONE, 1.1 kernel-module-thinkpad.modules, NONE, 1.1 kernel-module-thinkpad.spec, 1.7, 1.8 kernel-module-thinkpad-README.Fedora, 1.1, NONE" In-Reply-To: <1120309850.27103.39.camel@localhost.localdomain> References: <200507021128.j62BSots018406@cvs-int.fedora.redhat.com> <1120306803.8090.59.camel@notebook.thl.home> <1120309850.27103.39.camel@localhost.localdomain> Message-ID: <1120312942.14975.1.camel@notebook.thl.home> Am Samstag, den 02.07.2005, 08:10 -0500 schrieb Tom 'spot' Callaway: > On Sat, 2005-07-02 at 14:20 +0200, Thorsten Leemhuis wrote: > > Not really important, but imho important enough to send this mail: > > > > Am Samstag, den 02.07.2005, 07:28 -0400 schrieb Ville Skytta: > > >[...] > > > +Release: 2.%(echo %{kver} | tr - _) > > >[...] > > > > I'm still wondering if another character would be better. "_" is already > > used in the %{release} of the kernel -- imho it's a bit confusing. And > > it's not easy to convert the result or this tr"" back to the original > > output of "uname -r" if someone wants to do that. > > What would you suggest instead? What other chars are allowed in %{release}? /me looks over my keyboard = works, but probably is not a good idea ? works Or what about 2.%(echo %{kver} | sed 's/-/__/) Still confusing but at least could be converted back. > Alternately, we could make the Provides: kernel-module = %{kver}, Without the name? Yeah, why not. Does the old fedora.us/livna scheme make more sense as a virtual provides maybe? Provides: kernel-module-somename-%{kver} = %{version}-%{release} I'm undecided... -- Thorsten Leemhuis From mpeters at mac.com Sun Jul 3 08:18:09 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 03 Jul 2005 01:18:09 -0700 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050702134410.GB16344@jadzia.bu.edu> References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> Message-ID: <1120378689.2685.36.camel@locolhost.localdomain> On Sat, 2005-07-02 at 09:44 -0400, Matthew Miller wrote: > (Does useradd -r still use the wacky logic of picking the next-highest UID > instead of the lowest available? That should be fixed if so -- I have a > patch to change the general behavior but haven't checked if useradd -r > follows its own logic.) If you are going to patch useradd with the -r switch - can it also be changed to use a group ID that matches the UID? Fedora installs a group with group ID 100 but no user with uid 100 so when you use useradd with the -r switch, you end up with a different uid/gid - which isn't a functional problem, but isn't how other pairs of user/group are done. I filed an RFE bug on that some time ago, it doesn't appear to have been acted on however. From enrico.scholz at informatik.tu-chemnitz.de Sun Jul 3 10:08:32 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 03 Jul 2005 12:08:32 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> Message-ID: <878y0ourq7.fsf@kosh.bigo.ensc.de> mattdm at mattdm.org (Matthew Miller) writes: >> That's not possible. Only the range 0-99 is reserved for fixed user >> ids. All other ranges are free for local uses. For example the range >> 100-499 mentioned in another posting: every third party package which >> adds user, or just a simple 'useradd -r' will assign the next unused >> uid in this area. So you can not assign fixed UIDs in this range as it >> *will* cause conflicts. >> >> Using another UID range will be similarly; it may be/is possible that >> this range is used on some system. > > Yes, but the range under 500 is already defined as "special". I don't think > it's unreasonable for a certain subset of that to be now marked as reserved > for Fedora Extras packages. We could make it start at 300 to be less likely > to conflict with random "useradd -r" done earlier. Assigning fixed IDs in this range would violate LSB which states | The system User IDs from 100 to 499 should be reserved for dynamic | allocation by system administrators and post install scripts using | useradd. [http://www.linuxbase.org/spec//book/LSB-generic/LSB-generic/uidrange.html] That's why it would be a bad idea when Fedora Extras claims fixed UIDs there. I agree with you that every large organisation has its assigned UID ranges and it will not be possible to find a free range which can be assigned to Fedora Extras. Perhaps we could find such a range in the 32bit UID space which is allowed by Linux; but I am not sure whether we cause portability problems. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From mattdm at mattdm.org Sun Jul 3 13:43:34 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 3 Jul 2005 09:43:34 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <878y0ourq7.fsf@kosh.bigo.ensc.de> References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> <878y0ourq7.fsf@kosh.bigo.ensc.de> Message-ID: <20050703134334.GA27178@jadzia.bu.edu> On Sun, Jul 03, 2005 at 12:08:32PM +0200, Enrico Scholz wrote: > > for Fedora Extras packages. We could make it start at 300 to be less > > likely to conflict with random "useradd -r" done earlier. > Assigning fixed IDs in this range would violate LSB which states > > | The system User IDs from 100 to 499 should be reserved for dynamic > | allocation by system administrators and post install scripts using > | useradd. > [http://www.linuxbase.org/spec//book/LSB-generic/LSB-generic/uidrange.html] Well, that leaves us with stuffing Extras system UIDs into 0-99, or violating the above-500 space, which is worse. Note that the LSB doesn't say "must" -- it says "should", so it's a recommendation, not a requirement. Since we've got a need that's not really covered, goint against this recommendation is better than having the worse problem of dynamic system IDs (a nightmare for upgrades and for enterprise deployment). > That's why it would be a bad idea when Fedora Extras claims fixed UIDs > there. I agree with you that every large organisation has its assigned > UID ranges and it will not be possible to find a free range which can be > assigned to Fedora Extras. > > Perhaps we could find such a range in the 32bit UID space which is allowed > by Linux; but I am not sure whether we cause portability problems. OpenAFS makes this same (wrong) assumption that the higher numbers present some sort of unused dumping ground. The 32-bit UID space isn't a bunch of secret numbers for fun to play with. It's needed because some places actually require that many accounts. Let's not go there. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From fedora at leemhuis.info Sun Jul 3 14:11:49 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jul 2005 16:11:49 +0200 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120139542.3714.22.camel@notebook.thl.home> References: <1120139542.3714.22.camel@notebook.thl.home> Message-ID: <1120399910.2979.27.camel@notebook.thl.home> Hi * Am Donnerstag, den 30.06.2005, 15:52 +0200 schrieb Thorsten Leemhuis: > Anyway, I created a example package with kernel-modules for ndiswrapper > to play a bit with the discussed scheme. It I updated the example found online at http://www.leemhuis.info/files/fedorarpms/MISC.fdr/kernel-module-example/ and in the wiki at http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal Changes to the kernel-module-package: - These macro definitions are now found in the top of the spec file: %{!?kver: %define kver %(uname -r)} %define ksrc %{_usrsrc}/kernels/%{kver}-%{_target_cpu} %define moddir /lib/modules/%{kver}/kernel/misc %define mainpkgname ndiswrapper %define mainpkgversion 1.2 %define mainpgkrelease 1 Yes, in other packages I would not like these "mainpkg*" definitions on the top, but in this type of package I think they are helpful. - The main kernel-module package is now named "kernel-module-%{mainpkgname}-base" (if someones knows something better then "base" tell me). The kernel-module itself is now placed in %package -n kernel-module-%{mainpkgname} So only one SRPM is created no matter how much different kernel-modules are build. Also the CVS tags don't depend on the local kernel-version (I did not try but it got to this idea when I saw "Sacrifice no-args-builds-for-current-kernel for benefit of CVS tag sanity." https://www.redhat.com/archives/fedora-extras-commits/2005-July/msg00229.html ) - Now: Release: %{mainpgkrelease}.%(echo %{kver} | tr - _) Provides: kernel-module = %{kver} as suggested by spot on this list yesterday - Avoid some problems when kernel-module and kernel are deleted in one rpm transaction (anyone knows a better way to fix? "Requires(postun): kernel-%{_target_cpu} = %{kver}" does not work): -- Only depmod when System.map is still there %postun -n kernel-module-%{mainpkgname} [ -e "/boot/System.map-%{kver}" ] && \ /sbin/depmod -e -F /boot/System.map-%{kver} %{kver}> /dev/null || : -- In %files: %dir /lib/modules/%{kver}/ so that dir is removed during remove. CU thl P.S: I'm on a trip the next weeks -- I don't know how often and how long I'll have access to the Internet. So don't expect a fast reply from me during that time. And if you want to propose a kernel-module scheme that I would not like: this is you chance! ;-) -- Thorsten Leemhuis From tcallawa at redhat.com Sun Jul 3 14:09:48 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 03 Jul 2005 09:09:48 -0500 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050703134334.GA27178@jadzia.bu.edu> References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> <878y0ourq7.fsf@kosh.bigo.ensc.de> <20050703134334.GA27178@jadzia.bu.edu> Message-ID: <1120399788.27103.50.camel@localhost.localdomain> On Sun, 2005-07-03 at 09:43 -0400, Matthew Miller wrote: > On Sun, Jul 03, 2005 at 12:08:32PM +0200, Enrico Scholz wrote: > > > for Fedora Extras packages. We could make it start at 300 to be less > > > likely to conflict with random "useradd -r" done earlier. > > Assigning fixed IDs in this range would violate LSB which states > > > > | The system User IDs from 100 to 499 should be reserved for dynamic > > | allocation by system administrators and post install scripts using > > | useradd. > > [http://www.linuxbase.org/spec//book/LSB-generic/LSB-generic/uidrange.html] > > Well, that leaves us with stuffing Extras system UIDs into 0-99, or > violating the above-500 space, which is worse. Note that the LSB doesn't say > "must" -- it says "should", so it's a recommendation, not a requirement. > Since we've got a need that's not really covered, goint against this > recommendation is better than having the worse problem of dynamic system IDs > (a nightmare for upgrades and for enterprise deployment). I vote we stay below 500. My FC4 box seems to start at 500 for new UIDs. Starting at 300 seems sensible, to give FC some room. ~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 tcallawa at redhat.com Sun Jul 3 14:21:48 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 03 Jul 2005 09:21:48 -0500 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120399910.2979.27.camel@notebook.thl.home> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> Message-ID: <1120400508.27103.62.camel@localhost.localdomain> On Sun, 2005-07-03 at 16:11 +0200, Thorsten Leemhuis wrote: > - These macro definitions are now found in the top of the spec file: > %{!?kver: %define kver %(uname -r)} > %define ksrc %{_usrsrc}/kernels/%{kver}-%{_target_cpu} > %define moddir /lib/modules/%{kver}/kernel/misc > %define mainpkgname ndiswrapper > %define mainpkgversion 1.2 > %define mainpgkrelease 1 > Yes, in other packages I would not like these "mainpkg*" definitions on > the top, but in this type of package I think they are helpful. I think you're mostly right. mainpkgversion and mainpkgrelease are redundant, however. Just use Version and Release for that. > - The main kernel-module package is now named > "kernel-module-%{mainpkgname}-base" (if someones knows something better > then "base" tell me). Perhaps instead of -base, it could be -source. I'm ambivalent on that, really. > The kernel-module itself is now placed in > %package -n kernel-module-%{mainpkgname} > So only one SRPM is created no matter how much different kernel-modules > are build. This makes sense, good thinking. > - Avoid some problems when kernel-module and kernel are deleted in one > rpm transaction (anyone knows a better way to fix? "Requires(postun): > kernel-%{_target_cpu} = %{kver}" does not work): > -- Only depmod when System.map is still there > %postun -n kernel-module-%{mainpkgname} > [ -e "/boot/System.map-%{kver}" ] && \ > /sbin/depmod -e -F /boot/System.map-%{kver} %{kver}> /dev/null || : > -- In %files: > %dir /lib/modules/%{kver}/ > so that dir is removed during remove. The kernel package already owns that dir, I don't see why this is here. rpm removal ordering should take the module out first, then the kernel. Is that not the case? All in all, very good work. I think your proposal is shaping up to work well. Thanks for the time. ~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 fedora at leemhuis.info Sun Jul 3 15:25:04 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jul 2005 17:25:04 +0200 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120400508.27103.62.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> Message-ID: <1120404304.2979.47.camel@notebook.thl.home> Am Sonntag, den 03.07.2005, 09:21 -0500 schrieb Tom 'spot' Callaway: > On Sun, 2005-07-03 at 16:11 +0200, Thorsten Leemhuis wrote: > > > - These macro definitions are now found in the top of the spec file: > > %{!?kver: %define kver %(uname -r)} > > %define ksrc %{_usrsrc}/kernels/%{kver}-%{_target_cpu} > > %define moddir /lib/modules/%{kver}/kernel/misc > > %define mainpkgname ndiswrapper > > %define mainpkgversion 1.2 > > %define mainpgkrelease 1 > > Yes, in other packages I would not like these "mainpkg*" definitions on > > the top, but in this type of package I think they are helpful. > > I think you're mostly right. mainpkgversion and mainpkgrelease are > redundant, however. Just use Version and Release for that. /me thinks about that -- can't remember what my idea here was in the beginning. Removed. > > - The main kernel-module package is now named > > "kernel-module-%{mainpkgname}-base" (if someones knows something better > > then "base" tell me). > > Perhaps instead of -base, it could be -source. I'm ambivalent on that, > really. Yeah, source might be better. Changed. >[...] > > - Avoid some problems when kernel-module and kernel are deleted in one > > rpm transaction (anyone knows a better way to fix? "Requires(postun): > > kernel-%{_target_cpu} = %{kver}" does not work): > > -- Only depmod when System.map is still there > > %postun -n kernel-module-%{mainpkgname} > > [ -e "/boot/System.map-%{kver}" ] && \ > > /sbin/depmod -e -F /boot/System.map-%{kver} %{kver}> /dev/null || : > > -- In %files: > > %dir /lib/modules/%{kver}/ > > so that dir is removed during remove. > > The kernel package already owns that dir, I don't see why this is here. > rpm removal ordering should take the module out first, then the kernel. > Is that not the case? No: [thl at notebook ~]$ ls /lib/modules/ 2.6.12-1.1387_FC4 [thl at notebook ~]$ sudo rpm -ivh /home/rpmbuild/rpmbuild/RPMS/i686/kernel-module-ndiswrapper-1.2-1.2.6.11_1.1369_FC4.i686.rpm /mnt/server/all/usr/www/fedora/linux/core/4/i386/os/Fedora/RPMS/kernel-2.6.11-1.1369_FC4.i686.rpm --oldpackage Preparing... ########################################### [100%] 1:kernel ########################################### [ 50%] 2:kernel-module-ndiswrapp########################################### [100%] [thl at notebook ~]$ sudo rpm -e kernel-2.6.11-1.1369_FC4 kernel-module-ndiswrapper-1.2-1.2.6.11_1.1369_FC4.i686 [thl at notebook ~]$ ls /lib/modules/ 2.6.11-1.1369_FC4 2.6.12-1.1387_FC4 [thl at notebook ~]$ ls /lib/modules/2.6.11-1.1369_FC4/ [thl at notebook ~]$ rpm -qpl /mnt/server/all/usr/www/fedora/linux/core/4/i386/os/Fedora/RPMS/kernel-2.6.11-1.1369_FC4.i686.rpm | grep '/lib/modules/2.6.11-1.1369_FC4$' /lib/modules/2.6.11-1.1369_FC4 [thl at notebook ~]$ sudo rpm -ivh /home/rpmbuild/rpmbuild/RPMS/i686/kernel-module-ndiswrapper-1.2-1.2.6.11_1.1369_FC4.i686.rpm /mnt/server/all/usr/www/fedora/linux/core/4/i386/os/Fedora/RPMS/kernel-2.6.11-1.1369_FC4.i686.rpm --oldpackage Preparing... ########################################### [100%] 1:kernel ########################################### [ 50%] 2:kernel-module-ndiswrapp########################################### [100%] [thl at notebook ~]$ sudo rpm -e kernel-module-ndiswrapper-1.2-1.2.6.11_1.1369_FC4.i686 [thl at notebook ~]$ sudo rpm -e kernel-2.6.11-1.1369_FC4 [thl at notebook ~]$ ls /lib/modules/ 2.6.12-1.1387_FC4 [thl at notebook ~]$ Don't ask me why. Anyone any idea what's wrong here? Probably a stupid error of mine I don't see. > All in all, very good work. I think your proposal is shaping up to work > well. Thanks for the time. np -- what would be of more interest: skvidal, could something like http://www.leemhuis.info/files/fedorarpms/MISC.fdr/kernel-module-example/kernel-module-ndiswrapper.spec work together with yum or a slightly modified version of yum? Or is there anything obvious wrong here that would confuse yum? -- Thorsten Leemhuis From ville.skytta at iki.fi Sun Jul 3 16:12:40 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 03 Jul 2005 19:12:40 +0300 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120400508.27103.62.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> Message-ID: <1120407160.2695.81.camel@localhost.localdomain> On Sun, 2005-07-03 at 09:21 -0500, Tom 'spot' Callaway wrote: > On Sun, 2005-07-03 at 16:11 +0200, Thorsten Leemhuis wrote: > > > - These macro definitions are now found in the top of the spec file: > > %{!?kver: %define kver %(uname -r)} > > %define ksrc %{_usrsrc}/kernels/%{kver}-%{_target_cpu} > > %define moddir /lib/modules/%{kver}/kernel/misc > > %define mainpkgname ndiswrapper > > %define mainpkgversion 1.2 > > %define mainpgkrelease 1 > > Yes, in other packages I would not like these "mainpkg*" definitions on > > the top, but in this type of package I think they are helpful. > > I think you're mostly right. mainpkgversion and mainpkgrelease are > redundant, however. Just use Version and Release for that. Yep. A policy or at least guidelines exactly where to place the modules below /lib/modules/%{kver} would be nice. See the TODO item in the Wiki page. Personally I think /lib/modules/%{kver}/kernel/... is bad, these are not modules shipped with the kernel so intruding that space feels wrong. "updates" is bad too, these aren't updates to in-kernel modules. Upstream docs (see kbuild/modules.txt in the kernel source tree) talk about "extra", but IIRC in the past people have had the interpretation that it shouldn't be used for packaged modules. Anyway, /lib/modules/%{kver}/extra/%{mainpkgname} using the above definitions gets my vote, assuming there won't be problems with module-init-tools or other stuff with that. > > The kernel-module itself is now placed in > > %package -n kernel-module-%{mainpkgname} > > So only one SRPM is created no matter how much different kernel-modules > > are build. > > This makes sense, good thinking. Except as described in my earlier mail to this thread, if the main package's NVR doesn't change between rebuilds, we have a problem with -debuginfo for these builds. https://www.redhat.com/archives/fedora-packaging/2005-June/msg00055.html From ville.skytta at iki.fi Sun Jul 3 16:34:02 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 03 Jul 2005 19:34:02 +0300 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120404304.2979.47.camel@notebook.thl.home> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120404304.2979.47.camel@notebook.thl.home> Message-ID: <1120408442.2695.98.camel@localhost.localdomain> On Sun, 2005-07-03 at 17:25 +0200, Thorsten Leemhuis wrote: > Am Sonntag, den 03.07.2005, 09:21 -0500 schrieb Tom 'spot' Callaway: > > > - The main kernel-module package is now named > > > "kernel-module-%{mainpkgname}-base" (if someones knows something better > > > then "base" tell me). > > > > Perhaps instead of -base, it could be -source. I'm ambivalent on that, > > really. > > Yeah, source might be better. Changed. (Still has the -debuginfo problem.) > Don't ask me why. Anyone any idea what's wrong here? rpm's erasure ordering is known to still have problems (not only the CLI; yum exhibits the same problem). This problem is not limited to kernel module packages nor leftover dirs; for example %postun scriptlets are affected too (/boot/System.map-%{kver} may have disappeared in this case). Dunno if PreReq instead of Requires, or Requires + Requires(postun) instead of Requires would help. From fedora at leemhuis.info Sun Jul 3 17:10:41 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jul 2005 19:10:41 +0200 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120407160.2695.81.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120407160.2695.81.camel@localhost.localdomain> Message-ID: <1120410641.2979.68.camel@notebook.thl.home> Am Sonntag, den 03.07.2005, 19:12 +0300 schrieb Ville Skytt?: > On Sun, 2005-07-03 at 09:21 -0500, Tom 'spot' Callaway wrote: > > On Sun, 2005-07-03 at 16:11 +0200, Thorsten Leemhuis wrote: > > > > I think you're mostly right. mainpkgversion and mainpkgrelease are > > redundant, however. Just use Version and Release for that. > > Yep. Removed already :)) > A policy or at least guidelines exactly where to place the modules > below /lib/modules/%{kver} would be nice. Yes. My proposal: Put it at the same place where the normal module would be places by a normal "make install" of that package. That has several benefits: - If a external Documenation says "Look for the module in /lib/$(uname -r)/somewhere it is exactly found there where the Documentation says. No special fedora way - People sometimes try to compile a module on their own and go for the rpm later (or the other way round). They might end with two different modules in the kernel tree -- witch one wins? This can't happen if the modules are installed at their usual place. > Personally I think /lib/modules/%{kver}/kernel/... is bad, these are not > modules shipped with the kernel so intruding that space feels wrong. I don't share that opinion. I think it's confusing for no real reason. If we have a gnome-app or enhancement it's installed in the gnome-space in the filesystem also. > "updates" is bad too, these aren't updates to in-kernel modules. Yes. > > > The kernel-module itself is now placed in > > > %package -n kernel-module-%{mainpkgname} > > > So only one SRPM is created no matter how much different kernel-modules > > > are build. > > > > This makes sense, good thinking. > > Except as described in my earlier mail to this thread, if the main > package's NVR doesn't change between rebuilds, we have a problem with > -debuginfo for these builds. > https://www.redhat.com/archives/fedora-packaging/2005-June/msg00055.html Uhh, sorry, I knew I was forgetting something. Yes, that should be fixed. So what are our options: 1) create the debug-pkg ourself and don't rely on the internal rpm solution. 2) use a spec similar two my first proposal where the actual source of the kernel-module is in an external rpm that is a BuildRequire. Resulting SRPMS are small then. 3) No sub-pkg -- gives a lot of SRPMS that might take a lot of space... 4) If 1) is easy I'll vote for that. Otherwise I'd like to give 2) a try. 3) is a no go when I think of kernel-modules like ati-fglrx where each SRPM package would take around 4,5 MByte currently. Especially if we want to rebuild kernel-module for nearly all kernels that ever were published (someone suggested that somewhere in this thread iirc). -- Thorsten Leemhuis From fedora at leemhuis.info Sun Jul 3 17:31:17 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jul 2005 19:31:17 +0200 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120408442.2695.98.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120404304.2979.47.camel@notebook.thl.home> <1120408442.2695.98.camel@localhost.localdomain> Message-ID: <1120411877.2979.76.camel@notebook.thl.home> Am Sonntag, den 03.07.2005, 19:34 +0300 schrieb Ville Skytt?: > On Sun, 2005-07-03 at 17:25 +0200, Thorsten Leemhuis wrote: > > Am Sonntag, den 03.07.2005, 09:21 -0500 schrieb Tom 'spot' Callaway: > > > > > - The main kernel-module package is now named > > > > "kernel-module-%{mainpkgname}-base" (if someones knows something better > > > > then "base" tell me). > > > Perhaps instead of -base, it could be -source. I'm ambivalent on that, > > > really. > > Yeah, source might be better. Changed. > (Still has the -debuginfo problem.) See other mail > > Don't ask me why. Anyone any idea what's wrong here? > > rpm's erasure ordering is known to still have problems (not only the > CLI; yum exhibits the same problem). This problem is not limited to > kernel module packages nor leftover dirs; for example %postun scriptlets > are affected too (/boot/System.map-%{kver} may have disappeared in this > case). Dunno if PreReq instead of Requires, or Requires + > Requires(postun) instead of Requires would help. I tried Requires(postun): /boot/System.map-%{kver} Requires(postun): kernel-%{_target_cpu} = %{kver} before and tried with PreReq now also -- Nothing helped. -- Thorsten Leemhuis From fedora at leemhuis.info Sun Jul 3 19:01:08 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jul 2005 21:01:08 +0200 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120410641.2979.68.camel@notebook.thl.home> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> Message-ID: <1120417268.2979.91.camel@notebook.thl.home> Am Sonntag, den 03.07.2005, 19:10 +0200 schrieb Thorsten Leemhuis: > Am Sonntag, den 03.07.2005, 19:12 +0300 schrieb Ville Skytt?: > > On Sun, 2005-07-03 at 09:21 -0500, Tom 'spot' Callaway wrote: > > > On Sun, 2005-07-03 at 16:11 +0200, Thorsten Leemhuis wrote: > > > > > > > The kernel-module itself is now placed in > > > > %package -n kernel-module-%{mainpkgname} > > > > So only one SRPM is created no matter how much different kernel-modules > > > > are build. > > > > > > This makes sense, good thinking. > > > > Except as described in my earlier mail to this thread, if the main > > package's NVR doesn't change between rebuilds, we have a problem with > > -debuginfo for these builds. > > https://www.redhat.com/archives/fedora-packaging/2005-June/msg00055.html > > Uhh, sorry, I knew I was forgetting something. Yes, that should be > fixed. So what are our options: > > 1) create the debug-pkg ourself and don't rely on the internal rpm > solution. [...] > If 1) is easy I'll vote for that. I tried, was not that hard (if I didn't miss anything). Results are found at http://www.leemhuis.info/files/fedorarpms/MISC.fdr/kernel-module-example/ in the wiki at http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal -- Thorsten Leemhuis From ville.skytta at iki.fi Sun Jul 3 18:57:13 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 03 Jul 2005 21:57:13 +0300 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120410641.2979.68.camel@notebook.thl.home> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> Message-ID: <1120417033.2695.161.camel@localhost.localdomain> On Sun, 2005-07-03 at 19:10 +0200, Thorsten Leemhuis wrote: > Am Sonntag, den 03.07.2005, 19:12 +0300 schrieb Ville Skytt?: > > > A policy or at least guidelines exactly where to place the modules > > below /lib/modules/%{kver} would be nice. > > Yes. > > My proposal: [...] I forgot to mention that I don't have strong opinions on this, as long as some understandable guidelines exist. Installing into whatever upstream uses by default does have its merits like you pointed out. > > Except as described in my earlier mail to this thread, if the main > > package's NVR doesn't change between rebuilds, we have a problem with > > -debuginfo for these builds. > > https://www.redhat.com/archives/fedora-packaging/2005-June/msg00055.html > > Uhh, sorry, I knew I was forgetting something. Yes, that should be > fixed. So what are our options: > > 1) create the debug-pkg ourself and don't rely on the internal rpm > solution. Urgh, have you looked at glibc.spec? We really don't want that in every kernel module package. Perhaps it's acceptable if we could just call a script somewhere and be done with it. But the fundamental problem isn't actually limited to -debuginfo, but affects SRPMs to some extent as well (same-NEVR'd SRPM from different builds - what to do with them?). See below. > 2) use a spec similar two my first proposal where the actual source of > the kernel-module is in an external rpm that is a BuildRequire. I still don't like this too much in principle, but all the alternatives seem to have shortcomings of their own as well, so it seems we need to pick the least bad alternative. And this is a definite candidate. If I understand correctly, the binary-containing-source package could be theoretically reused in DKMS and similar systems - that would make this approach even more attractive. > 3) No sub-pkg -- gives a lot of SRPMS that might take a lot of space... Theoretically, we can choose to not ship these SRPMS at all. Their rebuild results vary depending on the passed in (or detected, in case of local rebuilds) kver anyway; what it was at build time won't affect the results. So essentially they're just the same things except for the filename of the SRPM. OTOH, not shipping them sounds fundamentally wrong. In the meantime, status of kernel-module-thinkpad in CVS: - The SRPM duplication (non?)problem persists. - It can be built for the running kernel without specifying kver, but the -debuginfo problem and the problem of getting same-NEVR'd source packages from different (specfile based) builds bites then. This would not affect us, I assume we will always pass kver. And the problem would be trivially solved by just removing the possibility to build without specifying kver. I'm starting to think that Thorsten's 2) above would actually solve all our problems, even if it's hackish, not the pretties one and it's a bit hard to understand. From aoliva at redhat.com Sun Jul 3 19:42:40 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 03 Jul 2005 16:42:40 -0300 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1120399788.27103.50.camel@localhost.localdomain> References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> <878y0ourq7.fsf@kosh.bigo.ensc.de> <20050703134334.GA27178@jadzia.bu.edu> <1120399788.27103.50.camel@localhost.localdomain> Message-ID: On Jul 3, 2005, "Tom 'spot' Callaway" wrote: > I vote we stay below 500. My FC4 box seems to start at 500 for new UIDs. > Starting at 300 seems sensible, to give FC some room. Erhm... But what about all those existing user bases introduced when only the range below 100 was reserved? My uid at the uni has been 404 since 1991. FWIW, it wasn't an HTTP error code back then, to the best of my knowledge; it was just the number right after 403. -- 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 mattdm at mattdm.org Sun Jul 3 20:58:41 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 3 Jul 2005 16:58:41 -0400 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120410641.2979.68.camel@notebook.thl.home> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> Message-ID: <20050703205841.GA3964@jadzia.bu.edu> On Sun, Jul 03, 2005 at 07:10:41PM +0200, Thorsten Leemhuis wrote: > My proposal: Put it at the same place where the normal module would be > places by a normal "make install" of that package. That has several > benefits: [benefits snipped] Drawback -- some packages (like OpenAFS, go figure) want to put the module in a really stupid place by default. We should follow the FHS and Fedora/RH precedent of fixing install location of files when the package is non-standard. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From mattdm at mattdm.org Sun Jul 3 21:00:22 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 3 Jul 2005 17:00:22 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> <878y0ourq7.fsf@kosh.bigo.ensc.de> <20050703134334.GA27178@jadzia.bu.edu> <1120399788.27103.50.camel@localhost.localdomain> Message-ID: <20050703210022.GB3964@jadzia.bu.edu> On Sun, Jul 03, 2005 at 04:42:40PM -0300, Alexandre Oliva wrote: > Erhm... But what about all those existing user bases introduced when > only the range below 100 was reserved? My uid at the uni has been 404 > since 1991. FWIW, it wasn't an HTTP error code back then, to the best > of my knowledge; it was just the number right after 403. How long ago was that? If I remember right, the default start number in Red Hat Linux 4.2 was 500.... But anyway, there's not enough room below 100, so something has to give. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From skvidal at phy.duke.edu Sun Jul 3 23:02:31 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 03 Jul 2005 19:02:31 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> <878y0ourq7.fsf@kosh.bigo.ensc.de> <20050703134334.GA27178@jadzia.bu.edu> <1120399788.27103.50.camel@localhost.localdomain> Message-ID: <1120431751.4617.103.camel@cutter> On Sun, 2005-07-03 at 16:42 -0300, Alexandre Oliva wrote: > On Jul 3, 2005, "Tom 'spot' Callaway" wrote: > > > I vote we stay below 500. My FC4 box seems to start at 500 for new UIDs. > > Starting at 300 seems sensible, to give FC some room. > > Erhm... But what about all those existing user bases introduced when > only the range below 100 was reserved? My uid at the uni has been 404 > since 1991. FWIW, it wasn't an HTTP error code back then, to the best > of my knowledge; it was just the number right after 403. Yes - and I had users who had uid's of 10 b/c they started out on ultrix and sunos. sucks to be in that situation. Change your uid and chown all your files. This is the nature of legacy. At some point it has to change. -sv From jjneely at pams.ncsu.edu Sun Jul 3 23:46:03 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Sun, 3 Jul 2005 19:46:03 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1120399788.27103.50.camel@localhost.localdomain> References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> <878y0ourq7.fsf@kosh.bigo.ensc.de> <20050703134334.GA27178@jadzia.bu.edu> <1120399788.27103.50.camel@localhost.localdomain> Message-ID: <20050703234603.GD1972@anduril.pams.ncsu.edu> > > I vote we stay below 500. My FC4 box seems to start at 500 for new UIDs. > Starting at 300 seems sensible, to give FC some room. > > ~spot I think this is the most sane. Jack -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From enrico.scholz at informatik.tu-chemnitz.de Mon Jul 4 05:57:55 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 04 Jul 2005 07:57:55 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050703134334.GA27178@jadzia.bu.edu> (Matthew Miller's message of "Sun, 3 Jul 2005 09:43:34 -0400") References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> <878y0ourq7.fsf@kosh.bigo.ensc.de> <20050703134334.GA27178@jadzia.bu.edu> Message-ID: <87y88nt8nw.fsf@kosh.bigo.ensc.de> mattdm at mattdm.org (Matthew Miller) writes: >> > for Fedora Extras packages. We could make it start at 300 to be less >> > likely to conflict with random "useradd -r" done earlier. >> Assigning fixed IDs in this range would violate LSB which states >> >> | The system User IDs from 100 to 499 should be reserved for dynamic >> | allocation by system administrators and post install scripts using >> | useradd. >> [http://www.linuxbase.org/spec//book/LSB-generic/LSB-generic/uidrange.html] > > Well, that leaves us with stuffing Extras system UIDs into 0-99, or > violating the above-500 space, ... or using the fedora-usermgmt approach where every system administrator can decide whether he wants semi-fixed uids and where he can configure a free uid-range which is used for it. > which is worse. Note that the LSB doesn't say "must" -- it says > "should", so it's a recommendation, not a requirement. Yes, it is only a recommendation. But should we violate it when alternative solutions are existing? The count of 200 free UIDs seems to be a little bit low for me; almost every package with a daemon will require an own user so we will fill the claimed 300-499 space in a few years. Or -- why do not we take the 500-999 area and let normal users begin at 1000 (latter is already the case e.g. in Debian)? There the same situation will arise: there might be conflicts with existing installations (like with the 300-499 or any other fixed range), but as Seth says: "Change your uid and chown all your files. This is the nature of legacy." Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From aoliva at redhat.com Mon Jul 4 13:27:48 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 04 Jul 2005 10:27:48 -0300 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050703210022.GB3964@jadzia.bu.edu> References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> <878y0ourq7.fsf@kosh.bigo.ensc.de> <20050703134334.GA27178@jadzia.bu.edu> <1120399788.27103.50.camel@localhost.localdomain> <20050703210022.GB3964@jadzia.bu.edu> Message-ID: On Jul 3, 2005, Matthew Miller wrote: > On Sun, Jul 03, 2005 at 04:42:40PM -0300, Alexandre Oliva wrote: >> Erhm... But what about all those existing user bases introduced when >> only the range below 100 was reserved? My uid at the uni has been 404 >> since 1991. FWIW, it wasn't an HTTP error code back then, to the best >> of my knowledge; it was just the number right after 403. > How long ago was that? If I remember right, the default start number in Red > Hat Linux 4.2 was 500.... That's no use if you created the userbase on say SunOS 4.0. > But anyway, there's not enough room below 100, so something has to give. Which is exactly why making it configurable is a good idea IMHO. -- 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 tcallawa at redhat.com Mon Jul 4 14:20:44 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 04 Jul 2005 09:20:44 -0500 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> <878y0ourq7.fsf@kosh.bigo.ensc.de> <20050703134334.GA27178@jadzia.bu.edu> <1120399788.27103.50.camel@localhost.localdomain> Message-ID: <1120486844.27103.70.camel@localhost.localdomain> On Sun, 2005-07-03 at 16:42 -0300, Alexandre Oliva wrote: > On Jul 3, 2005, "Tom 'spot' Callaway" wrote: > > > I vote we stay below 500. My FC4 box seems to start at 500 for new UIDs. > > Starting at 300 seems sensible, to give FC some room. > > Erhm... But what about all those existing user bases introduced when > only the range below 100 was reserved? My uid at the uni has been 404 > since 1991. FWIW, it wasn't an HTTP error code back then, to the best > of my knowledge; it was just the number right after 403. :) I suspect that we'll find that due to poor historical planning, every UID above 100 is used by someone, somewhere. ~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 tcallawa at redhat.com Mon Jul 4 14:30:53 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 04 Jul 2005 09:30:53 -0500 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120417268.2979.91.camel@notebook.thl.home> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> Message-ID: <1120487453.27103.79.camel@localhost.localdomain> On Sun, 2005-07-03 at 21:01 +0200, Thorsten Leemhuis wrote: > > 1) create the debug-pkg ourself and don't rely on the internal rpm > > solution. > [...] > > If 1) is easy I'll vote for that. > > I tried, was not that hard (if I didn't miss anything). Results are > found at > http://www.leemhuis.info/files/fedorarpms/MISC.fdr/kernel-module-example/ > in the wiki at > http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal I like this approach the best. The only change is that the -debuginfo package needs to Require: kernel-module-%{mainpkgname} (its not any good without it). As to location, I'm very inclined to standardize on: /lib/modules/%{kver}/extra/%{mainpkgname} To address Thorsten's concerns: - Lots of external documentation conflicts with what we package in Fedora Core or Fedora Extras. rpm -ql kernel-module-openafs works very well. :) - Double existing modules. Same thing happens if you compile Apache by hand, you get two copies of Apache on the system. There may EVEN be cases in which you want to do this for kernel modules. The modutils look for the first module which matches that name in the tree. By using extras/, we trump the kernel/ drivers directory. I think it is important to point out which drivers came with the FC kernel, and which ones are provided by FE addon packages. Using the "extra" namespace is the cleanest way to do this. ~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 enrico.scholz at informatik.tu-chemnitz.de Mon Jul 4 15:27:17 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 04 Jul 2005 17:27:17 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> <878y0ourq7.fsf@kosh.bigo.ensc.de> <20050703134334.GA27178@jadzia.bu.edu> <1120399788.27103.50.camel@localhost.localdomain> <1120486844.27103.70.camel@localhost.localdomain> Message-ID: <87mzp2382y.fsf@kosh.bigo.ensc.de> tcallawa at redhat.com ("Tom 'spot' Callaway") writes: > I suspect that we'll find that due to poor historical planning, every > UID above 100 is used by someone, somewhere. Exactly; that's why, Fedora Extras can not claim a fixed UID range there. Neither in 100-499, nor in 500-2^16, nor in the upper 32 bit range. Enrico From tcallawa at redhat.com Mon Jul 4 15:41:14 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 04 Jul 2005 10:41:14 -0500 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <87mzp2382y.fsf@kosh.bigo.ensc.de> References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> <878y0ourq7.fsf@kosh.bigo.ensc.de> <20050703134334.GA27178@jadzia.bu.edu> <1120399788.27103.50.camel@localhost.localdomain> <1120486844.27103.70.camel@localhost.localdomain> <87mzp2382y.fsf@kosh.bigo.ensc.de> Message-ID: <1120491674.30349.0.camel@localhost.localdomain> On Mon, 2005-07-04 at 17:27 +0200, Enrico Scholz wrote: > tcallawa at redhat.com ("Tom 'spot' Callaway") writes: > > > I suspect that we'll find that due to poor historical planning, every > > UID above 100 is used by someone, somewhere. > > Exactly; that's why, Fedora Extras can not claim a fixed UID range > there. Neither in 100-499, nor in 500-2^16, nor in the upper 32 bit > range. Nevertheless, we need to have a default. I'm not opposed to using the existing user tools to create the IDs, merely that the default starting UID should be 300. ~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 mattdm at mattdm.org Mon Jul 4 16:17:22 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 4 Jul 2005 12:17:22 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1120491674.30349.0.camel@localhost.localdomain> References: <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> <878y0ourq7.fsf@kosh.bigo.ensc.de> <20050703134334.GA27178@jadzia.bu.edu> <1120399788.27103.50.camel@localhost.localdomain> <1120486844.27103.70.camel@localhost.localdomain> <87mzp2382y.fsf@kosh.bigo.ensc.de> <1120491674.30349.0.camel@localhost.localdomain> Message-ID: <20050704161722.GA4976@jadzia.bu.edu> On Mon, Jul 04, 2005 at 10:41:14AM -0500, Tom 'spot' Callaway wrote: > > Exactly; that's why, Fedora Extras can not claim a fixed UID range > > there. Neither in 100-499, nor in 500-2^16, nor in the upper 32 bit > > range. > Nevertheless, we need to have a default. I'm not opposed to using the > existing user tools to create the IDs, merely that the default starting > UID should be 300. And that we should have a registry of standard fixed UIDs within that range, right? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 76 degrees Fahrenheit. From mattdm at mattdm.org Mon Jul 4 16:20:06 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 4 Jul 2005 12:20:06 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <87y88nt8nw.fsf@kosh.bigo.ensc.de> References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> <878y0ourq7.fsf@kosh.bigo.ensc.de> <20050703134334.GA27178@jadzia.bu.edu> <87y88nt8nw.fsf@kosh.bigo.ensc.de> Message-ID: <20050704162006.GB4976@jadzia.bu.edu> On Mon, Jul 04, 2005 at 07:57:55AM +0200, Enrico Scholz wrote: > The count of 200 free UIDs seems to be a little bit low for me; almost > every package with a daemon will require an own user so we will fill the > claimed 300-499 space in a few years. > > Or -- why do not we take the 500-999 area and let normal users begin at > 1000 (latter is already the case e.g. in Debian)? There the same situation > will arise: there might be conflicts with existing installations (like > with the 300-499 or any other fixed range), but as Seth says: "Change your > uid and chown all your files. This is the nature of legacy." We can start with 300-499 now, and then move the default minuid to 1000 in Fedora Core sometime later, with a warning that ids < 500 will become system ids in some future release, and then finally at some point in the future, make that change. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 76 degrees Fahrenheit. From Christian.Iseli at licr.org Mon Jul 4 16:31:42 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 04 Jul 2005 18:31:42 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: Your message of "Mon, 04 Jul 2005 12:17:22 EDT." <20050704161722.GA4976@jadzia.bu.edu> Message-ID: <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> mattdm at mattdm.org said: > And that we should have a registry of standard fixed UIDs within that range, > right? That's the part I don't understand: why a global registry ? Isn't the point of adding local UIDs to get a kind of macro thing, i.e. what is standard is the name, which should be the same on all machines, but nobody cares what the actual UID is ? I agree it can get a bit hairy when several machines share things by NFS, but having a central global UID registry also seems hairy. The only real special UID is numbered 0. But probably I'm overlooking something obvious :) Anybody cares to explain ? Thanks, Christian From mattdm at mattdm.org Mon Jul 4 16:54:10 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 4 Jul 2005 12:54:10 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> Message-ID: <20050704165410.GA5937@jadzia.bu.edu> On Mon, Jul 04, 2005 at 06:31:42PM +0200, Christian.Iseli at licr.org wrote: > mattdm at mattdm.org said: > > And that we should have a registry of standard fixed UIDs within that range, > > right? > That's the part I don't understand: why a global registry ? So that multiple systems have the same ids. Or so that if you do a reinstall, your files have the same owners. > Isn't the point of adding local UIDs to get a kind of macro thing, i.e. what > is standard is the name, which should be the same on all machines, but nobody > cares what the actual UID is ? The filesystem cares. Therefore, we have to. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 76 degrees Fahrenheit. From jjneely at pams.ncsu.edu Mon Jul 4 21:51:58 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Mon, 4 Jul 2005 17:51:58 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050704162006.GB4976@jadzia.bu.edu> References: <20050701204709.GA23498@jadzia.bu.edu> <1120261910.27103.29.camel@localhost.localdomain> <871x6hwsa1.fsf@kosh.bigo.ensc.de> <20050702134410.GB16344@jadzia.bu.edu> <878y0ourq7.fsf@kosh.bigo.ensc.de> <20050703134334.GA27178@jadzia.bu.edu> <87y88nt8nw.fsf@kosh.bigo.ensc.de> <20050704162006.GB4976@jadzia.bu.edu> Message-ID: <20050704215158.GE1972@anduril.pams.ncsu.edu> > > We can start with 300-499 now, and then move the default minuid to 1000 in > Fedora Core sometime later, with a warning that ids < 500 will become system > ids in some future release, and then finally at some point in the future, > make that change. > I'm all about being able to configure where these IDs fall. But lets definitely make the default 300-499 for now. That's the most consistent with the way Red Hat / Fedora Core does things and is least likely to cause an existing installation to blow up. If the user wants to they can set there system to use another range if needed. Jack -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 5 12:07:32 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 5 Jul 2005 14:07:32 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> Message-ID: <20050705140732.7363d257@python2> Christian.Iseli at licr.org wrote : > That's the part I don't understand: why a global registry ? > [...] > > I agree it can get a bit hairy when several machines share things by NFS, but > having a central global UID registry also seems hairy. That's the point : Fixed uid/gid is often a good thing, I have many setups where a bunch of redundant servers access the same nfs share, and I'm in trouble when I install packages on those servers which create a user with a non fixed uid, and one gets say 201 and the other 202... I'm really grateful to know I can expect apache to be uid 48 everywhere, for instance. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 0.40 1.01 2.31 From steve at silug.org Tue Jul 5 16:01:30 2005 From: steve at silug.org (Steven Pritchard) Date: Tue, 5 Jul 2005 11:01:30 -0500 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> Message-ID: <20050705160130.GA28606@osiris.silug.org> On Mon, Jul 04, 2005 at 06:31:42PM +0200, Christian.Iseli at licr.org wrote: > That's the part I don't understand: why a global registry ? > > Isn't the point of adding local UIDs to get a kind of macro thing, i.e. what > is standard is the name, which should be the same on all machines, but nobody > cares what the actual UID is ? I have to agree. I can't think of a single reason why it would matter (for example) what UID the openvpn user is on any system. It's just an unprivileged user that openvpn can be configured to run as (after starting as root). I could use "nobody", but, well, that seems to be bad form these days. > I agree it can get a bit hairy when several machines share things by NFS, but > having a central global UID registry also seems hairy. In that case, there's NIS/NIS+/LDAP/whatever, and it is up to the sysadmin to do any extra work necessary to integrate the package into their environment. In the case of my openvpn package, if "useradd -r" does the right thing, then the problem is solved. If not, the sysadmin can just add an openvpn user before installing the package. 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 mattdm at mattdm.org Tue Jul 5 16:25:20 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 5 Jul 2005 12:25:20 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050705160130.GA28606@osiris.silug.org> References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> <20050705160130.GA28606@osiris.silug.org> Message-ID: <20050705162520.GA19052@jadzia.bu.edu> On Tue, Jul 05, 2005 at 11:01:30AM -0500, Steven Pritchard wrote: > I have to agree. I can't think of a single reason why it would matter > (for example) what UID the openvpn user is on any system. It's just > an unprivileged user that openvpn can be configured to run as (after > starting as root). I could use "nobody", but, well, that seems to be > bad form these days. That's all well and good until the user owns files. > In that case, there's NIS/NIS+/LDAP/whatever, and it is up to the > sysadmin to do any extra work necessary to integrate the package into > their environment. In the case of my openvpn package, if "useradd -r" > does the right thing, then the problem is solved. If not, the > sysadmin can just add an openvpn user before installing the package. Why should the *default* be "you have to do some extra work"? The standard case should be just that -- standard. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From enrico.scholz at informatik.tu-chemnitz.de Tue Jul 5 17:34:16 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 05 Jul 2005 19:34:16 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050705160130.GA28606@osiris.silug.org> (Steven Pritchard's message of "Tue, 5 Jul 2005 11:01:30 -0500") References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> <20050705160130.GA28606@osiris.silug.org> Message-ID: <87fyuti2cn.fsf@kosh.bigo.ensc.de> steve at silug.org (Steven Pritchard) writes: >> I agree it can get a bit hairy when several machines share things by >> NFS, but having a central global UID registry also seems hairy. > > In that case, there's NIS/NIS+/LDAP/whatever, System users should be in /etc/passwd because the requirements for NIS/LDAP/whatever might not be fulfilled for early services; e.g. openvpn will be executed before the ldap service so the 'openvpn' user might not be resolveable at this time. LDAP/NIS might be unwanted in certain environments also (e.g. on firewalls, portable machines). > and it is up to the sysadmin to do any extra work necessary to integrate > the package into their environment. In the case of my openvpn package, > if "useradd -r" does the right thing, then the problem is solved. If > not, the sysadmin can just add an openvpn user before installing the > package. rpm does not offer a way to determine whether a package creates an user or not. So the 'just add an ... user before installing' requires lot of manual work, and automatic updates can not be applied. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From steve at silug.org Tue Jul 5 18:32:22 2005 From: steve at silug.org (Steven Pritchard) Date: Tue, 5 Jul 2005 13:32:22 -0500 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <87fyuti2cn.fsf@kosh.bigo.ensc.de> References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> <20050705160130.GA28606@osiris.silug.org> <87fyuti2cn.fsf@kosh.bigo.ensc.de> Message-ID: <20050705183222.GA32528@osiris.silug.org> On Tue, Jul 05, 2005 at 07:34:16PM +0200, Enrico Scholz wrote: > System users should be in /etc/passwd because the requirements for > NIS/LDAP/whatever might not be fulfilled for early services; > e.g. openvpn will be executed before the ldap service so the 'openvpn' > user might not be resolveable at this time. > > LDAP/NIS might be unwanted in certain environments also (e.g. on > firewalls, portable machines). And those systems don't need to share files owned by system users, so it is a non-issue. > rpm does not offer a way to determine whether a package creates an user > or not. So the 'just add an ... user before installing' requires lot of > manual work, $ rpm -qp --requires openvpn-2.0-2.x86_64.rpm | grep useradd /usr/sbin/useradd $ rpm -qp --scripts openvpn-2.0-2.x86_64.rpm preinstall scriptlet (using /bin/sh): if ! id openvpn > /dev/null 2>&1 ; then /usr/sbin/useradd -r -s /sbin/nologin -c OpenVPN -d /etc/openvpn openvpn fi [...] In the (likely far) less than 1% of cases where that's not good enough, I can't imagine why letting the sysadmin fix any issues that we can't possibly anticipate is a problem. > and automatic updates can not be applied. Uh, I've been auto-updating every system I have openvpn, clamav, etc. on for, what, a year and a half? I must not understand you. 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 Tue Jul 5 18:33:45 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 05 Jul 2005 21:33:45 +0300 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050705162520.GA19052@jadzia.bu.edu> References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> <20050705160130.GA28606@osiris.silug.org> <20050705162520.GA19052@jadzia.bu.edu> Message-ID: <1120588425.6862.90.camel@localhost.localdomain> On Tue, 2005-07-05 at 12:25 -0400, Matthew Miller wrote: > On Tue, Jul 05, 2005 at 11:01:30AM -0500, Steven Pritchard wrote: > > > In that case, there's NIS/NIS+/LDAP/whatever, and it is up to the > > sysadmin to do any extra work necessary to integrate the package into > > their environment. In the case of my openvpn package, if "useradd -r" > > does the right thing, then the problem is solved. If not, the > > sysadmin can just add an openvpn user before installing the package. Agreed on all counts. And in addition to the above, NFS4 should help in some specific cases too. > Why should the *default* be "you have to do some extra work"? It shouldn't, but what do you think can be done about it? Not really an argument to any direction, but IMO the extra work not fatally wrong either because to get into a situation where any of this matters, one has already had to do some extra work, and could just take care of the uid mappings while at it. Shouldn't be a big deal. > The standard case should be just that -- standard. If someone can come up with a standard or defaults that do not bluntly declare existing standards and policies, which have really nothing wrong in them, as broken or incompatible, that would be cool. FWIW, personally I think the time when that would have been really possible has passed a looooong time ago. One semi-related point: migrating existing packages in public, supported repositories that have not used a fixed uid mapping scheme before to use one is probably not going to be feasible. From mattdm at mattdm.org Tue Jul 5 18:59:40 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 5 Jul 2005 14:59:40 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1120588425.6862.90.camel@localhost.localdomain> References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> <20050705160130.GA28606@osiris.silug.org> <20050705162520.GA19052@jadzia.bu.edu> <1120588425.6862.90.camel@localhost.localdomain> Message-ID: <20050705185940.GA25219@jadzia.bu.edu> On Tue, Jul 05, 2005 at 09:33:45PM +0300, Ville Skytt? wrote: > One semi-related point: migrating existing packages in public, supported > repositories that have not used a fixed uid mapping scheme before to use > one is probably not going to be feasible. Why not? They'd just be going from some-random-id to some-random-id-which- happens-to-be-the-same-every-time-thank-goodness. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From enrico.scholz at informatik.tu-chemnitz.de Tue Jul 5 19:06:40 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 05 Jul 2005 21:06:40 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050705183222.GA32528@osiris.silug.org> (Steven Pritchard's message of "Tue, 5 Jul 2005 13:32:22 -0500") References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> <20050705160130.GA28606@osiris.silug.org> <87fyuti2cn.fsf@kosh.bigo.ensc.de> <20050705183222.GA32528@osiris.silug.org> Message-ID: <877jg5hy2n.fsf@kosh.bigo.ensc.de> steve at silug.org (Steven Pritchard) writes: >> rpm does not offer a way to determine whether a package creates an user >> or not. So the 'just add an ... user before installing' requires lot of >> manual work, > > $ rpm -qp --requires openvpn-2.0-2.x86_64.rpm | grep useradd > /usr/sbin/useradd > $ rpm -qp --scripts openvpn-2.0-2.x86_64.rpm > preinstall scriptlet (using /bin/sh): > if ! id openvpn > /dev/null 2>&1 ; then > /usr/sbin/useradd -r -s /sbin/nologin -c OpenVPN -d /etc/openvpn openvpn > fi > [...] And now: do this for a 'yum install ...' transaction which lists 100 new packages and tell me all new users inclusive information like homedir, shell and gecos... Or for a nightly 'yum upgrade' operation which adds new packages because of changed dependencies. 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 Jul 5 19:32:30 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 05 Jul 2005 21:32:30 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1120588425.6862.90.camel@localhost.localdomain> (Ville Skytt's message of "Tue, 05 Jul 2005 21:33:45 +0300") References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> <20050705160130.GA28606@osiris.silug.org> <20050705162520.GA19052@jadzia.bu.edu> <1120588425.6862.90.camel@localhost.localdomain> Message-ID: <873bqthwvl.fsf@kosh.bigo.ensc.de> ville.skytta at iki.fi (Ville Skytt?) writes: >> > In that case, there's NIS/NIS+/LDAP/whatever, and it is up to the >> > sysadmin to do any extra work necessary to integrate the package >> > into their environment. In the case of my openvpn package, if >> > "useradd -r" does the right thing, then the problem is solved. If >> > not, the sysadmin can just add an openvpn user before installing >> > the package. > > Agreed on all counts. And in addition to the above, NFS4 should help in > some specific cases too. Sharing does not happen only over NFS. It can happen with '--bind' mounts between chroot environments, and Xen allows (limited) block device sharing also. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From ville.skytta at iki.fi Tue Jul 5 19:34:40 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 05 Jul 2005 22:34:40 +0300 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120487453.27103.79.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> Message-ID: <1120592080.6862.136.camel@localhost.localdomain> On Mon, 2005-07-04 at 09:30 -0500, Tom 'spot' Callaway wrote: > On Sun, 2005-07-03 at 21:01 +0200, Thorsten Leemhuis wrote: > > > > 1) create the debug-pkg ourself and don't rely on the internal rpm > > > solution. > > [...] > > > If 1) is easy I'll vote for that. > > > > I tried, was not that hard (if I didn't miss anything). Results are > > found at > > http://www.leemhuis.info/files/fedorarpms/MISC.fdr/kernel-module-example/ > > in the wiki at > > http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal > > I like this approach the best. I like that too, but the dilemma with the same-NEVR'd source rpm persists. I'm not sure if it's a design goal or a design flaw, but the little (ha!) pedant in me says it's the latter. To clarify: - kernel-module-foo-1.0-1.src.rpm in repo - check out the package from CVS, build for a new kernel -> get another kernel-module-foo-1.0-1.src.rpm which != the original What to do with the new source rpm? Discarding would be ugly, and overwriting the existing srpm in the repo even uglier. Rebuilding from an existing srpm in the repo would help (or just pretending it was done, and discarding the new one :)). Allowing the source rpm's NEVR to change between rebuilds as usual and always shipping them would not have this problem at the (negligible IMHO) cost of more disk space consumption. That approach would not need any special -debuginfo treatment either. In this scenario, we'd just need to figure out how we'd like the CVS tags to be. Turning things upside down and explicitly specifying a default %{kver} assignment in specfiles when new kernels are released (+ the smp etc variants each separately) and allowing local rebuilders override it with a --define would solve that easily, with the added benefit that the build system wouldn't have to know about passing any special --defines to these builds. Whoever requests the builds would just have to be able to specify the target architecture(s). As an example, I've changed kernel-module-thinkpad in Extras CVS (devel) to do the above (currently for the UP build). Mmh, maybe I should just shut up about this now :). Does the above make any sense? > The only change is that the -debuginfo > package needs to Require: kernel-module-%{mainpkgname} (its not any good > without it). Note: -debuginfo packages created the usual way don't have that dependency. But that's probably because it could be hard to implement in the automagic that generates them nowadays. If such a dependency would be added, it should be fully versioned, though. > As to location, I'm very inclined to standardize on: > /lib/modules/%{kver}/extra/%{mainpkgname} Works for me. From ville.skytta at iki.fi Tue Jul 5 19:50:01 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 05 Jul 2005 22:50:01 +0300 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <873bqthwvl.fsf@kosh.bigo.ensc.de> References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> <20050705160130.GA28606@osiris.silug.org> <20050705162520.GA19052@jadzia.bu.edu> <1120588425.6862.90.camel@localhost.localdomain> <873bqthwvl.fsf@kosh.bigo.ensc.de> Message-ID: <1120593001.6862.152.camel@localhost.localdomain> On Tue, 2005-07-05 at 21:32 +0200, Enrico Scholz wrote: > ville.skytta at iki.fi (Ville Skytt?) writes: > > >> > In that case, there's NIS/NIS+/LDAP/whatever, and it is up to the > >> > sysadmin to do any extra work necessary to integrate the package > >> > into their environment. In the case of my openvpn package, if > >> > "useradd -r" does the right thing, then the problem is solved. If > >> > not, the sysadmin can just add an openvpn user before installing > >> > the package. > > > > Agreed on all counts. And in addition to the above, NFS4 should help in > > some specific cases too. > > Sharing does not happen only over NFS. ...which is why I said "some specific cases". From ville.skytta at iki.fi Tue Jul 5 19:58:45 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 05 Jul 2005 22:58:45 +0300 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050705185940.GA25219@jadzia.bu.edu> References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> <20050705160130.GA28606@osiris.silug.org> <20050705162520.GA19052@jadzia.bu.edu> <1120588425.6862.90.camel@localhost.localdomain> <20050705185940.GA25219@jadzia.bu.edu> Message-ID: <1120593525.6862.161.camel@localhost.localdomain> On Tue, 2005-07-05 at 14:59 -0400, Matthew Miller wrote: > On Tue, Jul 05, 2005 at 09:33:45PM +0300, Ville Skytt? wrote: > > One semi-related point: migrating existing packages in public, supported > > repositories that have not used a fixed uid mapping scheme before to use > > one is probably not going to be feasible. > > Why not? They'd just be going from some-random-id to some-random-id-which- > happens-to-be-the-same-every-time-thank-goodness. Would you change the uid of a user in a %pre scriptlet on package upgrade if it existed already? And if that succeeds, what about files that are not owned by the package, but are already on the disk elsewhere? Or would you rather let the existing username have the uid it had before the package upgrade, effectively nullifying the original goal of being able to trust that the uid will always be the same? The above are the approaches I can come up with now to deal with the migration without declaring valid existing setups broken. Even if possible in theory, the first certainly does not sound practically feasible to me, and the second one does not meet the initial goal. Did I miss something? From tcallawa at redhat.com Tue Jul 5 20:33:58 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 05 Jul 2005 15:33:58 -0500 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120592080.6862.136.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120592080.6862.136.camel@localhost.localdomain> Message-ID: <1120595638.30349.40.camel@localhost.localdomain> On Tue, 2005-07-05 at 22:34 +0300, Ville Skytt? wrote: > On Mon, 2005-07-04 at 09:30 -0500, Tom 'spot' Callaway wrote: > > On Sun, 2005-07-03 at 21:01 +0200, Thorsten Leemhuis wrote: > > > > > > 1) create the debug-pkg ourself and don't rely on the internal rpm > > > > solution. > > > [...] > > > > If 1) is easy I'll vote for that. > > > > > > I tried, was not that hard (if I didn't miss anything). Results are > > > found at > > > http://www.leemhuis.info/files/fedorarpms/MISC.fdr/kernel-module-example/ > > > in the wiki at > > > http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal > > > > I like this approach the best. > > I like that too, but the dilemma with the same-NEVR'd source rpm > persists. I'm not sure if it's a design goal or a design flaw, but the > little (ha!) pedant in me says it's the latter. To clarify: > > - kernel-module-foo-1.0-1.src.rpm in repo > - check out the package from CVS, build for a new kernel > -> get another kernel-module-foo-1.0-1.src.rpm which != the original Why would the src.rpm not be the same as the original? The spec file and source tarball should be consistent, and not affected by a rebuild. ~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 ville.skytta at iki.fi Tue Jul 5 20:47:43 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 05 Jul 2005 23:47:43 +0300 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120595638.30349.40.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120592080.6862.136.camel@localhost.localdomain> <1120595638.30349.40.camel@localhost.localdomain> Message-ID: <1120596463.6862.179.camel@localhost.localdomain> On Tue, 2005-07-05 at 15:33 -0500, Tom 'spot' Callaway wrote: > On Tue, 2005-07-05 at 22:34 +0300, Ville Skytt? wrote: > > > - kernel-module-foo-1.0-1.src.rpm in repo > > - check out the package from CVS, build for a new kernel > > -> get another kernel-module-foo-1.0-1.src.rpm which != the original > > Why would the src.rpm not be the same as the original? The spec file and > source tarball should be consistent, and not affected by a rebuild. There are variables like build host, build time, file timestamps, file modes, --define's passed to the srpm build, possibly other buildsys configuration variations etc. All of which are sort of cosmetic, but nevertheless result in a different source rpm. From tcallawa at redhat.com Tue Jul 5 21:12:28 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 05 Jul 2005 16:12:28 -0500 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120596463.6862.179.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120592080.6862.136.camel@localhost.localdomain> <1120595638.30349.40.camel@localhost.localdomain> <1120596463.6862.179.camel@localhost.localdomain> Message-ID: <1120597948.30349.48.camel@localhost.localdomain> On Tue, 2005-07-05 at 23:47 +0300, Ville Skytt? wrote: > On Tue, 2005-07-05 at 15:33 -0500, Tom 'spot' Callaway wrote: > > On Tue, 2005-07-05 at 22:34 +0300, Ville Skytt? wrote: > > > > > - kernel-module-foo-1.0-1.src.rpm in repo > > > - check out the package from CVS, build for a new kernel > > > -> get another kernel-module-foo-1.0-1.src.rpm which != the original > > > > Why would the src.rpm not be the same as the original? The spec file and > > source tarball should be consistent, and not affected by a rebuild. > > There are variables like build host, build time, file timestamps, file > modes, --define's passed to the srpm build, possibly other buildsys > configuration variations etc. All of which are sort of cosmetic, but > nevertheless result in a different source rpm. I'm really not worried about cosmetic changes. None of these things should affect the binary packages generated from that src.rpm. ~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 mattdm at mattdm.org Wed Jul 6 02:38:05 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 5 Jul 2005 22:38:05 -0400 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120596463.6862.179.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120592080.6862.136.camel@localhost.localdomain> <1120595638.30349.40.camel@localhost.localdomain> <1120596463.6862.179.camel@localhost.localdomain> Message-ID: <20050706023804.GA3518@jadzia.bu.edu> On Tue, Jul 05, 2005 at 11:47:43PM +0300, Ville Skytt? wrote: > There are variables like build host, build time, file timestamps, file > modes, --define's passed to the srpm build, possibly other buildsys > configuration variations etc. All of which are sort of cosmetic, but > nevertheless result in a different source rpm. This is really no worse than what we've already got. From the FC4 src rpms: $ rpm -qp --qf '%{arch}\n' *.src.rpm --nodigest --nosignature|sort|uniq i386 ia64 noarch ppc ppc64 ppc64iseries x86_64 -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From mattdm at mattdm.org Wed Jul 6 02:40:27 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 5 Jul 2005 22:40:27 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1120593525.6862.161.camel@localhost.localdomain> References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> <20050705160130.GA28606@osiris.silug.org> <20050705162520.GA19052@jadzia.bu.edu> <1120588425.6862.90.camel@localhost.localdomain> <20050705185940.GA25219@jadzia.bu.edu> <1120593525.6862.161.camel@localhost.localdomain> Message-ID: <20050706024027.GB3518@jadzia.bu.edu> On Tue, Jul 05, 2005 at 10:58:45PM +0300, Ville Skytt? wrote: > Or would you rather let the existing username have the uid it had before > the package upgrade, effectively nullifying the original goal of being > able to trust that the uid will always be the same? I'd be happy enough with being able to trust that it'll always be the same on new installs. The older systems can be migrated as time/energy/inclination permits. I don't see any reason to block improving the situation just because there's currently a mess. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From ville.skytta at iki.fi Wed Jul 6 07:00:02 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 06 Jul 2005 10:00:02 +0300 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120597948.30349.48.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120592080.6862.136.camel@localhost.localdomain> <1120595638.30349.40.camel@localhost.localdomain> <1120596463.6862.179.camel@localhost.localdomain> <1120597948.30349.48.camel@localhost.localdomain> Message-ID: <1120633202.6862.226.camel@localhost.localdomain> On Tue, 2005-07-05 at 16:12 -0500, Tom 'spot' Callaway wrote: > On Tue, 2005-07-05 at 23:47 +0300, Ville Skytt? wrote: > > > > There are variables like build host, build time, file timestamps, file > > modes, --define's passed to the srpm build, possibly other buildsys > > configuration variations etc. All of which are sort of cosmetic, but > > nevertheless result in a different source rpm. > > I'm really not worried about cosmetic changes. None of these things > should affect the binary packages generated from that src.rpm. --defines end up in various dependencies of the source rpm, which does not matter as long as one doesn't use its dependencies for anything, but the specfile's instead. (This is not limited to these packages.) The original question remains though; what to do with the srpms? Discard or overwrite the ones already in the repo? My +1 to the former, or more generally: never overwrite any package in the repository. From Christian.Iseli at licr.org Wed Jul 6 08:49:07 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 06 Jul 2005 10:49:07 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: Your message of "Tue, 05 Jul 2005 14:07:32 +0200." <20050705140732.7363d257@python2> Message-ID: <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net said: > That's the point : Fixed uid/gid is often a good thing, I have many setups > where a bunch of redundant servers access the same nfs share, and I'm in > trouble when I install packages on those servers which create a user with a > non fixed uid, and one gets say 201 and the other 202... > I'm really grateful to know I can expect apache to be uid 48 everywhere, for > instance. I think there are two cases: standalone machines, and machines that share data. For standalone machines, the only trouble is when they are re-installed or upgraded. If the old passwd file can still be read, the problem is easy to solve: just reuse the old UIDs. When the old passwd file is damaged: you are in trouble anyway: the user probably created a few accounts which contain files, and those accounts will need to be hand-recreated with the proper UID anyway... Having fixed UIDs helps some, but not that much. For machines that share data, IMHO the proper way is to put all accounts with distributed files in a UID management thing like LDAP or NIS. It doesn't buy you much that a few of those UIDs are fixed. Plus, people running such setups are supposed to be pretty knowledgeable about managing a local UID database. I'm still of the opinion that fixed UIDs don't solve much, and are not easy to manage. In a way, it seems things might be a bit simpler if a username->UID mapping was stored somewhere in the filesystem, at mount/fsck/umount time... Ah well, just daydreaming I guess :) Cheers, Christian From mattdm at mattdm.org Wed Jul 6 11:31:56 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 6 Jul 2005 07:31:56 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> Message-ID: <20050706113156.GA14829@jadzia.bu.edu> On Wed, Jul 06, 2005 at 10:49:07AM +0200, Christian.Iseli at licr.org wrote: > For standalone machines, the only trouble is when they are re-installed or > upgraded. If the old passwd file can still be read, the problem is easy to > solve: just reuse the old UIDs. When the old passwd file is damaged: you are > in trouble anyway: the user probably created a few accounts which contain > files, and those accounts will need to be hand-recreated with the proper UID > anyway... Having fixed UIDs helps some, but not that much. I often upgrade by preserving /home and a few key config files but wiping the system disk. Much faster than the anaconda upgrade option, with cleaner results. But if I do that, and the UIDs used by packages at install time change, there will be mis-owned files on the system. > For machines that share data, IMHO the proper way is to put all accounts > with distributed files in a UID management thing like LDAP or NIS. It As previously mentioned, that's not the right thing for system accounts. For example, it doesn't help the above situation. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From Christian.Iseli at licr.org Wed Jul 6 12:13:59 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 06 Jul 2005 14:13:59 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: Your message of "Wed, 06 Jul 2005 07:31:56 EDT." <20050706113156.GA14829@jadzia.bu.edu> Message-ID: <200507061213.j66CDxuT014475@ludwig-alpha.unil.ch> mattdm at mattdm.org said: > I often upgrade by preserving /home and a few key config files but wiping the > system disk. Much faster than the anaconda upgrade option, with cleaner > results. But if I do that, and the UIDs used by packages at install time > change, there will be mis-owned files on the system. Why is /etc/passwd not included in your "and a few key config files" ? I'm not saying the current situation is ideal. I'm saying I'd rather have anaconda preserve existing system account UIDs and/or use those from the local LDAP/NIS/whatever, than a centralized fixed UIDs assignation... Christian From nicolas.mailhot at laposte.net Wed Jul 6 12:33:00 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 6 Jul 2005 14:33:00 +0200 (CEST) Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050705183222.GA32528@osiris.silug.org> References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> <20050705160130.GA28606@osiris.silug.org> <87fyuti2cn.fsf@kosh.bigo.ensc.de> <20050705183222.GA32528@osiris.silug.org> Message-ID: <56750.192.54.193.35.1120653180.squirrel@rousalka.dyndns.org> On Mar 5 juillet 2005 20:32, Steven Pritchard wrote: > On Tue, Jul 05, 2005 at 07:34:16PM +0200, Enrico Scholz wrote: >> System users should be in /etc/passwd because the requirements for >> NIS/LDAP/whatever might not be fulfilled for early services; >> e.g. openvpn will be executed before the ldap service so the 'openvpn' >> user might not be resolveable at this time. >> >> LDAP/NIS might be unwanted in certain environments also (e.g. on >> firewalls, portable machines). > > And those systems don't need to share files owned by system users, so > it is a non-issue. Those systems can share files owned by system users via backups, which may or may not require fixed UIDs to work, so they need it like everyone else. The root mistake IMHO was exposing UIDs and GIDs to userspace, had they been hidden from the start like inodes we would not have all those problems today. But since they are exposed they need to be kept consistent like other stuff. Regards, -- Nicolas Mailhot From tcallawa at redhat.com Wed Jul 6 13:24:46 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 06 Jul 2005 08:24:46 -0500 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120633202.6862.226.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120592080.6862.136.camel@localhost.localdomain> <1120595638.30349.40.camel@localhost.localdomain> <1120596463.6862.179.camel@localhost.localdomain> <1120597948.30349.48.camel@localhost.localdomain> <1120633202.6862.226.camel@localhost.localdomain> Message-ID: <1120656286.30349.91.camel@localhost.localdomain> On Wed, 2005-07-06 at 10:00 +0300, Ville Skytt? wrote: > On Tue, 2005-07-05 at 16:12 -0500, Tom 'spot' Callaway wrote: > > On Tue, 2005-07-05 at 23:47 +0300, Ville Skytt? wrote: > > > > > > There are variables like build host, build time, file timestamps, file > > > modes, --define's passed to the srpm build, possibly other buildsys > > > configuration variations etc. All of which are sort of cosmetic, but > > > nevertheless result in a different source rpm. > > > > I'm really not worried about cosmetic changes. None of these things > > should affect the binary packages generated from that src.rpm. > > --defines end up in various dependencies of the source rpm, which does > not matter as long as one doesn't use its dependencies for anything, but > the specfile's instead. (This is not limited to these packages.) > > The original question remains though; what to do with the srpms? > Discard or overwrite the ones already in the repo? My +1 to the former, > or more generally: never overwrite any package in the repository. Personally, since the buildsystem is going to have to treat kernel-module-* packages differently, I'd like to see it build them like this: When a make build is done in kernel-module-foo/FC-3/, the buildsystem assembles the sources and makes a SRPM. It then looks at a list (either generated at buildtime, or preexistant) of the released kernels for FC-3, and iterates through each of them, running rpmbuild --rebuild --define "kver $VERSION". At the end of the loop, we should have all the binary packages and a single SRPM. ~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 jjneely at pams.ncsu.edu Wed Jul 6 13:59:02 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Wed, 6 Jul 2005 09:59:02 -0400 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120656286.30349.91.camel@localhost.localdomain> References: <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120592080.6862.136.camel@localhost.localdomain> <1120595638.30349.40.camel@localhost.localdomain> <1120596463.6862.179.camel@localhost.localdomain> <1120597948.30349.48.camel@localhost.localdomain> <1120633202.6862.226.camel@localhost.localdomain> <1120656286.30349.91.camel@localhost.localdomain> Message-ID: <20050706135902.GO1972@anduril.pams.ncsu.edu> On Wed, Jul 06, 2005 at 08:24:46AM -0500, Tom 'spot' Callaway wrote: > On Wed, 2005-07-06 at 10:00 +0300, Ville Skytt? wrote: > > On Tue, 2005-07-05 at 16:12 -0500, Tom 'spot' Callaway wrote: > > > On Tue, 2005-07-05 at 23:47 +0300, Ville Skytt? wrote: > > > > > > > > There are variables like build host, build time, file timestamps, file > > > > modes, --define's passed to the srpm build, possibly other buildsys > > > > configuration variations etc. All of which are sort of cosmetic, but > > > > nevertheless result in a different source rpm. > > > > > > I'm really not worried about cosmetic changes. None of these things > > > should affect the binary packages generated from that src.rpm. > > > > --defines end up in various dependencies of the source rpm, which does > > not matter as long as one doesn't use its dependencies for anything, but > > the specfile's instead. (This is not limited to these packages.) > > > > The original question remains though; what to do with the srpms? > > Discard or overwrite the ones already in the repo? My +1 to the former, > > or more generally: never overwrite any package in the repository. > > Personally, since the buildsystem is going to have to treat > kernel-module-* packages differently, I'd like to see it build them like > this: > > When a make build is done in kernel-module-foo/FC-3/, the buildsystem > assembles the sources and makes a SRPM. It then looks at a list (either > generated at buildtime, or preexistant) of the released kernels for > FC-3, and iterates through each of them, running rpmbuild --rebuild > --define "kver $VERSION". At the end of the loop, we should have all the > binary packages and a single SRPM. > > ~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! > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging +1 -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From tcallawa at redhat.com Wed Jul 6 14:39:41 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 06 Jul 2005 09:39:41 -0500 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <20050706135902.GO1972@anduril.pams.ncsu.edu> References: <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120592080.6862.136.camel@localhost.localdomain> <1120595638.30349.40.camel@localhost.localdomain> <1120596463.6862.179.camel@localhost.localdomain> <1120597948.30349.48.camel@localhost.localdomain> <1120633202.6862.226.camel@localhost.localdomain> <1120656286.30349.91.camel@localhost.localdomain> <20050706135902.GO1972@anduril.pams.ncsu.edu> Message-ID: <1120660781.30349.122.camel@localhost.localdomain> > > Personally, since the buildsystem is going to have to treat > > kernel-module-* packages differently, I'd like to see it build them like > > this: > > > > When a make build is done in kernel-module-foo/FC-3/, the buildsystem > > assembles the sources and makes a SRPM. It then looks at a list (either > > generated at buildtime, or preexistant) of the released kernels for > > FC-3, and iterates through each of them, running rpmbuild --rebuild > > --define "kver $VERSION". At the end of the loop, we should have all the > > binary packages and a single SRPM. Also, if possible, it would be awesome if the buildsystem could automatically do a build when a new kernel goes into FC (for that kernel only). Barring that, it would be nice if there was some way for kernel-module-* maintainers to be notified of the new kernel update in advance. ~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 ville.skytta at iki.fi Wed Jul 6 15:16:52 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 06 Jul 2005 18:16:52 +0300 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120660781.30349.122.camel@localhost.localdomain> References: <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120592080.6862.136.camel@localhost.localdomain> <1120595638.30349.40.camel@localhost.localdomain> <1120596463.6862.179.camel@localhost.localdomain> <1120597948.30349.48.camel@localhost.localdomain> <1120633202.6862.226.camel@localhost.localdomain> <1120656286.30349.91.camel@localhost.localdomain> <20050706135902.GO1972@anduril.pams.ncsu.edu> <1120660781.30349.122.camel@localhost.localdomain> Message-ID: <1120663012.6862.273.camel@localhost.localdomain> On Wed, 2005-07-06 at 09:39 -0500, Tom 'spot' Callaway wrote: > > > Personally, since the buildsystem is going to have to treat > > > kernel-module-* packages differently, I'd like to see it build them like > > > this: > > > > > > When a make build is done in kernel-module-foo/FC-3/, the buildsystem > > > assembles the sources and makes a SRPM. It then looks at a list (either > > > generated at buildtime, or preexistant) of the released kernels for > > > FC-3, and iterates through each of them, running rpmbuild --rebuild > > > --define "kver $VERSION". At the end of the loop, we should have all the > > > binary packages and a single SRPM. That still doesn't answer the question, so at the risk of parroting, I'm going to try once again because I don't know if people understand the question and the problem: Yes, it's a single SRPM resulting from _that_ build. It's very likely that there would be another one with the same NEVR from an earlier build sitting in the repository already. More clarification: - in the beginning, we have only kernel X - rebuild a kernel-module-foo package for it, results: - k-m-foo-1.0-1.src.rpm - k-m-foo-1.0-1.X...rpm (all smp, xen0 etc variants and archs) - the above get pushed to the repository - then, kernel Y is released, rebuild k-m-foo (which has had no changes in the meantime) for it, results: - k-m-foo-1.0-1.src.rpm - k-m-foo-1.0-1.Y...rpm (all smp, xen0 etc variants and archs) Do we discard the new k-m-foo-1.0-1.src.rpm or overwrite the one which is already in the repository? Or do we solve this with a policy (assuming the process you described above would be implemented): "always bump the release of the "main" package of a module package before building it for a new kernel"? That'd result in only one srpm per module package per released kernel "family". > Also, if possible, it would be awesome if the buildsystem could > automatically do a build when a new kernel goes into FC (for that kernel > only). Barring that, it would be nice if there was some way for > kernel-module-* maintainers to be notified of the new kernel update in > advance. Sure. But I'm becoming worried about this discussion already placing requirements on the build system, which will delay our ability to ship any module packages even further. We could start with something much simpler; several suggestions have already been outlined in this thread. The day "make build" would allow specifying the arch, we could start building and shipping the packages, and could improve the process incrementally. From tcallawa at redhat.com Wed Jul 6 15:28:32 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 06 Jul 2005 10:28:32 -0500 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120663012.6862.273.camel@localhost.localdomain> References: <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120592080.6862.136.camel@localhost.localdomain> <1120595638.30349.40.camel@localhost.localdomain> <1120596463.6862.179.camel@localhost.localdomain> <1120597948.30349.48.camel@localhost.localdomain> <1120633202.6862.226.camel@localhost.localdomain> <1120656286.30349.91.camel@localhost.localdomain> <20050706135902.GO1972@anduril.pams.ncsu.edu> <1120660781.30349.122.camel@localhost.localdomain> <1120663012.6862.273.camel@localhost.localdomain> Message-ID: <1120663712.30349.143.camel@localhost.localdomain> On Wed, 2005-07-06 at 18:16 +0300, Ville Skytt? wrote: > - in the beginning, we have only kernel X > - rebuild a kernel-module-foo package for it, results: > - k-m-foo-1.0-1.src.rpm > - k-m-foo-1.0-1.X...rpm (all smp, xen0 etc variants and archs) > - the above get pushed to the repository > - then, kernel Y is released, rebuild k-m-foo (which has had no changes > in the meantime) for it, results: > - k-m-foo-1.0-1.src.rpm > - k-m-foo-1.0-1.Y...rpm (all smp, xen0 etc variants and archs) > > Do we discard the new k-m-foo-1.0-1.src.rpm or overwrite the one which > is already in the repository? I vote we discard the new one. > Or do we solve this with a policy (assuming the process you described > above would be implemented): "always bump the release of the "main" > package of a module package before building it for a new kernel"? > That'd result in only one srpm per module package per released kernel > "family". It would also result in unnecessary package upgrades. > > Also, if possible, it would be awesome if the buildsystem could > > automatically do a build when a new kernel goes into FC (for that kernel > > only). Barring that, it would be nice if there was some way for > > kernel-module-* maintainers to be notified of the new kernel update in > > advance. > > Sure. But I'm becoming worried about this discussion already placing > requirements on the build system, which will delay our ability to ship > any module packages even further. We could start with something much > simpler; several suggestions have already been outlined in this thread. > The day "make build" would allow specifying the arch, we could start > building and shipping the packages, and could improve the process > incrementally. The build system has other issues. Right now, I don't think it can deal with ExclusiveArch correctly. If it did, then we could just have "make build" parse ExclusiveArch for kernel-module packages, and build for all those arches. I've CC'd seth and dan to see what they say. ~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 mpeters at mac.com Wed Jul 6 18:16:22 2005 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 06 Jul 2005 11:16:22 -0700 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050704165410.GA5937@jadzia.bu.edu> References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> <20050704165410.GA5937@jadzia.bu.edu> Message-ID: <1120673783.2744.5.camel@locolhost.localdomain> On Mon, 2005-07-04 at 12:54 -0400, Matthew Miller wrote: > On Mon, Jul 04, 2005 at 06:31:42PM +0200, Christian.Iseli at licr.org wrote: > > mattdm at mattdm.org said: > > > And that we should have a registry of standard fixed UIDs within that range, > > > right? > > That's the part I don't understand: why a global registry ? > > So that multiple systems have the same ids. Or so that if you do a > reinstall, your files have the same owners. I save my /etc/passwd file for reinstall. For multiple machines where identical UID/GID is needed - you generally should not be relying on local /etc/passwd. If you have a laptop that needs to share UID/GID - then you manually set up the /etc/passwd and /etc/group for that laptop. A system administrator on a network where keeping UID/GID in sync is important should know how to do it w/o Fedora needing to specify a registry of unames and groups. Follow the FHS - below 100 reserved for vendor, 100-499 for system accounts not specified by vendor, 500 and above for user accounts. That works now, and no registry (which needs maintenance) is needed. From Nicolas.Mailhot at laPoste.net Wed Jul 6 18:32:15 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 06 Jul 2005 20:32:15 +0200 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1120673783.2744.5.camel@locolhost.localdomain> References: <20050704161722.GA4976@jadzia.bu.edu> <200507041631.j64GVg0a005743@ludwig-alpha.unil.ch> <20050704165410.GA5937@jadzia.bu.edu> <1120673783.2744.5.camel@locolhost.localdomain> Message-ID: <1120674736.18405.14.camel@rousalka.dyndns.org> Le mercredi 06 juillet 2005 ? 11:16 -0700, Michael A. Peters a ?crit : > Follow the FHS - below 100 reserved for vendor, 100-499 for system > accounts not specified by vendor, 500 and above for user accounts. > > That works now, and no registry (which needs maintenance) is needed. That does not work at all now. 100 numbers is way too little for vendor. A big reasons UIDs are not the same across distros for example is they need to manage this sparse resource, so they can not preallocate an UID when it's used in another distro - they have to reserve this space to the main products they ship. Even if after a few years the same product is adopted by everyone, each distro will by then have reallocated a different hole in its 100 range to it. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Wed Jul 6 18:48:01 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 06 Jul 2005 21:48:01 +0300 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120663712.30349.143.camel@localhost.localdomain> References: <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120592080.6862.136.camel@localhost.localdomain> <1120595638.30349.40.camel@localhost.localdomain> <1120596463.6862.179.camel@localhost.localdomain> <1120597948.30349.48.camel@localhost.localdomain> <1120633202.6862.226.camel@localhost.localdomain> <1120656286.30349.91.camel@localhost.localdomain> <20050706135902.GO1972@anduril.pams.ncsu.edu> <1120660781.30349.122.camel@localhost.localdomain> <1120663012.6862.273.camel@localhost.localdomain> <1120663712.30349.143.camel@localhost.localdomain> Message-ID: <1120675681.6862.323.camel@localhost.localdomain> On Wed, 2005-07-06 at 10:28 -0500, Tom 'spot' Callaway wrote: > On Wed, 2005-07-06 at 18:16 +0300, Ville Skytt? wrote: > > > Or do we solve this with a policy (assuming the process you described > > above would be implemented): "always bump the release of the "main" > > package of a module package before building it for a new kernel"? > > That'd result in only one srpm per module package per released kernel > > "family". > > It would also result in unnecessary package upgrades. How so? We wouldn't be building the module package again for older kernels unless there are some real changes in it. To illustrate (leaving "tr - _" needed for the release tag aside for a moment): kernel-%{kver1} # eg. kver1 = 2.6.11-1.1369_FC4 k-m-foo-1.0-1.%{kver1} kernel-%{kver2} # eg. kver2 = 2.6.12-1.1387_FC4 k-m-foo-1.0-1.%{kver2} In the above, k-m-foo-1.0-1.%{kver2} must not upgrade k-m-foo-1.0-1.%{kver1} in the usual sense anyway, instead they both need to be installed. So this needs to be special cased in depsolvers, and bumping the first digit of the release tag of k-m-foo when built for kernel %{kver2} should not have any effect on the special case. Also note that a side effect of stuffing %{kver} into the release (or version) tag means that we might be in for surprises if we trust rpm's version comparison algorithm to sort the "same" module packages for different kernels consistently with the corresponding kernel versions. For example: Version: 1.0 Release: 1.2.6.12_1.1234 Version: 1.0 Release: 1.2.6.12.1_1.2345 The former is newer as far as rpm is concerned, it compares "1234" in the former against "1" in the latter. If the kernel packages' version number always has the same number of "segments" (currently 3), and its Epoch is never bumped, the inconsistency would never occur though. From tcallawa at redhat.com Wed Jul 6 20:00:50 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 06 Jul 2005 15:00:50 -0500 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120675681.6862.323.camel@localhost.localdomain> References: <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120592080.6862.136.camel@localhost.localdomain> <1120595638.30349.40.camel@localhost.localdomain> <1120596463.6862.179.camel@localhost.localdomain> <1120597948.30349.48.camel@localhost.localdomain> <1120633202.6862.226.camel@localhost.localdomain> <1120656286.30349.91.camel@localhost.localdomain> <20050706135902.GO1972@anduril.pams.ncsu.edu> <1120660781.30349.122.camel@localhost.localdomain> <1120663012.6862.273.camel@localhost.localdomain> <1120663712.30349.143.camel@localhost.localdomain> <1120675681.6862.323.camel@localhost.localdomain> Message-ID: <1120680050.9303.2.camel@localhost.localdomain> On Wed, 2005-07-06 at 21:48 +0300, Ville Skytt? wrote: > On Wed, 2005-07-06 at 10:28 -0500, Tom 'spot' Callaway wrote: > > On Wed, 2005-07-06 at 18:16 +0300, Ville Skytt? wrote: > > > > > Or do we solve this with a policy (assuming the process you described > > > above would be implemented): "always bump the release of the "main" > > > package of a module package before building it for a new kernel"? > > > That'd result in only one srpm per module package per released kernel > > > "family". > > > > It would also result in unnecessary package upgrades. > > How so? We wouldn't be building the module package again for older > kernels unless there are some real changes in it. To illustrate > (leaving "tr - _" needed for the release tag aside for a moment): The buildsystem has no way of knowing this, nor do users. The only reasonable way is to rebuild for all existant kernels when we increment release. This means that if a new kernel comes out, all my old kernels get new kernel-module-foo packages downloaded and installed, when all i needed was a kernel-module-foo for my new kernel. ~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 ville.skytta at iki.fi Wed Jul 6 20:51:30 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 06 Jul 2005 23:51:30 +0300 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120680050.9303.2.camel@localhost.localdomain> References: <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120592080.6862.136.camel@localhost.localdomain> <1120595638.30349.40.camel@localhost.localdomain> <1120596463.6862.179.camel@localhost.localdomain> <1120597948.30349.48.camel@localhost.localdomain> <1120633202.6862.226.camel@localhost.localdomain> <1120656286.30349.91.camel@localhost.localdomain> <20050706135902.GO1972@anduril.pams.ncsu.edu> <1120660781.30349.122.camel@localhost.localdomain> <1120663012.6862.273.camel@localhost.localdomain> <1120663712.30349.143.camel@localhost.localdomain> <1120675681.6862.323.camel@localhost.localdomain> <1120680050.9303.2.camel@localhost.localdomain> Message-ID: <1120683090.6862.421.camel@localhost.localdomain> On Wed, 2005-07-06 at 15:00 -0500, Tom 'spot' Callaway wrote: > On Wed, 2005-07-06 at 21:48 +0300, Ville Skytt? wrote: > > > > How so? We wouldn't be building the module package again for older > > kernels unless there are some real changes in it. To illustrate > > (leaving "tr - _" needed for the release tag aside for a moment): > > The buildsystem has no way of knowing this, nor do users. The only > reasonable way is to rebuild for all existant kernels when we increment > release. Well, we obviously disagree here, as well as on a number of other issues in this thread. But it seems I got my concerns across, so I'll happily switch back to the "waits patiently" mode now. From mpeters at mac.com Thu Jul 7 00:40:20 2005 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 06 Jul 2005 17:40:20 -0700 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050706113156.GA14829@jadzia.bu.edu> References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> Message-ID: <1120696820.2744.26.camel@locolhost.localdomain> On Wed, 2005-07-06 at 07:31 -0400, Matthew Miller wrote: > > I often upgrade by preserving /home and a few key config files but wiping > the system disk. Much faster than the anaconda upgrade option, with cleaner > results. But if I do that, and the UIDs used by packages at install time > change, there will be mis-owned files on the system. A system service should NOT have a home directory in /home so all of the UIG/GID in /home should be above 500. > > > > For machines that share data, IMHO the proper way is to put all accounts > > with distributed files in a UID management thing like LDAP or NIS. It > > As previously mentioned, that's not the right thing for system accounts. For > example, it doesn't help the above situation. system accounts should not have home directories in /home anyway. If someone packages a fedora or extras package that uses a system account and has a directory in /home that is a packaging bug. But really - just like you need to preserve your ssl keys, a sysadmin should preserve /etc/passwd and /etc/group. I never personally save /etc/shadow - I just use the saved /etc/passwd to recreate users keeping uid/gid the same. From mattdm at mattdm.org Thu Jul 7 00:52:59 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 6 Jul 2005 20:52:59 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1120696820.2744.26.camel@locolhost.localdomain> References: <20050705140732.7363d257@python2> <200507060849.j668n8f3013631@ludwig-alpha.unil.ch> <20050706113156.GA14829@jadzia.bu.edu> <1120696820.2744.26.camel@locolhost.localdomain> Message-ID: <20050707005259.GA14794@jadzia.bu.edu> On Wed, Jul 06, 2005 at 05:40:20PM -0700, Michael A. Peters wrote: > > I often upgrade by preserving /home and a few key config files but wiping > > the system disk. Much faster than the anaconda upgrade option, with cleaner > > results. But if I do that, and the UIDs used by packages at install time > > change, there will be mis-owned files on the system. > A system service should NOT have a home directory in /home so all of the > UIG/GID in /home should be above 500. That's irrelevant. If it creates files in (say) /var as whatever user it picks at random, and then I copy my old password file over the new one, it will be All Br0ke. (And that's not even considering the annoyance of dealing with any *new* system users.) [...] > system accounts should not have home directories in /home anyway. I have no idea why you're all on about /home. > But really - just like you need to preserve your ssl keys, a sysadmin > should preserve /etc/passwd and /etc/group. I never personally > save /etc/shadow - I just use the saved /etc/passwd to recreate users > keeping uid/gid the same. See above. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From mpeters at mac.com Thu Jul 7 02:17:43 2005 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 06 Jul 2005 19:17:43 -0700 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050707005259.GA14794@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> Message-ID: <1120702663.2744.40.camel@locolhost.localdomain> On Wed, 2005-07-06 at 20:52 -0400, Matthew Miller wrote: > > I have no idea why you're all on about /home. Because you described the same process I use - /home is its own partition, I don't do upgrades - I do clean installs formatting / but not formatting /home. Then after firstboot - I add my user accounts, and yum install anything from extras/livna. No uid/gid problems. If there is other data I need to preserve that are not already owned by core, I can add those uid/gid's from my saved passwd and group files so that the same uid/gid is used. There is thus no conflict - no need to reserve an extra range of uid/gid for extras (or any other repository). As long as the package adds its user as a system account or is already present from previous /etc/passwd file - there are no conflicts, none. If the rpm doesn't add the user as a system user - then there is a bug in the packaging. non core packages that depend on a particular user/group really should add that user itself - that way you can use a macro do define where its home directory is (if needed) and if it adds the user/group itself, with the -r switch, it won't conflict with anything else. Sure - it may be a different uid/gid on my machine than yours - but so what? That's only an issue if we are on the same network, in which case the network admin should decide what uid/gid is used. I guess what I'm trying to say is I don't see a problem with the way it is currently done, nor do I see how a registry of uid/gid's solves anything. From mattdm at mattdm.org Thu Jul 7 03:02:13 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 6 Jul 2005 23:02:13 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <1120702663.2744.40.camel@locolhost.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> Message-ID: <20050707030213.GA19518@jadzia.bu.edu> On Wed, Jul 06, 2005 at 07:17:43PM -0700, Michael A. Peters wrote: > There is thus no conflict - no need to reserve an extra range of uid/gid > for extras (or any other repository). As long as the package adds its > user as a system account or is already present from previous /etc/passwd > file - there are no conflicts, none. If the rpm doesn't add the user as > a system user - then there is a bug in the packaging. let's say you have server-program-foo, and server-program-bar. On your first install, server-program-foo got installed first and created user "serverfoo" as uid 101, and server-program-bar created "serverbar" with uid 102. Now, on the second install, for arcane RPM transaction ordering reasons, server-program-bar gets installed first -- and gets stuff owned by new user "serverbar" uid 101. Now, when you put your password file back, uid 101 reverts to "serverfoo", all of the files are owned by the wrong user. You may not even notice it until something breaks, but it ain't right. (And that's not even considering that you accidentally wiped out the new user created by server-program-baz, which requires a separate user account in the new version and you didn't notice before copying your passwd file on top of the new one.) > I guess what I'm trying to say is I don't see a problem with the way it > is currently done, nor do I see how a registry of uid/gid's solves > anything. It solves the above problem, and *also* issues with backup, with networked filesystems, and more. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From jjneely at pams.ncsu.edu Thu Jul 7 03:52:01 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Wed, 6 Jul 2005 23:52:01 -0400 Subject: [Fedora-packaging] OpenAFS kernel-module package Message-ID: <20050707035201.GT1972@anduril.pams.ncsu.edu> Folks, I've whipped up some new OpenAFS packages based on some of what we have discussed and proposed regarding kernel module packages. I'm kinda suprised that Matthew hasn't beaten me to it. :-) These are a rough first attempt. I have left out the debuginfo package stuffs for a future exercise. But I invite folks to comment on them. I'll probably be working on fine tuning these tomorrow during work. After working on this for a few hours I have come to the conclusion that the method of doing kernel-module-foo-source packages is very complex. I'm a big fan of having most of the smarts be in Yum and in this case the build system rather than depend on complex magic from the packager. But I do understand the issues of having multiple similar/same SRPMS, debuginfo packages etc. What's the worst evil? *shrug* SRPMS: http://anduril.pams.ncsu.edu/~slack/SRPMS/kernel-module-openafs-source-1.3.84-6.src.rpm http://anduril.pams.ncsu.edu/~slack/SRPMS/openafs-1.3.84-6.src.rpm SPECS: http://anduril.pams.ncsu.edu/~slack/SPECS/kernel-module-openafs-source.spec http://anduril.pams.ncsu.edu/~slack/SPECS/openafs.spec Jack Neely -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From mattdm at mattdm.org Thu Jul 7 03:53:00 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 6 Jul 2005 23:53:00 -0400 Subject: [Fedora-packaging] packages which add user accounts: is fedora-usermgmt the way? In-Reply-To: <20050707030213.GA19518@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> Message-ID: <20050707035300.GA21070@jadzia.bu.edu> > It solves the above problem, and *also* issues with backup, with networked > filesystems, and more. It's come to my attention that I've spent way too much energy on this thread. I think I've made my point; I'll shut up now. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From fedora at leemhuis.info Wed Jul 6 16:53:23 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 06 Jul 2005 18:53:23 +0200 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120487453.27103.79.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> Message-ID: <1120668803.3108.15.camel@localhost.localdomain> Am Montag, den 04.07.2005, 09:30 -0500 schrieb Tom 'spot' Callaway: > On Sun, 2005-07-03 at 21:01 +0200, Thorsten Leemhuis wrote: > > > > 1) create the debug-pkg ourself and don't rely on the internal rpm > > > solution. > > [...] > > > If 1) is easy I'll vote for that. > > > > I tried, was not that hard (if I didn't miss anything). Results are > > found at > > http://www.leemhuis.info/files/fedorarpms/MISC.fdr/kernel-module-example/ > > in the wiki at > > http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal > > I like this approach the best. :) > The only change is that the -debuginfo > package needs to Require: kernel-module-%{mainpkgname} (its not any good > without it). Done, with V-R > As to location, I'm very inclined to standardize on: > /lib/modules/%{kver}/extra/%{mainpkgname} I changed it -- but I still would prefer the directory used by upstream. Just a note: "extra =! extras" so other 3rd party repos probably could and should use this also. I'll update the Wiki and the example found on my homepage when I have online-access the next time. -- Thorsten Leemhuis From mattdm at mattdm.org Thu Jul 7 12:34:35 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 7 Jul 2005 08:34:35 -0400 Subject: [Fedora-packaging] OpenAFS kernel-module package In-Reply-To: <20050707035201.GT1972@anduril.pams.ncsu.edu> References: <20050707035201.GT1972@anduril.pams.ncsu.edu> Message-ID: <20050707123435.GA545@jadzia.bu.edu> On Wed, Jul 06, 2005 at 11:52:01PM -0400, Jack Neely wrote: > I've whipped up some new OpenAFS packages based on some of what we have > discussed and proposed regarding kernel module packages. I'm kinda > suprised that Matthew hasn't beaten me to it. :-) Yeah, I was foolishly waiting for things to settle down. :) Honestly, I'm glad someone else is working on this -- I'm glad to help, but OpenAFS is too big and complicated to depend on just one maintainer. I'll take a look at what you've got ... should the rest of this discussion be moved to the Fedora Extras list? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From jjneely at pams.ncsu.edu Thu Jul 7 14:24:20 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Thu, 7 Jul 2005 10:24:20 -0400 Subject: [Fedora-packaging] OpenAFS kernel-module package In-Reply-To: <20050707123435.GA545@jadzia.bu.edu> References: <20050707035201.GT1972@anduril.pams.ncsu.edu> <20050707123435.GA545@jadzia.bu.edu> Message-ID: <20050707142419.GU1972@anduril.pams.ncsu.edu> On Thu, Jul 07, 2005 at 08:34:35AM -0400, Matthew Miller wrote: > On Wed, Jul 06, 2005 at 11:52:01PM -0400, Jack Neely wrote: > > I've whipped up some new OpenAFS packages based on some of what we have > > discussed and proposed regarding kernel module packages. I'm kinda > > suprised that Matthew hasn't beaten me to it. :-) > > Yeah, I was foolishly waiting for things to settle down. :) Nonsense!! > > Honestly, I'm glad someone else is working on this -- I'm glad to help, but > OpenAFS is too big and complicated to depend on just one maintainer. > We've had similar but seprate packages for a long time now. All about finding something that works for both of us well. > I'll take a look at what you've got ... should the rest of this discussion > be moved to the Fedora Extras list? > I don't know. Yum isn't ready to handle kernel modules yet. My patch wont be in 2.3.4 and there more patches that need writing to deal with "I need to install kernel-module-openafs now what VRs do I install?" The hard ones. Since OpenAFS seems to be the common case to a lot of folks, and isn't trivial to package...might as well let folks have a look. :-) Jack -- Jack Neely Realm Linux Administration and Development 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 Jul 7 15:05:24 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 07 Jul 2005 11:05:24 -0400 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120663712.30349.143.camel@localhost.localdomain> References: <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120592080.6862.136.camel@localhost.localdomain> <1120595638.30349.40.camel@localhost.localdomain> <1120596463.6862.179.camel@localhost.localdomain> <1120597948.30349.48.camel@localhost.localdomain> <1120633202.6862.226.camel@localhost.localdomain> <1120656286.30349.91.camel@localhost.localdomain> <20050706135902.GO1972@anduril.pams.ncsu.edu> <1120660781.30349.122.camel@localhost.localdomain> <1120663012.6862.273.camel@localhost.localdomain> <1120663712.30349.143.camel@localhost.localdomain> Message-ID: <1120748724.31499.3.camel@opus.phy.duke.edu> > The build system has other issues. Right now, I don't think it can deal > with ExclusiveArch correctly. If it did, then we could just have "make > build" parse ExclusiveArch for kernel-module packages, and build for all > those arches. I've CC'd seth and dan to see what they say. does this imply that if you ExclusiveArch to i386 that it should build for i386, i686, athlon, automatically? -sv From notting at redhat.com Thu Jul 7 15:20:55 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jul 2005 11:20:55 -0400 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120748724.31499.3.camel@opus.phy.duke.edu> References: <1120595638.30349.40.camel@localhost.localdomain> <1120596463.6862.179.camel@localhost.localdomain> <1120597948.30349.48.camel@localhost.localdomain> <1120633202.6862.226.camel@localhost.localdomain> <1120656286.30349.91.camel@localhost.localdomain> <20050706135902.GO1972@anduril.pams.ncsu.edu> <1120660781.30349.122.camel@localhost.localdomain> <1120663012.6862.273.camel@localhost.localdomain> <1120663712.30349.143.camel@localhost.localdomain> <1120748724.31499.3.camel@opus.phy.duke.edu> Message-ID: <20050707152055.GA12148@nostromo.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > > > The build system has other issues. Right now, I don't think it can deal > > with ExclusiveArch correctly. If it did, then we could just have "make > > build" parse ExclusiveArch for kernel-module packages, and build for all > > those arches. I've CC'd seth and dan to see what they say. > > does this imply that if you ExclusiveArch to i386 that it should build > for i386, i686, athlon, automatically? Realistically, you'd want to either: a) ExclusiveArch: or b) have a magic list somewhere of things that builds for 'wherever there's a kernel' Bill From tcallawa at redhat.com Thu Jul 7 19:57:57 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 07 Jul 2005 14:57:57 -0500 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120748724.31499.3.camel@opus.phy.duke.edu> References: <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120592080.6862.136.camel@localhost.localdomain> <1120595638.30349.40.camel@localhost.localdomain> <1120596463.6862.179.camel@localhost.localdomain> <1120597948.30349.48.camel@localhost.localdomain> <1120633202.6862.226.camel@localhost.localdomain> <1120656286.30349.91.camel@localhost.localdomain> <20050706135902.GO1972@anduril.pams.ncsu.edu> <1120660781.30349.122.camel@localhost.localdomain> <1120663012.6862.273.camel@localhost.localdomain> <1120663712.30349.143.camel@localhost.localdomain> <1120748724.31499.3.camel@opus.phy.duke.edu> Message-ID: <1120766277.9303.25.camel@localhost.localdomain> On Thu, 2005-07-07 at 11:05 -0400, seth vidal wrote: > > The build system has other issues. Right now, I don't think it can deal > > with ExclusiveArch correctly. If it did, then we could just have "make > > build" parse ExclusiveArch for kernel-module packages, and build for all > > those arches. I've CC'd seth and dan to see what they say. > > does this imply that if you ExclusiveArch to i386 that it should build > for i386, i686, athlon, automatically? No, but I don't know what the buildsystem will do if it sees: ExclusiveArch: i586 i686 ppc ppc64 x86_64 ~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 Fri Jul 8 07:38:17 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 08 Jul 2005 09:38:17 +0200 Subject: [Fedora-packaging] Where to install examples to? Message-ID: <1120808297.30532.344.camel@mccallum.corsepiu.local> Hi, I am observing packages in FE installing examples/demos to /usr/bin. Do people agree upon this to be good packaging practice or not? IMO, it is not, because * This gradually fills up /usr/bin. * Many such examples/demos are semi-functional or less and have never been designed to be used by the public. I'd recommend to install examples/demos to either /usr/lib// or even to /usr/share/doc/ Opinions, comments? Ralf From nicolas.mailhot at laposte.net Fri Jul 8 08:53:21 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 8 Jul 2005 10:53:21 +0200 (CEST) Subject: [Fedora-packaging] Where to install examples to? In-Reply-To: <1120808297.30532.344.camel@mccallum.corsepiu.local> References: <1120808297.30532.344.camel@mccallum.corsepiu.local> Message-ID: <37959.192.54.193.37.1120812801.squirrel@rousalka.dyndns.org> On Ven 8 juillet 2005 09:38, Ralf Corsepius wrote: > Hi, > > I am observing packages in FE installing examples/demos to /usr/bin. > > Do people agree upon this to be good packaging practice or not? IMHO examples and demos should be treated like normal code _BUT_ always spinned of in a separate subpackage. This way you get proper packaging and only people who really need them will have them on the filesystem. I hate packages that dump examples and demos in a random place without any real checks and have the main package swelled by this payload. -- Nicolas Mailhot From enrico.scholz at informatik.tu-chemnitz.de Fri Jul 8 08:58:46 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 08 Jul 2005 10:58:46 +0200 Subject: [Fedora-packaging] Where to install examples to? In-Reply-To: <1120808297.30532.344.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Fri, 08 Jul 2005 09:38:17 +0200") References: <1120808297.30532.344.camel@mccallum.corsepiu.local> Message-ID: <87eka9znax.fsf@kosh.bigo.ensc.de> rc040203 at freenet.de (Ralf Corsepius) writes: > I am observing packages in FE installing examples/demos to /usr/bin. > Do people agree upon this to be good packaging practice or not? > > IMO, it is not, because > * This gradually fills up /usr/bin. > * Many such examples/demos are semi-functional or less and have never > been designed to be used by the public. ACK; additionally: * it may add additional dependencies; e.g. when haing a C project which ships a perl script as demo, the entire package will require perl. Packaging the demo into /usr/lib or as %doc will not help much as rpm generates deps for all files (inclusive %doc) :( So a separate subpackage will be the best solution. Enrico From rc040203 at freenet.de Fri Jul 8 09:27:26 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 08 Jul 2005 11:27:26 +0200 Subject: [Fedora-packaging] Where to install examples to? In-Reply-To: <87eka9znax.fsf@kosh.bigo.ensc.de> References: <1120808297.30532.344.camel@mccallum.corsepiu.local> <87eka9znax.fsf@kosh.bigo.ensc.de> Message-ID: <1120814846.30532.366.camel@mccallum.corsepiu.local> On Fri, 2005-07-08 at 10:58 +0200, Enrico Scholz wrote: > rc040203 at freenet.de (Ralf Corsepius) writes: > > > I am observing packages in FE installing examples/demos to /usr/bin. > > Do people agree upon this to be good packaging practice or not? > > > > IMO, it is not, because > > * This gradually fills up /usr/bin. > > * Many such examples/demos are semi-functional or less and have never > > been designed to be used by the public. > > ACK; additionally: > > * it may add additional dependencies; e.g. when haing a C project which > ships a perl script as demo, the entire package will require perl. > > Packaging the demo into /usr/lib or as %doc will not help much as > rpm generates deps for all files (inclusive %doc) :( So a separate > subpackage will be the best solution. I realize I have not been precise enough. The trigger for this thread to me had been example/demo binaries handling in https://www.redhat.com/archives/fedora-extras-commits/2005-July/msg00619.html In this case, "example binaries" are being packaged into an *-examples package and are installed to /usr/bin. The question here is, should these binaries be installed at all, or should they better be installed accompanying the source code somewhere else, or should the whole examples not be installed at all (This seems to have been the intention of the original authors, because the original Makefiles do not install them). If they are coding examples, IMO, it would be best to only ship the sources (then /usr/share/doc probably would be appropriate), or to ship these binaries, accompanied by the source-code somewhere under /usr/lib/. When having faced a similar problem with my Inventor package some time ago at fedora.us, the outcome of a similar discussion was to ship Inventor's examples source-code without binaries below /usr/lib/ (c.f. Inventor-examples). A counter example to this consideration is gtk-demo. RH ships it as part of the gtk2 package :( Ralf From mpeters at mac.com Fri Jul 8 13:57:32 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 08 Jul 2005 06:57:32 -0700 Subject: [Fedora-packaging] Where to install examples to? In-Reply-To: <1120808297.30532.344.camel@mccallum.corsepiu.local> References: <1120808297.30532.344.camel@mccallum.corsepiu.local> Message-ID: <1120831053.2744.81.camel@locolhost.localdomain> On Fri, 2005-07-08 at 09:38 +0200, Ralf Corsepius wrote: > Hi, > > I am observing packages in FE installing examples/demos to /usr/bin. > > Do people agree upon this to be good packaging practice or not? > > > IMO, it is not, because > * This gradually fills up /usr/bin. > * Many such examples/demos are semi-functional or less and have never > been designed to be used by the public. > > I'd recommend to install examples/demos to either > /usr/lib// > or even to > /usr/share/doc/ > > Opinions, comments? I'm in agreement - though some demos/examples actually are functional, if they are only intended to be demos/examples they should (imho) be in /usr/share/doc/ That's traditionally where I have found them (IE gst-python demos - some of which are useful as stand alone) From mpeters at mac.com Fri Jul 8 13:59:03 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 08 Jul 2005 06:59:03 -0700 Subject: [Fedora-packaging] Where to install examples to? In-Reply-To: <37959.192.54.193.37.1120812801.squirrel@rousalka.dyndns.org> References: <1120808297.30532.344.camel@mccallum.corsepiu.local> <37959.192.54.193.37.1120812801.squirrel@rousalka.dyndns.org> Message-ID: <1120831144.2744.83.camel@locolhost.localdomain> On Fri, 2005-07-08 at 10:53 +0200, Nicolas Mailhot wrote: > _BUT_ always > spinned of in a separate subpackage. would devel package suffice? From nicolas.mailhot at laposte.net Fri Jul 8 14:05:36 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 8 Jul 2005 16:05:36 +0200 (CEST) Subject: [Fedora-packaging] Where to install examples to? In-Reply-To: <1120831144.2744.83.camel@locolhost.localdomain> References: <1120808297.30532.344.camel@mccallum.corsepiu.local> <37959.192.54.193.37.1120812801.squirrel@rousalka.dyndns.org> <1120831144.2744.83.camel@locolhost.localdomain> Message-ID: <36003.192.54.193.37.1120831536.squirrel@rousalka.dyndns.org> On Ven 8 juillet 2005 15:59, Michael A. Peters wrote: > On Fri, 2005-07-08 at 10:53 +0200, Nicolas Mailhot wrote: >> _BUT_ always >> spinned of in a separate subpackage. > > would devel package suffice? Depends on the size. Very often -devel packages are only used to build other stuff, so if examples/demos dwarf the "need-for-building" part they don't belong in the same subpackage IMHO. -- Nicolas Mailhot From bugs.michael at gmx.net Fri Jul 8 16:04:04 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 8 Jul 2005 18:04:04 +0200 Subject: [Fedora-packaging] Where to install examples to? In-Reply-To: <1120808297.30532.344.camel@mccallum.corsepiu.local> References: <1120808297.30532.344.camel@mccallum.corsepiu.local> Message-ID: <20050708180404.73ce7715.bugs.michael@gmx.net> On Fri, 08 Jul 2005 09:38:17 +0200, Ralf Corsepius wrote: > Hi, > > I am observing packages in FE installing examples/demos to /usr/bin. > > Do people agree upon this to be good packaging practice or not? > > > IMO, it is not, because > * This gradually fills up /usr/bin. > * Many such examples/demos are semi-functional or less and have never > been designed to be used by the public. > > I'd recommend to install examples/demos to either > /usr/lib// > or even to > /usr/share/doc/ > > Opinions, comments? Certainly _not_ /usr/share, as that one is for architecture-independent data. Reasonable: * use a separate -demos package for them * include them in -devel package as source, so developers can build them and examine them * don't package them if they are not built by default and depending on what kind of demos/example they are -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1422_FC5 loadavg: 2.18 1.74 1.49 From fedora at leemhuis.info Sat Jul 9 18:49:45 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 09 Jul 2005 20:49:45 +0200 Subject: [Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package) In-Reply-To: <1120668803.3108.15.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120399910.2979.27.camel@notebook.thl.home> <1120400508.27103.62.camel@localhost.localdomain> <1120407160.2695.81.camel@localhost.localdomain> <1120410641.2979.68.camel@notebook.thl.home> <1120417268.2979.91.camel@notebook.thl.home> <1120487453.27103.79.camel@localhost.localdomain> <1120668803.3108.15.camel@localhost.localdomain> Message-ID: <1120934985.3560.3.camel@localhost.localdomain> Am Donnerstag, den 07.07.2005, 09:13 +0200 schrieb Thorsten Leemhuis: > Am Montag, den 04.07.2005, 09:30 -0500 schrieb Tom 'spot' Callaway: > > On Sun, 2005-07-03 at 21:01 +0200, Thorsten Leemhuis wrote: > > > > > I tried, was not that hard (if I didn't miss anything). Results are > > > found at > > > http://www.leemhuis.info/files/fedorarpms/MISC.fdr/kernel-module-example/ > > > in the wiki at > > > http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal Another small update: the kernel-module is now installed as 0644 as proposed by Ville. There is no need for 744 (rumors circulate that there were problems with 644 in the past but nobody remembers the details). -- Thorsten Leemhuis From rc040203 at freenet.de Sun Jul 10 12:01:01 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 10 Jul 2005 14:01:01 +0200 Subject: [Fedora-packaging] Where to install examples to? In-Reply-To: <20050708180404.73ce7715.bugs.michael@gmx.net> References: <1120808297.30532.344.camel@mccallum.corsepiu.local> <20050708180404.73ce7715.bugs.michael@gmx.net> Message-ID: <1120996861.30532.413.camel@mccallum.corsepiu.local> On Fri, 2005-07-08 at 18:04 +0200, Michael Schwendt wrote: > On Fri, 08 Jul 2005 09:38:17 +0200, Ralf Corsepius wrote: > > > Hi, > > > > I am observing packages in FE installing examples/demos to /usr/bin. > > > > Do people agree upon this to be good packaging practice or not? > > > > > > IMO, it is not, because > > * This gradually fills up /usr/bin. > > * Many such examples/demos are semi-functional or less and have never > > been designed to be used by the public. > > > > I'd recommend to install examples/demos to either > > /usr/lib// > > or even to > > /usr/share/doc/ > > > > Opinions, comments? > > Certainly _not_ /usr/share, as that one is for architecture-independent > data. Right, this wouldn't be an appropriate place for binaries, but it would be for "examples/demos" provided as source code. > Reasonable: > > * use a separate -demos package for them > > * include them in -devel package as source, so developers can > build them and examine them > > * don't package them if they are not built by default and > depending on what kind of demos/example they are ACK. Ralf From mpeters at mac.com Fri Jul 15 08:09:01 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 15 Jul 2005 01:09:01 -0700 Subject: [Fedora-packaging] updating versions policy Message-ID: <1121414942.2665.26.camel@locolhost.localdomain> I know that with shared libraries, it generally is not a good idea to push an update that involves versioning a shared library because the user may have software their system that is linked against the older shared library, but is there a general policy about other software? One of the packages I maintain in Extras is likely to be named as a sourceforge project of the month. The upstream developer is working overtime to finish implementing some things before that happens. The package is gourmet (PyGTK recipe manager) and absolutely nothing depends upon it - and I'm thinking that when he has these things finished, that might be a good time to update the package in Extras. Since it is not a package which is designed to have anything else depend on it, I'm assuming there is not a problem with a version update in Extras? Is that the case? The project is under fairly rapid development but I don't intend to package every little update simply because most of them don't add anything worth an update imho, but I think the update he is planning (after testing) is will be worth pushing an update. From bugs.michael at gmx.net Fri Jul 15 08:45:53 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 15 Jul 2005 10:45:53 +0200 Subject: [Fedora-packaging] updating versions policy In-Reply-To: <1121414942.2665.26.camel@locolhost.localdomain> References: <1121414942.2665.26.camel@locolhost.localdomain> Message-ID: <20050715104553.08d1b0a5.bugs.michael@gmx.net> On Fri, 15 Jul 2005 01:09:01 -0700, Michael A. Peters wrote: > I know that with shared libraries, it generally is not a good idea to > push an update that involves versioning a shared library because the > user may have software their system that is linked against the older > shared library, but is there a general policy about other software? With "versioning a shared library" here you mean a change in SONAME? > One of the packages I maintain in Extras is likely to be named as a > sourceforge project of the month. The upstream developer is working > overtime to finish implementing some things before that happens. The > package is gourmet (PyGTK recipe manager) and absolutely nothing depends > upon it - and I'm thinking that when he has these things finished, that > might be a good time to update the package in Extras. > > Since it is not a package which is designed to have anything else depend > on it, I'm assuming there is not a problem with a version update in > Extras? Is that the case? If your package is the only one which accesses the shared libs, no problem. This is most certainly the case when the package doesn't provide a public API and if no other package implements an API either. Hence: no dependencies in Extras => don't worry about upgrades. From mpeters at mac.com Fri Jul 15 09:43:54 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 15 Jul 2005 02:43:54 -0700 Subject: [Fedora-packaging] updating versions policy In-Reply-To: <20050715104553.08d1b0a5.bugs.michael@gmx.net> References: <1121414942.2665.26.camel@locolhost.localdomain> <20050715104553.08d1b0a5.bugs.michael@gmx.net> Message-ID: <1121420634.2665.30.camel@locolhost.localdomain> On Fri, 2005-07-15 at 10:45 +0200, Michael Schwendt wrote: > On Fri, 15 Jul 2005 01:09:01 -0700, Michael A. Peters wrote: > > > I know that with shared libraries, it generally is not a good idea to > > push an update that involves versioning a shared library because the > > user may have software their system that is linked against the older > > shared library, but is there a general policy about other software? > > With "versioning a shared library" here you mean a change in SONAME? yes > > > If your package is the only one which accesses the shared libs, no > problem. This is most certainly the case when the package doesn't provide > a public API and if no other package implements an API either. Hence: > no dependencies in Extras => don't worry about upgrades. OK - cool From orion at cora.nwra.com Fri Jul 15 20:48:19 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Jul 2005 14:48:19 -0600 Subject: [Fedora-packaging] Using %{dist} for conditional compilation Message-ID: <42D82113.5030005@cora.nwra.com> Is it kosher to use the %{dist} tag for conditional compilation? The shift from g77 to gfortran in FC3->FC4 has led to the need to compile packages differently for the two distributions. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From ivazquez at ivazquez.net Fri Jul 15 21:01:16 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 15 Jul 2005 17:01:16 -0400 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <42D82113.5030005@cora.nwra.com> References: <42D82113.5030005@cora.nwra.com> Message-ID: <1121461276.10063.11.camel@ignacio.lan> On Fri, 2005-07-15 at 14:48 -0600, Orion Poplawski wrote: > Is it kosher to use the %{dist} tag for conditional compilation? The > shift from g77 to gfortran in FC3->FC4 has led to the need to compile > packages differently for the two distributions. No. Use %{fedora}. It will have an integer value the same as the version of Fedora the package is built for. Even better, since there are separate branches per version it's easy enough to just have the differences in the spec files directly. -- 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 mpeters at mac.com Fri Jul 15 22:28:57 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 15 Jul 2005 15:28:57 -0700 Subject: [Fedora-packaging] Re: Using %{dist} for conditional compilation In-Reply-To: <42D82113.5030005@cora.nwra.com> References: <42D82113.5030005@cora.nwra.com> Message-ID: <1121466537.2665.41.camel@locolhost.localdomain> On Fri, 2005-07-15 at 14:48 -0600, Orion Poplawski wrote: > Is it kosher to use the %{dist} tag for conditional compilation? No, I don't think so - because %{dist} is not defined on the users machines, only defined on the build machine, in mock. different spec files in the different branches seems best to me. > The > shift from g77 to gfortran in FC3->FC4 has led to the need to compile > packages differently for the two distributions. > From orion at cora.nwra.com Fri Jul 15 22:35:03 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Jul 2005 16:35:03 -0600 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <1121461276.10063.11.camel@ignacio.lan> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> Message-ID: <42D83A17.9060302@cora.nwra.com> Ignacio Vazquez-Abrams wrote: > > No. Use %{fedora}. It will have an integer value the same as the version > of Fedora the package is built for. Even better, since there are > separate branches per version it's easy enough to just have the > differences in the spec files directly. > Could you give an example? I can't find docs on how to use %if in a spec file to compare values. Trying to do something like: %if %{fedora} >= 4 BuildRequires: gcc-gfortran %else BuildRequires: gcc-g77 %endif -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From ivazquez at ivazquez.net Fri Jul 15 22:52:10 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 15 Jul 2005 18:52:10 -0400 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <42D83A17.9060302@cora.nwra.com> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> <42D83A17.9060302@cora.nwra.com> Message-ID: <1121467930.10063.18.camel@ignacio.lan> On Fri, 2005-07-15 at 16:35 -0600, Orion Poplawski wrote: > Ignacio Vazquez-Abrams wrote: > > > > No. Use %{fedora}. It will have an integer value the same as the version > > of Fedora the package is built for. Even better, since there are > > separate branches per version it's easy enough to just have the > > differences in the spec files directly. > > > > Could you give an example? I can't find docs on how to use %if in a > spec file to compare values. %if 0%{?fedora} > 03 foo %else bar %endif -- 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 andreas at bawue.net Fri Jul 15 22:52:08 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Sat, 16 Jul 2005 00:52:08 +0200 (CEST) Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <42D83A17.9060302@cora.nwra.com> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> <42D83A17.9060302@cora.nwra.com> Message-ID: On Fri, 15 Jul 2005, Orion Poplawski wrote: > Could you give an example? I can't find docs on how to use %if in a > spec file to compare values. Trying to do something like: %if "%fedora" >= "4" BuildRequires: gcc-gfortran %else BuildRequires: gcc-g77 %endif This should work. bye, andreas From mpeters at mac.com Sat Jul 16 07:45:19 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 16 Jul 2005 00:45:19 -0700 Subject: [Fedora-packaging] Building src.rpm's outside of mock/mach Message-ID: <1121499920.2665.55.camel@locolhost.localdomain> I'm all for building rpm's inside mach/mock because it avoids unintended dependencies (IE you build sox outside of mock, and have lame-devel and libmad-devel on your system, the resulting sox rpm will be linked against them) But what about cases where building outside of mock results in a build error, should that be considered a packaging error? The question came about as result of working on a gstreamer-plugins add-on package. If make install is used in the spec file, it works fine when built inside mock because the necessary devel packages for core plugins are not there. But when the same src.rpm is rebuilt on a user system, it may result in a build error because make install will potentially build plugins that aren't intended to be packaged. Is it a packaging error if a src.rpm can only be expected to reliably build inside mock/mach? If it is a packaging error, what would be the best course of action? Some solutions include manually installing what you DO want to package (what I have been doing), perhaps a bunch of configure switches telling configure not to build all of the plugins you don't intend to package, or telling rpm to ignore unpackaged files. From mattdm at mattdm.org Sat Jul 16 12:59:34 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 16 Jul 2005 08:59:34 -0400 Subject: [Fedora-packaging] Building src.rpm's outside of mock/mach In-Reply-To: <1121499920.2665.55.camel@locolhost.localdomain> References: <1121499920.2665.55.camel@locolhost.localdomain> Message-ID: <20050716125934.GA3850@jadzia.bu.edu> On Sat, Jul 16, 2005 at 12:45:19AM -0700, Michael A. Peters wrote: > If it is a packaging error, what would be the best course of action? > Some solutions include manually installing what you DO want to package > (what I have been doing), perhaps a bunch of configure switches telling > configure not to build all of the plugins you don't intend to package, > or telling rpm to ignore unpackaged files. I think the configure switch is the best way -- it makes the choice of what to package explicit. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From shiva at sewingwitch.com Sat Jul 16 18:47:53 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 16 Jul 2005 11:47:53 -0700 Subject: [Fedora-packaging] Re: Using %{dist} for conditional compilation In-Reply-To: <1121466537.2665.41.camel@locolhost.localdomain> References: <42D82113.5030005@cora.nwra.com> <1121466537.2665.41.camel@locolhost.localdomain> Message-ID: <0D1A01AC7FC43BAC0C7532DB@[10.0.0.14]> --On Friday, July 15, 2005 3:28 PM -0700 "Michael A. Peters" wrote: > different spec files in the different branches seems best to me. OTOH, if your objective is to create a tarball that can also be built as an RPM, then you want a single spec file so that -ta is unambiguous. From tcallawa at redhat.com Sat Jul 16 18:52:58 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 16 Jul 2005 13:52:58 -0500 Subject: [Fedora-packaging] Re: Using %{dist} for conditional compilation In-Reply-To: <0D1A01AC7FC43BAC0C7532DB@[10.0.0.14]> References: <42D82113.5030005@cora.nwra.com> <1121466537.2665.41.camel@locolhost.localdomain> <0D1A01AC7FC43BAC0C7532DB@[10.0.0.14]> Message-ID: <1121539978.2755.131.camel@localhost.localdomain> On Sat, 2005-07-16 at 11:47 -0700, Kenneth Porter wrote: > --On Friday, July 15, 2005 3:28 PM -0700 "Michael A. Peters" > wrote: > > > different spec files in the different branches seems best to me. > > OTOH, if your objective is to create a tarball that can also be built as an > RPM, then you want a single spec file so that -ta is unambiguous. The dist tag guidelines are setup specifically so that you can either use them, or not use them. If you don't like the idea of using them in your packages, by all means, do not. It will NOT fail a review if you don't use them. However, if you want to use them, all you have to do is use them properly. ~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 mpeters at mac.com Sun Jul 17 00:55:52 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 16 Jul 2005 17:55:52 -0700 Subject: [Fedora-packaging] Re: Using %{dist} for conditional compilation In-Reply-To: <0D1A01AC7FC43BAC0C7532DB@[10.0.0.14]> References: <42D82113.5030005@cora.nwra.com> <1121466537.2665.41.camel@locolhost.localdomain> <0D1A01AC7FC43BAC0C7532DB@[10.0.0.14]> Message-ID: <1121561752.2665.62.camel@locolhost.localdomain> On Sat, 2005-07-16 at 11:47 -0700, Kenneth Porter wrote: > --On Friday, July 15, 2005 3:28 PM -0700 "Michael A. Peters" > wrote: > > > different spec files in the different branches seems best to me. > > OTOH, if your objective is to create a tarball that can also be built as an > RPM, then you want a single spec file so that -ta is unambiguous. spec files in upstream tarballs should really try to avoid using distribution specific macros anyway. From rc040203 at freenet.de Sun Jul 17 04:53:23 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 17 Jul 2005 06:53:23 +0200 Subject: [Fedora-packaging] Building src.rpm's outside of mock/mach In-Reply-To: <1121499920.2665.55.camel@locolhost.localdomain> References: <1121499920.2665.55.camel@locolhost.localdomain> Message-ID: <1121576004.4468.7.camel@mccallum.corsepiu.local> On Sat, 2005-07-16 at 00:45 -0700, Michael A. Peters wrote: > Is it a packaging error if a src.rpm can only be expected to reliably > build inside mock/mach? IMO, yes, definitely - Package building/re-building must be deterministically reproduce the same results in both chroot'ed and non-chroot'ed environments. > If it is a packaging error, what would be the best course of action? IMO, if a package can't be rebuilt in a user environment it qualifies as broken and "not ready for release". > Some solutions include manually installing what you DO want to package That would be a packager's hack/resort to work around a broken package. > (what I have been doing), perhaps a bunch of configure switches telling > configure not to build all of the plugins you don't intend to package, > or telling rpm to ignore unpackaged files. Yes, this would be an approach upstream could choose to fix such issues. Ralf From rc040203 at freenet.de Wed Jul 20 13:07:29 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 20 Jul 2005 15:07:29 +0200 Subject: [Fedora-packaging] Multiline %defines Message-ID: <1121864849.2015.165.camel@mccallum.corsepiu.local> Hi, Is there a portable (portable across different versions of rpm) way to override specify defines which span across several lines, from inside of a spec file? Background: I am trying to override __os_install_post from inside of a spec file, similar to this: .. %define __os_install_post \ ./brp-custom-compress \ ./brp-custom-strip \ %{nil} .. This seems to work on rpm-4.4.x (FC4), but seems to fail with rpm-4.0.x (rh7.3): # rpmbuild tmp.spec .... error: Macro %__os_install_post has empty body error: line 55: Unknown tag: ./brp-compress \ AFAIS, rpm-4.0.x chokes on the line continuation char. Ralf From mattdm at mattdm.org Wed Jul 20 13:26:33 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 20 Jul 2005 09:26:33 -0400 Subject: [Fedora-packaging] Multiline %defines In-Reply-To: <1121864849.2015.165.camel@mccallum.corsepiu.local> References: <1121864849.2015.165.camel@mccallum.corsepiu.local> Message-ID: <20050720132633.GA15566@jadzia.bu.edu> On Wed, Jul 20, 2005 at 03:07:29PM +0200, Ralf Corsepius wrote: > Background: I am trying to override __os_install_post from inside of a > spec file, similar to this: > .. > %define __os_install_post \ > ./brp-custom-compress \ > ./brp-custom-strip \ > %{nil} [...] > AFAIS, rpm-4.0.x chokes on the line continuation char. Haven't tried it, but what if you do: %define __os_install_post "./brp-custom-compress; ./brp-custom-strip" and dodge the issue? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From rc040203 at freenet.de Wed Jul 20 13:43:32 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 20 Jul 2005 15:43:32 +0200 Subject: [Fedora-packaging] Multiline %defines In-Reply-To: <20050720132633.GA15566@jadzia.bu.edu> References: <1121864849.2015.165.camel@mccallum.corsepiu.local> <20050720132633.GA15566@jadzia.bu.edu> Message-ID: <1121867013.2015.174.camel@mccallum.corsepiu.local> On Wed, 2005-07-20 at 09:26 -0400, Matthew Miller wrote: > On Wed, Jul 20, 2005 at 03:07:29PM +0200, Ralf Corsepius wrote: > > Background: I am trying to override __os_install_post from inside of a > > spec file, similar to this: > > .. > > %define __os_install_post \ > > ./brp-custom-compress \ > > ./brp-custom-strip \ > > %{nil} > [...] > > AFAIS, rpm-4.0.x chokes on the line continuation char. > > Haven't tried it, but what if you do: > > %define __os_install_post "./brp-custom-compress; ./brp-custom-strip" > > and dodge the issue? To be tried. However, I've been told [1] %define __os_install_post ./brp-custom-compress; ./brp-custom-strip was working, but haven't had a chance this try it yet. Another obvious work-around would be not to use __os_install_post and to explicitly call the brp* scripts: %define __os_install_post %{nil} ... %install ... ./brp-custom-compress ./brp-custom-strip Does anybody recall since when (which rpm version, which RHL/FC release) this issue had been fixed? Ralf [1] I don't have rh7.3, I just received a report from a rh7.3 user who is trying to build one of my rpms. From orion at cora.nwra.com Wed Jul 20 16:41:57 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 20 Jul 2005 10:41:57 -0600 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> <42D83A17.9060302@cora.nwra.com> Message-ID: <42DE7ED5.3040603@cora.nwra.com> Andreas Thienemann wrote: > On Fri, 15 Jul 2005, Orion Poplawski wrote: > > > %if "%fedora" >= "4" > BuildRequires: gcc-gfortran > %else > BuildRequires: gcc-g77 > %endif > > This should work. > > bye, > andreas > On my FC4 box I get: $ rpmbuild -ba *spec error: Failed build dependencies: gcc-g77 is needed by hdf-4.2r1-2.i386 So looks like %fedora is not defined on user machins, only in the build system? This won't work. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From rdieter at math.unl.edu Wed Jul 20 16:49:04 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Jul 2005 11:49:04 -0500 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <42DE7ED5.3040603@cora.nwra.com> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> <42D83A17.9060302@cora.nwra.com> <42DE7ED5.3040603@cora.nwra.com> Message-ID: <42DE8080.6070103@math.unl.edu> Orion Poplawski wrote: > Andreas Thienemann wrote: >> On Fri, 15 Jul 2005, Orion Poplawski wrote: >> %if "%fedora" >= "4" >> BuildRequires: gcc-gfortran >> %else >> BuildRequires: gcc-g77 >> %endif >> >> This should work. > On my FC4 box I get: > > $ rpmbuild -ba *spec > error: Failed build dependencies: > gcc-g77 is needed by hdf-4.2r1-2.i386 > > So looks like %fedora is not defined on user machins, only in the build > system? Yes, the Fedora Extras buildsystem defines this macro. You expected otherwise? -- Rex From rdieter at math.unl.edu Wed Jul 20 16:50:49 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Jul 2005 11:50:49 -0500 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <42DE8080.6070103@math.unl.edu> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> <42D83A17.9060302@cora.nwra.com> <42DE7ED5.3040603@cora.nwra.com> <42DE8080.6070103@math.unl.edu> Message-ID: <42DE80E9.4080805@math.unl.edu> Rex Dieter wrote: > Orion Poplawski wrote: > >> Andreas Thienemann wrote: >> >>> On Fri, 15 Jul 2005, Orion Poplawski wrote: > > >>> %if "%fedora" >= "4" >>> BuildRequires: gcc-gfortran >>> %else >>> BuildRequires: gcc-g77 >>> %endif >>> >>> This should work. > > >> On my FC4 box I get: >> >> $ rpmbuild -ba *spec >> error: Failed build dependencies: >> gcc-g77 is needed by hdf-4.2r1-2.i386 >> >> So looks like %fedora is not defined on user machins, only in the >> build system? > > > Yes, the Fedora Extras buildsystem defines this macro. You expected > otherwise? To emulate the buildsystem behavior (in this context), you'd need to: rpmbuild --define "fedora 4" --define "dist fc4" foo.spec -- Rex From ivazquez at ivazquez.net Wed Jul 20 17:09:46 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 20 Jul 2005 13:09:46 -0400 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <42DE7ED5.3040603@cora.nwra.com> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> <42D83A17.9060302@cora.nwra.com> <42DE7ED5.3040603@cora.nwra.com> Message-ID: <1121879387.28256.47.camel@ignacio.lan> On Wed, 2005-07-20 at 10:41 -0600, Orion Poplawski wrote: > Andreas Thienemann wrote: > > On Fri, 15 Jul 2005, Orion Poplawski wrote: > > > > > > %if "%fedora" >= "4" > > BuildRequires: gcc-gfortran > > %else > > BuildRequires: gcc-g77 > > %endif > > > > This should work. > > On my FC4 box I get: > > $ rpmbuild -ba *spec > error: Failed build dependencies: > gcc-g77 is needed by hdf-4.2r1-2.i386 > > So looks like %fedora is not defined on user machins, only in the build > system? This won't work. Put this in /etc/rpm: http://fedora.ivazquez.net/files/macros.disttag -- 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 jspaleta at gmail.com Wed Jul 20 20:53:57 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 20 Jul 2005 16:53:57 -0400 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <42DE8080.6070103@math.unl.edu> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> <42D83A17.9060302@cora.nwra.com> <42DE7ED5.3040603@cora.nwra.com> <42DE8080.6070103@math.unl.edu> Message-ID: <604aa791050720135376dcd0be@mail.gmail.com> On 7/20/05, Rex Dieter wrote: > Yes, the Fedora Extras buildsystem defines this macro. You expected > otherwise? actually.. i sort of do. I'd very much expect my workstation running fc4 to have access to a package with the fedora specific macro definitions set to values the fedora-whatever build system uses for building packages for fc4. I dont expect my fc4 workstation to build things for fc3 or the development tree without some define love. But i would expect there to be a package that provided the fedora specific fc4 rpm macros as well as providing those macros when using a mock managed local build environment. mock is great and all.. but we can't demand it be used for local test building. -jef