From jdennis at redhat.com Thu Dec 3 15:33:23 2009 From: jdennis at redhat.com (John Dennis) Date: Thu, 03 Dec 2009 10:33:23 -0500 Subject: [Fedora-packaging] LSB initscript ordering issues Message-ID: <4B17DA43.5010904@redhat.com> I'm in the process of cleaning up an initscript I own to meet LSB standards but this has left me with several questions primarilary in the area of start up ordering. FYI, I'm utilizing the guidelines found here: https://fedoraproject.org/wiki/FCNewInit/Initscripts https://fedoraproject.org/wiki/Packaging/SysVInitScript In the past we used hardcoded chkconfig start/stop numbers to control the order in which services were started and stopped. My understanding is that is deprecated (although still supported) but the preferred method is the LSB boot facility declarations (Required-Start, Should-Start, Required-Stop, Should-Stop). Correct? The section describing facility names seems a bit vague to me: Shouldn't the guidelines *require* that the LSB block have a Provides: declaration which at a minimum includes a name matching the initscript? If you read between the lines the guidelines seem to suggest that but it's not clearly an explicit mandate. Without that I don't see how one can use the boot facility dependencies for other services. In other words if I depend on mysql running then mysql must have declared it provides mysql, or is that provides implicit as opposed to explicit? In addition to the explicit eponymous Provides: what about virtual provides? Do we have a set of virtual provide names? (e.g. mailserver, webserver, or ldapserver) The guidelines also state that an initiscript should never be marked as %config and instead import configuration settings from /etc/sysconfig/$name. But what about the case where a service may have a variety of boot dependencies depending on how it's configured? For example a service might be configured to optionally use mysql vs. postgres, or to use LDAP vs. SQL so it will have boot dependencies on particular services which cannot be hardwired ahead of time. I doubt the LSB block parsing logic handles "includes" from /etc/sysconfig, or does it? Assuming not then the initscript has to be marked as %config right? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From notting at redhat.com Thu Dec 3 15:39:55 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 3 Dec 2009 10:39:55 -0500 Subject: [Fedora-packaging] LSB initscript ordering issues In-Reply-To: <4B17DA43.5010904@redhat.com> References: <4B17DA43.5010904@redhat.com> Message-ID: <20091203153955.GG657@nostromo.devel.redhat.com> John Dennis (jdennis at redhat.com) said: > In the past we used hardcoded chkconfig start/stop numbers to > control the order in which services were started and stopped. My > understanding is that is deprecated (although still supported) but > the preferred method is the LSB boot facility declarations > (Required-Start, Should-Start, Required-Stop, Should-Stop). Correct? I wouldn't say it's *preferred*. It's an alternate method. > The section describing facility names seems a bit vague to me: > > Shouldn't the guidelines *require* that the LSB block have a > Provides: declaration which at a minimum includes a name matching > the initscript? That's implicitly provided no matter what. > In addition to the explicit eponymous Provides: what about virtual > provides? Do we have a set of virtual provide names? (e.g. > mailserver, webserver, or ldapserver) No. Those aren't defined in the spec. > The guidelines also state that an initiscript should never be marked > as %config and instead import configuration settings from > /etc/sysconfig/$name. But what about the case where a service may > have a variety of boot dependencies depending on how it's > configured? For example a service might be configured to optionally > use mysql vs. postgres, or to use LDAP vs. SQL so it will have boot > dependencies on particular services which cannot be hardwired ahead > of time. The LSB spec won't help you here, alas. > I doubt the LSB block parsing logic handles "includes" from > /etc/sysconfig, or does it? It does not. Bill From jdennis at redhat.com Thu Dec 3 15:48:04 2009 From: jdennis at redhat.com (John Dennis) Date: Thu, 03 Dec 2009 10:48:04 -0500 Subject: [Fedora-packaging] LSB initscript ordering issues In-Reply-To: <20091203153955.GG657@nostromo.devel.redhat.com> References: <4B17DA43.5010904@redhat.com> <20091203153955.GG657@nostromo.devel.redhat.com> Message-ID: <4B17DDB4.1080405@redhat.com> On 12/03/2009 10:39 AM, Bill Nottingham wrote: > John Dennis (jdennis at redhat.com) said: >> In the past we used hardcoded chkconfig start/stop numbers to >> control the order in which services were started and stopped. My >> understanding is that is deprecated (although still supported) but >> the preferred method is the LSB boot facility declarations >> (Required-Start, Should-Start, Required-Stop, Should-Stop). Correct? > > I wouldn't say it's *preferred*. It's an alternate method. > >> The section describing facility names seems a bit vague to me: >> >> Shouldn't the guidelines *require* that the LSB block have a >> Provides: declaration which at a minimum includes a name matching >> the initscript? > > That's implicitly provided no matter what. It might be nice to update the wiki to make this clear. > >> In addition to the explicit eponymous Provides: what about virtual >> provides? Do we have a set of virtual provide names? (e.g. >> mailserver, webserver, or ldapserver) > > No. Those aren't defined in the spec. Right, it's not an LSB issue but a Fedora packaging issue. Do we intend to define such a set of virtual provides for Fedora? > >> The guidelines also state that an initiscript should never be marked >> as %config and instead import configuration settings from >> /etc/sysconfig/$name. But what about the case where a service may >> have a variety of boot dependencies depending on how it's >> configured? For example a service might be configured to optionally >> use mysql vs. postgres, or to use LDAP vs. SQL so it will have boot >> dependencies on particular services which cannot be hardwired ahead >> of time. > > The LSB spec won't help you here, alas. Right, this isn't an LSB spec issue but a Fedora packaging guideline issue. If a sysadmin configures the service to depend on a specific set of dependency services then he/she will have to edit the initscript, thus it should be marked %config so that this customization is not lost. > >> I doubt the LSB block parsing logic handles "includes" from >> /etc/sysconfig, or does it? > > It does not. > > Bill -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From kevin at tummy.com Thu Dec 3 17:25:11 2009 From: kevin at tummy.com (Kevin Fenzi) Date: Thu, 3 Dec 2009 10:25:11 -0700 Subject: [Fedora-packaging] LSB initscript ordering issues In-Reply-To: <4B17DA43.5010904@redhat.com> References: <4B17DA43.5010904@redhat.com> Message-ID: <20091203102511.3cae9522@ohm.scrye.com> On Thu, 03 Dec 2009 10:33:23 -0500 John Dennis wrote: > I'm in the process of cleaning up an initscript I own to meet LSB > standards but this has left me with several questions primarilary in > the area of start up ordering. > > FYI, I'm utilizing the guidelines found here: > https://fedoraproject.org/wiki/FCNewInit/Initscripts ...snip... Just so it's clear: the above link is NOT a guideline... only the other link (https://fedoraproject.org/wiki/Packaging/SysVInitScript) is. I have updated the page to note that it's not a guideline. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From a.badger at gmail.com Thu Dec 3 18:09:50 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 3 Dec 2009 10:09:50 -0800 Subject: [Fedora-packaging] Man pages Packaging Guideline Message-ID: <20091203180950.GA2712@clingman.lan> Hey Ivana, So the FPC met yesterday and voted against the Man Pages Draft as a Packaging Guideline. The basic reasoning is that the justification for voting against the previous man pagesdraft: https://fedoraproject.org/wiki/MAN_pages_which_exists_in_other_places(draft) was applicable here as well. In particular, this was the conclusion of discussion of that other draft: "This draft conflicts with the general practice that Fedora packagers should be working to send improvements directly to upstream. Anyone who feels motivated to dig in other distributions for patches or improvements should feel free to do so, but it is not something that the FPC felt should be codified into the guidelines. " The FPC did offer a few thoughts on what could be done with this, though: * If FESCo wanted to make a policy that we should be striving to have some sort of coverage goal for man pages, then we'd definitely include packaging guidelines so that reviewers and packagers would know that making man pages is required. This could be a FESCo policy like "Fedora wants to have 100% coverage of binaries in /bin, /sbin, /usr/bin, and /usr/sbin" * I'm going to be working on ways that we can restructure the Packaging Guidelines to be better organized this weekend (as part of FUDCon). One aspect of that is figuring out how to make FESCo policies, non-guideline hints for packaging, and other things that are optional or just non-Guideline material better integrated so that packagers and reviewers can both know what's necessary for a Fedora Package and what things they can do to make their package really shine. Finding a place for things like this draft there could be good. + As part of that, we do currently have a page that lists tricks and tips for making better packages that go above and beyond the Guidelines: https://fedoraproject.org/wiki/Packaging_tricks That wiki page is open for anyone to write to so you should be able to add your man page stuff there (or link from it) for the time being. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From a.badger at gmail.com Thu Dec 3 19:55:39 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 3 Dec 2009 11:55:39 -0800 Subject: [Fedora-packaging] LSB initscript ordering issues In-Reply-To: <4B17DDB4.1080405@redhat.com> References: <4B17DA43.5010904@redhat.com> <20091203153955.GG657@nostromo.devel.redhat.com> <4B17DDB4.1080405@redhat.com> Message-ID: <20091203195539.GB2712@clingman.lan> On Thu, Dec 03, 2009 at 10:48:04AM -0500, John Dennis wrote: > On 12/03/2009 10:39 AM, Bill Nottingham wrote: > >John Dennis (jdennis at redhat.com) said: > >>In the past we used hardcoded chkconfig start/stop numbers to > >>control the order in which services were started and stopped. My > >>understanding is that is deprecated (although still supported) but > >>the preferred method is the LSB boot facility declarations > >>(Required-Start, Should-Start, Required-Stop, Should-Stop). Correct? > > > >I wouldn't say it's *preferred*. It's an alternate method. > > > >>The section describing facility names seems a bit vague to me: > >> > >>Shouldn't the guidelines *require* that the LSB block have a > >>Provides: declaration which at a minimum includes a name matching > >>the initscript? > > > >That's implicitly provided no matter what. > > It might be nice to update the wiki to make this clear. > The Guidelines actually did require this. I've updated it to reflect that the service name is implicitly noted. > > > >>In addition to the explicit eponymous Provides: what about virtual > >>provides? Do we have a set of virtual provide names? (e.g. > >>mailserver, webserver, or ldapserver) > > > >No. Those aren't defined in the spec. > > Right, it's not an LSB issue but a Fedora packaging issue. Do we > intend to define such a set of virtual provides for Fedora? > This would make sense. If you could propose a list to add that would be great. You might want to work with the virtual provides for services within rpms, at least to use the same names, even if we don't end up using both. > > > >>The guidelines also state that an initiscript should never be marked > >>as %config and instead import configuration settings from > >>/etc/sysconfig/$name. But what about the case where a service may > >>have a variety of boot dependencies depending on how it's > >>configured? For example a service might be configured to optionally > >>use mysql vs. postgres, or to use LDAP vs. SQL so it will have boot > >>dependencies on particular services which cannot be hardwired ahead > >>of time. > > > >The LSB spec won't help you here, alas. > > Right, this isn't an LSB spec issue but a Fedora packaging guideline > issue. If a sysadmin configures the service to depend on a specific > set of dependency services then he/she will have to edit the > initscript, thus it should be marked %config so that this > customization is not lost. > It could be that the LSB, dependency style is not flexible enough to work in this instance. We might be able to work around this with virtual provides, though. We do want to avoid marking init scripts as %config and eventually, in the indefinite sense, we can use upstart's facilities to do this sort of thing. So I'm not certain that we'd want to start encouraging people to mix config with the initscripts yet. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jdennis at redhat.com Thu Dec 3 20:13:36 2009 From: jdennis at redhat.com (John Dennis) Date: Thu, 03 Dec 2009 15:13:36 -0500 Subject: [Fedora-packaging] LSB initscript ordering issues In-Reply-To: <20091203195539.GB2712@clingman.lan> References: <4B17DA43.5010904@redhat.com> <20091203153955.GG657@nostromo.devel.redhat.com> <4B17DDB4.1080405@redhat.com> <20091203195539.GB2712@clingman.lan> Message-ID: <4B181BF0.2010600@redhat.com> On 12/03/2009 02:55 PM, Toshio Kuratomi wrote: > On Thu, Dec 03, 2009 at 10:48:04AM -0500, John Dennis wrote: >> On 12/03/2009 10:39 AM, Bill Nottingham wrote: >>> John Dennis (jdennis at redhat.com) said: >>>> The guidelines also state that an initiscript should never be marked >>>> as %config and instead import configuration settings from >>>> /etc/sysconfig/$name. But what about the case where a service may >>>> have a variety of boot dependencies depending on how it's >>>> configured? For example a service might be configured to optionally >>>> use mysql vs. postgres, or to use LDAP vs. SQL so it will have boot >>>> dependencies on particular services which cannot be hardwired ahead >>>> of time. >>> >>> The LSB spec won't help you here, alas. >> >> Right, this isn't an LSB spec issue but a Fedora packaging guideline >> issue. If a sysadmin configures the service to depend on a specific >> set of dependency services then he/she will have to edit the >> initscript, thus it should be marked %config so that this >> customization is not lost. >> > It could be that the LSB, dependency style is not flexible enough to work in > this instance. We might be able to work around this with virtual provides, > though. We do want to avoid marking init scripts as %config and eventually, > in the indefinite sense, we can use upstart's facilities to do this > sort of thing. So I'm not certain that we'd want to start encouraging > people to mix config with the initscripts yet. A more careful reading of the LSB spec might indicate this is a moot issue after all. If I understand correctly I think this can be accomplished by listing *every* optional dependency in the Should-Start list. If I'm reading it correctly the items in Should-Start will be started earlier if and only if they are enabled to start. For example if you're dependent on a SQL database and can choose between mysql and postgres in your configuration and elect to use mysql. Then the initscript would have: # Should-Start: mysql postgres and all the sysadmin must do is enable mysql to start at boot. Because mysql is enabled the mysql dependency will be honored, but the postgres dependency will not be honored because it's not enabled. Or at least that's my interpretation ... -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From notting at redhat.com Thu Dec 3 20:42:39 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 3 Dec 2009 15:42:39 -0500 Subject: [Fedora-packaging] LSB initscript ordering issues In-Reply-To: <4B181BF0.2010600@redhat.com> References: <4B17DA43.5010904@redhat.com> <20091203153955.GG657@nostromo.devel.redhat.com> <4B17DDB4.1080405@redhat.com> <20091203195539.GB2712@clingman.lan> <4B181BF0.2010600@redhat.com> Message-ID: <20091203204238.GB3002@nostromo.devel.redhat.com> John Dennis (jdennis at redhat.com) said: > >It could be that the LSB, dependency style is not flexible enough to work in > >this instance. We might be able to work around this with virtual provides, > >though. We do want to avoid marking init scripts as %config and eventually, > >in the indefinite sense, we can use upstart's facilities to do this > >sort of thing. So I'm not certain that we'd want to start encouraging > >people to mix config with the initscripts yet. > > A more careful reading of the LSB spec might indicate this is a moot > issue after all. If I understand correctly I think this can be > accomplished by listing *every* optional dependency in the > Should-Start list. > > If I'm reading it correctly the items in Should-Start will be > started earlier if and only if they are enabled to start. > > For example if you're dependent on a SQL database and can choose > between mysql and postgres in your configuration and elect to use > mysql. Then the initscript would have: > > # Should-Start: mysql postgres > > and all the sysadmin must do is enable mysql to start at boot. > Because mysql is enabled the mysql dependency will be honored, but > the postgres dependency will not be honored because it's not > enabled. Alas, not until I (or someone) gets around to fixing https://bugzilla.redhat.com/show_bug.cgi?id=98470 Should-Start is listed as optional in the spec, FWIW. Bill From jonathan.underwood at gmail.com Fri Dec 4 20:21:50 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 4 Dec 2009 20:21:50 +0000 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <4B0AB36F.9090307@redhat.com> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> Message-ID: <645d17210912041221sa5608e1k5f5c9653f16e869c@mail.gmail.com> 2009/11/23 Tom "spot" Callaway : > The Fedora Packaging Committee will have its next meeting on Wednesday, > December 2, 2009 @ 1600 UTC, in #fedora-meeting. Here is the tentative > agenda: > > * pkgconfig autorequires: > https://fedoraproject.org/wiki/PackagingDrafts/PkgconfigAutoRequires > > * Revised Emacs add-on guidelines: > https://fedoraproject.org/wiki/PackagingDrafts/EmacsPackagingRevised > > * man-pages guidelines: > https://fedoraproject.org/wiki/User:Varekova/man-pages/missing-man-pages > > * Python3 Guidelines: https://fedoraproject.org/wiki/PackagingDrafts/Python3 > > A reminder: If you have something that you want to get onto the FPC's > agenda, the procedure is documented here: > https://fedoraproject.org/wiki/Packaging:Committee#Guideline_Change_Procedure Did this meeting not happen? I don't see the minutes on the wiki..? From kevin at tummy.com Fri Dec 4 20:31:48 2009 From: kevin at tummy.com (Kevin Fenzi) Date: Fri, 4 Dec 2009 13:31:48 -0700 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <645d17210912041221sa5608e1k5f5c9653f16e869c@mail.gmail.com> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> <645d17210912041221sa5608e1k5f5c9653f16e869c@mail.gmail.com> Message-ID: <20091204133148.77c24295@ohm.scrye.com> On Fri, 4 Dec 2009 20:21:50 +0000 Jonathan Underwood wrote: > Did this meeting not happen? I don't see the minutes on the wiki..? It did: http://meetbot.fedoraproject.org/fedora-meeting/2009-12-02/fedora-meeting.2009-12-02-17.14.html kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jonathan.underwood at gmail.com Fri Dec 4 21:11:49 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 4 Dec 2009 21:11:49 +0000 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <20091204133148.77c24295@ohm.scrye.com> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> <645d17210912041221sa5608e1k5f5c9653f16e869c@mail.gmail.com> <20091204133148.77c24295@ohm.scrye.com> Message-ID: <645d17210912041311j603da39fx52026d5295cbfa99@mail.gmail.com> 2009/12/4 Kevin Fenzi : > On Fri, 4 Dec 2009 20:21:50 +0000 > Jonathan Underwood wrote: > >> Did this meeting not happen? I don't see the minutes on the wiki..? > > It did: > > http://meetbot.fedoraproject.org/fedora-meeting/2009-12-02/fedora-meeting.2009-12-02-17.14.html Ahh, thank's Kevin. Is this the new way minutes are being posted for FPC? If so, it'd be worth adding a link from https://fedoraproject.org/wiki/Packaging:Minutes to the meetbot site. J. From a.badger at gmail.com Sat Dec 5 15:19:27 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 5 Dec 2009 07:19:27 -0800 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting - Dec 2, 2009 - 1600 UTC In-Reply-To: <645d17210912041311j603da39fx52026d5295cbfa99@mail.gmail.com> References: <4B0AB286.1080805@redhat.com> <4B0AB36F.9090307@redhat.com> <645d17210912041221sa5608e1k5f5c9653f16e869c@mail.gmail.com> <20091204133148.77c24295@ohm.scrye.com> <645d17210912041311j603da39fx52026d5295cbfa99@mail.gmail.com> Message-ID: <20091205151926.GI2712@clingman.lan> On Fri, Dec 04, 2009 at 09:11:49PM +0000, Jonathan Underwood wrote: > Ahh, thank's Kevin. > > Is this the new way minutes are being posted for FPC? If so, it'd be > worth adding a link from > > https://fedoraproject.org/wiki/Packaging:Minutes > > to the meetbot site. > Updated. Thanks for mentioning the problem. I'll see if we can start using the #meetingname command so we get the logs in a packaging subdirectory as well. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mschwendt at gmail.com Sat Dec 5 17:19:41 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 5 Dec 2009 18:19:41 +0100 Subject: [Fedora-packaging] Clarification of Static Libraries packaging guidelines Message-ID: <20091205181941.600ac00f@gmail.com> $ yum list \*-static | wc -l 115 $ yum list \*-devel-static | wc -l 8 $ yum list \*-static | grep -v devel | wc -l 108 Perhaps I only have a nit-picky day, but https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries clearly mentions *-static as in foo-static - and not foo-devel-static. Could this part of the guidelines be clarified, please? Related to this ambiguity in the naming guidelines, it's kind of pointless if some packages start creating -static subpackages, which provide a virtual -devel *and* a virtual -devel-static package in addition to a shared library base package. Effectively, it implies that another package could "BuildRequires: libfoo-devel" for _static_ linking even if a shared library is available. This is exactly what the old guidelines wanted to avoid (by separating -devel and -static subpackages). From pertusus at free.fr Sat Dec 5 18:00:50 2009 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 5 Dec 2009 19:00:50 +0100 Subject: [Fedora-packaging] Clarification of Static Libraries packaging guidelines In-Reply-To: <20091205181941.600ac00f@gmail.com> References: <20091205181941.600ac00f@gmail.com> Message-ID: <20091205180049.GF4179@free.fr> On Sat, Dec 05, 2009 at 06:19:41PM +0100, Michael Schwendt wrote: > $ yum list \*-static | wc -l > 115 > $ yum list \*-devel-static | wc -l > 8 > $ yum list \*-static | grep -v devel | wc -l > 108 > > Perhaps I only have a nit-picky day, but > > https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries > > clearly mentions *-static as in foo-static - and not foo-devel-static. > Could this part of the guidelines be clarified, please? There should be no foo-devel-static. But I am not sure that there is a need to change the guideline since it doesn't mention the devel-static possibility. At some point this was unclear and some devel-static packages were done, but hopefully this is a thing from the past. > Related to this ambiguity in the naming guidelines, it's kind of pointless > if some packages start creating -static subpackages, which provide a > virtual -devel *and* a virtual -devel-static package in addition to a This should never be the case. Fist there should not be any -devel-static package, and second the -static package should not provide a virtual -devel if there are shared libraries. But once again, I think that the guidelines are clear on that subject: # Static libraries and shared libraries. In this case, the static libraries must be placed in a *-static subpackage. Separating the static libraries from the other development files in *-devel allow us to track this usage by checking which packages BuildRequire the *-static package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries. -- Pat From mschwendt at gmail.com Sat Dec 5 18:18:47 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 5 Dec 2009 19:18:47 +0100 Subject: [Fedora-packaging] Clarification of Static Libraries packaging guidelines In-Reply-To: <20091205180049.GF4179@free.fr> References: <20091205181941.600ac00f@gmail.com> <20091205180049.GF4179@free.fr> Message-ID: <20091205191847.2c9c6aa1@gmail.com> On Sat, 5 Dec 2009 19:00:50 +0100, Patrice wrote: > There should be no foo-devel-static. But I am not sure that there is a need > to change the guideline since it doesn't mention the devel-static > possibility. So, we should get rid of the six remaining -devel-static packages then. One is in F12 "updates", btw. ;) One at RPM Fusion. Though, without hanging around on IRC I still don't know whether I could simply go ahead and fix the packages for F13 devel or if this would be a case of filing tickets and waiting many months for a reaction. > But once again, I think that the guidelines are clear on that subject: Well, I do too, but that's the theory only as I've found two review requests that create the full set of libfoo, libfoo-static + virtual libfoo-devel and libfoo-devel-static in libfoo-static. From limb at jcomserv.net Mon Dec 7 13:15:26 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 07 Dec 2009 07:15:26 -0600 Subject: [Fedora-packaging] Clarification of Static Libraries packaging guidelines In-Reply-To: <20091205191847.2c9c6aa1@gmail.com> References: <20091205181941.600ac00f@gmail.com> <20091205180049.GF4179@free.fr> <20091205191847.2c9c6aa1@gmail.com> Message-ID: <4B1CFFEE.7020306@jcomserv.net> Michael Schwendt wrote: > On Sat, 5 Dec 2009 19:00:50 +0100, Patrice wrote: > > >> There should be no foo-devel-static. But I am not sure that there is a need >> to change the guideline since it doesn't mention the devel-static >> possibility. >> > > So, we should get rid of the six remaining -devel-static packages then. > One is in F12 "updates", btw. ;) One at RPM Fusion. > > Though, without hanging around on IRC I still don't know whether I could > simply go ahead and fix the packages for F13 devel or if this would be > a case of filing tickets and waiting many months for a reaction. > > I'd file the bugs, explain the problem, and include a short-ish timeline in which you expect a response or will make the change yourself. I say 2 weeks, unless the maintainer has something listed on the Vacation wiki page. Then, if the don't reply, they were warned, just do it and take care of any deps. My $0.02. -J >> But once again, I think that the guidelines are clear on that subject: >> > > Well, I do too, but that's the theory only as I've found two review > requests that create the full set of libfoo, libfoo-static + virtual > libfoo-devel and libfoo-devel-static in libfoo-static. > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- in your fear, seek only peace in your fear, seek only love -d. bowie From mschwendt at gmail.com Mon Dec 7 18:35:25 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 7 Dec 2009 19:35:25 +0100 Subject: [Fedora-packaging] Clarification of Static Libraries packaging guidelines In-Reply-To: <4B1CFFEE.7020306@jcomserv.net> References: <20091205181941.600ac00f@gmail.com> <20091205180049.GF4179@free.fr> <20091205191847.2c9c6aa1@gmail.com> <4B1CFFEE.7020306@jcomserv.net> Message-ID: <20091207193525.71338163@gmail.com> Another issue: https://bugzilla.redhat.com/buglist.cgi?quicksearch=Violation+of+the+Packaging+Guidelines+ A couple of -devel packages that provide virtual -static packages and include both the shared and static build of the same library. From jdennis at redhat.com Mon Dec 7 22:21:49 2009 From: jdennis at redhat.com (John Dennis) Date: Mon, 07 Dec 2009 17:21:49 -0500 Subject: [Fedora-packaging] file permissions, guidelines, rpmlint Message-ID: <4B1D7FFD.4020307@redhat.com> O.K. so apparently my understanding of sane file/directory permissions seems to quite divergent from rpmlint's. So I went to both the Fedora Packaging Guildelines and FHS in a attempt to resolve the discrepancy and discovered both the Guildlines and FHS offer virtually no information. * Is there a reference which states what file/directory permissions should be and a rationale? * Should rpmlint really be emitting warnings and errors for items not in the guidelines? (not just about file/directory but a number of other issues which frankly seems dubious). If rpmlint and the guidelines are divergent then should rpmlint be a recommended tool during package review? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rootoutcast at hushmail.com Tue Dec 8 01:11:39 2009 From: rootoutcast at hushmail.com (rootoutcast at hushmail.com) Date: Mon, 07 Dec 2009 18:11:39 -0700 Subject: [Fedora-packaging] New to the packaging list Message-ID: <20091208011139.AF5EE2803F@smtp.hushmail.com> I I am trying to right a .spec file for checkinstall I'm following the directions on https://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHow To I run rpmbuild -ba checkinstall.spec and get RPM build errors: File /home/makerpm/rpmbuild/SOURCES is smaller than 13 bytes Bad exit status from /var/tmp/rpm-tmp.4SyjIO (%prep) my spec file is below Name: checkinstall Version: 1.6.1 Release: 1%{?dist} Summary: Installs a compiled program from the program's source directory Group: Development/System License: GPLv2 URL: http://www.asic-linux.com.mx/~izto/checkinstall/index.php Source0: http://www.asic- linux.com.mx/~izto/checkinstall/files/source/checkinstall-1.6.1.tgz/ BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}- %{release}-XXXXXX) BuildRequires: make Requires: make install %description checkinstall will create a Slackware, RPM or Debian compatible package and install it using your distribution's standard package administration utilities. %prep %setup -q %build %configure make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT this is my first packaging attempt any help would be appreciated Thanks From supercyper at 163.com Tue Dec 8 02:45:41 2009 From: supercyper at 163.com (null) Date: Tue, 8 Dec 2009 10:45:41 +0800 (CST) Subject: [Fedora-packaging] New to the packaging list In-Reply-To: <20091208011139.AF5EE2803F@smtp.hushmail.com> References: <20091208011139.AF5EE2803F@smtp.hushmail.com> Message-ID: <30170166.595071260240341231.JavaMail.coremail@bj163app38.163.com> Source0: http://www.asic- linux.com.mx/~izto/checkinstall/files/source/checkinstall-1.6.1.tgz/ Should be http://www.asic- linux.com.mx/~izto/checkinstall/files/source/checkinstall-1.6.1.tgz ?2009-12-08?rootoutcast at hushmail.com ??? I I am trying to right a .spec file for checkinstall I'm following the directions on https://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHow To I run rpmbuild -ba checkinstall.spec and get RPM build errors: File /home/makerpm/rpmbuild/SOURCES is smaller than 13 bytes Bad exit status from /var/tmp/rpm-tmp.4SyjIO (%prep) my spec file is below Name: checkinstall Version: 1.6.1 Release: 1%{?dist} Summary: Installs a compiled program from the program's source directory Group: Development/System License: GPLv2 URL: http://www.asic-linux.com.mx/~izto/checkinstall/index.php Source0: http://www.asic- linux.com.mx/~izto/checkinstall/files/source/checkinstall-1.6.1.tgz/ BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}- %{release}-XXXXXX) BuildRequires: make Requires: make install %description checkinstall will create a Slackware, RPM or Debian compatible package and install it using your distribution's standard package administration utilities. %prep %setup -q %build %configure make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT this is my first packaging attempt any help would be appreciated Thanks -- Fedora-packaging mailing list Fedora-packaging at redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging -------------- next part -------------- An HTML attachment was scrubbed... URL: From ry at n.rix.si Tue Dec 8 02:47:44 2009 From: ry at n.rix.si (Ryan Rix) Date: Mon, 7 Dec 2009 19:47:44 -0700 Subject: [Fedora-packaging] New to the packaging list In-Reply-To: <20091208011139.AF5EE2803F@smtp.hushmail.com> References: <20091208011139.AF5EE2803F@smtp.hushmail.com> Message-ID: <200912071947.49726.ry@n.rix.si> On Mon 7 December 2009 6:11:39 pm rootoutcast at hushmail.com wrote: > I I am trying to right a .spec file for checkinstall I'm following > the directions on > https://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHow > To > > I run rpmbuild -ba checkinstall.spec and get > > RPM build errors: > File /home/makerpm/rpmbuild/SOURCES is smaller than 13 bytes > Bad exit status from /var/tmp/rpm-tmp.4SyjIO (%prep) > > my spec file is below > > Name: checkinstall > Version: 1.6.1 > Release: 1%{?dist} > Summary: Installs a compiled program from the program's source > directory > > Group: Development/System > License: GPLv2 > URL: http://www.asic-linux.com.mx/~izto/checkinstall/index.php > Source0: http://www.asic- > linux.com.mx/~izto/checkinstall/files/source/checkinstall-1.6.1.tgz/ Hi, Try removing the forward slash at the end of that line.. -- Ryan Rix Fedora KDE SIG Member, Phoenix AZ Ambassador, News KDE Beat writer New Mail address: phrkonaleash at gmail.com -> ry at n.rix.si !! http://hackersramblings.wordpress.com | http://identi.ca/phrkonaleash XMPP: phrkonaleash at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#plugaz,#fedora-kde and countless other FOSS channels. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From nicolas.mailhot at laposte.net Tue Dec 8 11:13:03 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 8 Dec 2009 12:13:03 +0100 Subject: [Fedora-packaging] file permissions, guidelines, rpmlint In-Reply-To: <4B1D7FFD.4020307@redhat.com> References: <4B1D7FFD.4020307@redhat.com> Message-ID: <81317c09df84bd3b064d002b068e3cd9.squirrel@arekh.dyndns.org> Le Lun 7 d?cembre 2009 23:21, John Dennis a ?crit : > * Should rpmlint really be emitting warnings and errors for items not in > the guidelines? (not just about file/directory but a number of other > issues which frankly seems dubious). If rpmlint and the guidelines are > divergent then should rpmlint be a recommended tool during package review? rpmlint is very convenient but 1. has been known to emit stupid warnings in the past (for example, during months it failed *any* spec file with UTF-8 inside, when UTF-8 was a Fedora choice, and while FPC had not asked for any filtering) 2. has refused to include checks for some Fedora packaging guidelines (because they were "distro specific" (ie the maintainer disagreed with FPC; today the same checks are performed by Debian's lintian on .debs, but rpmlint still ignores them) I don't think this can resolved unless the rpmlint maintainer agrees to pay more attention to Fedora packaging guidelines. Right now rpmlint is whatever rpmlint maintainer feels is right. It may align or not with our own packaging guidelines. -- Nicolas Mailhot From berrange at redhat.com Tue Dec 8 11:32:32 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Dec 2009 11:32:32 +0000 Subject: [Fedora-packaging] file permissions, guidelines, rpmlint In-Reply-To: <81317c09df84bd3b064d002b068e3cd9.squirrel@arekh.dyndns.org> References: <4B1D7FFD.4020307@redhat.com> <81317c09df84bd3b064d002b068e3cd9.squirrel@arekh.dyndns.org> Message-ID: <20091208113232.GB16596@redhat.com> On Tue, Dec 08, 2009 at 12:13:03PM +0100, Nicolas Mailhot wrote: > > > Le Lun 7 d?cembre 2009 23:21, John Dennis a ?crit : > > > * Should rpmlint really be emitting warnings and errors for items not in > > the guidelines? (not just about file/directory but a number of other > > issues which frankly seems dubious). If rpmlint and the guidelines are > > divergent then should rpmlint be a recommended tool during package review? > > rpmlint is very convenient but > > 1. has been known to emit stupid warnings in the past (for example, during > months it failed *any* spec file with UTF-8 inside, when UTF-8 was a Fedora > choice, and while FPC had not asked for any filtering) > > 2. has refused to include checks for some Fedora packaging guidelines (because > they were "distro specific" (ie the maintainer disagreed with FPC; today the > same checks are performed by Debian's lintian on .debs, but rpmlint still > ignores them) > > I don't think this can resolved unless the rpmlint maintainer agrees to pay > more attention to Fedora packaging guidelines. Right now rpmlint is whatever > rpmlint maintainer feels is right. It may align or not with our own packaging > guidelines. If rpmlint upstream doesn't want to implement our guidelines, then either we need a new tool, or try to make rpmlint support 'plugins', so that we can drop extra Fedora rules into the standard upstream set without needing to hack the main source. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From wolfy at nobugconsulting.ro Tue Dec 8 11:38:06 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Tue, 08 Dec 2009 13:38:06 +0200 Subject: [Fedora-packaging] file permissions, guidelines, rpmlint In-Reply-To: <20091208113232.GB16596@redhat.com> References: <4B1D7FFD.4020307@redhat.com> <81317c09df84bd3b064d002b068e3cd9.squirrel@arekh.dyndns.org> <20091208113232.GB16596@redhat.com> Message-ID: <4B1E3A9E.9020209@nobugconsulting.ro> Daniel P. Berrange wrote: > On Tue, Dec 08, 2009 at 12:13:03PM +0100, Nicolas Mailhot wrote: > >> Le Lun 7 d?cembre 2009 23:21, John Dennis a ?crit : >> >> >>> * Should rpmlint really be emitting warnings and errors for items not in >>> the guidelines? (not just about file/directory but a number of other >>> issues which frankly seems dubious). If rpmlint and the guidelines are >>> divergent then should rpmlint be a recommended tool during package review? >>> >> rpmlint is very convenient but >> >> 1. has been known to emit stupid warnings in the past (for example, during >> months it failed *any* spec file with UTF-8 inside, when UTF-8 was a Fedora >> choice, and while FPC had not asked for any filtering) >> >> 2. has refused to include checks for some Fedora packaging guidelines (because >> they were "distro specific" (ie the maintainer disagreed with FPC; today the >> same checks are performed by Debian's lintian on .debs, but rpmlint still >> ignores them) >> >> I don't think this can resolved unless the rpmlint maintainer agrees to pay >> more attention to Fedora packaging guidelines. Right now rpmlint is whatever >> rpmlint maintainer feels is right. It may align or not with our own packaging >> guidelines. >> > > If rpmlint upstream doesn't want to implement our guidelines, then either > we need a new tool, or try to make rpmlint support 'plugins', so that we > can drop extra Fedora rules into the standard upstream set without needing > to hack the main source. > One can use custom rules (and fedora does use custom rules) for quite a while. From jdennis at redhat.com Tue Dec 8 16:06:30 2009 From: jdennis at redhat.com (John Dennis) Date: Tue, 08 Dec 2009 11:06:30 -0500 Subject: [Fedora-packaging] file permissions, guidelines, rpmlint In-Reply-To: <81317c09df84bd3b064d002b068e3cd9.squirrel@arekh.dyndns.org> References: <4B1D7FFD.4020307@redhat.com> <81317c09df84bd3b064d002b068e3cd9.squirrel@arekh.dyndns.org> Message-ID: <4B1E7986.6010907@redhat.com> On 12/08/2009 06:13 AM, Nicolas Mailhot wrote: > > > Le Lun 7 d?cembre 2009 23:21, John Dennis a ?crit : > >> * Should rpmlint really be emitting warnings and errors for items not in >> the guidelines? (not just about file/directory but a number of other >> issues which frankly seems dubious). If rpmlint and the guidelines are >> divergent then should rpmlint be a recommended tool during package review? > > rpmlint is very convenient but > > 1. has been known to emit stupid warnings in the past (for example, during > months it failed *any* spec file with UTF-8 inside, when UTF-8 was a Fedora > choice, and while FPC had not asked for any filtering) > > 2. has refused to include checks for some Fedora packaging guidelines (because > they were "distro specific" (ie the maintainer disagreed with FPC; today the > same checks are performed by Debian's lintian on .debs, but rpmlint still > ignores them) > > I don't think this can resolved unless the rpmlint maintainer agrees to pay > more attention to Fedora packaging guidelines. Right now rpmlint is whatever > rpmlint maintainer feels is right. It may align or not with our own packaging > guidelines. > O.K. you and few others have answered one of my questions, rpmlint is divorced from our guidelines. But I had another question, specifically about file permissions and if there were guidelines. The question is in the context of system services. I've looked at the file ownership and permissions under /etc and /var/log and there doesn't seem to be a lot of consistency. My personal viewpoint is that for system services normal users should not be able to read configuration files and logs. Files/directories should have uid of root (0) and a gid belonging to the special daemon user associated with the service (which implicitly includes a special daemon group). Permissions should be set up to allow only root and the daemon user access to read and write files and search directories for that service. Normal users (e.g. users who are neither root nor in the daemon special group) should not be given read permission on files nor execute permission on directories. In other words the mode 755 is not correct for files owned by system services, it should be either 770 or 750 depending on the file/directory. Rpmlint is recommending 775 for everything as far as I can tell and I think is wrong. Is there a consensus on file permissions for "system" packages? Would others agree with the basic philosophy I outlined or do you take issue with it? FWIW I've never seen a recommendation written on this topic, it seems to be anecdotal, historical and inconsistent rather than prescribed. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rc040203 at freenet.de Tue Dec 8 17:26:11 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 08 Dec 2009 18:26:11 +0100 Subject: [Fedora-packaging] file permissions, guidelines, rpmlint In-Reply-To: <4B1E7986.6010907@redhat.com> References: <4B1D7FFD.4020307@redhat.com> <81317c09df84bd3b064d002b068e3cd9.squirrel@arekh.dyndns.org> <4B1E7986.6010907@redhat.com> Message-ID: <4B1E8C33.1070007@freenet.de> On 12/08/2009 05:06 PM, John Dennis wrote: > On 12/08/2009 06:13 AM, Nicolas Mailhot wrote: >> >> >> Le Lun 7 d?cembre 2009 23:21, John Dennis a ?crit : >> >>> * Should rpmlint really be emitting warnings and errors for items not in >>> the guidelines? (not just about file/directory but a number of other >>> issues which frankly seems dubious). If rpmlint and the guidelines are >>> divergent then should rpmlint be a recommended tool during package >>> review? >> >> rpmlint is very convenient but >> >> 1. has been known to emit stupid warnings in the past (for example, >> during >> months it failed *any* spec file with UTF-8 inside, when UTF-8 was a >> Fedora >> choice, and while FPC had not asked for any filtering) >> >> 2. has refused to include checks for some Fedora packaging guidelines >> (because >> they were "distro specific" (ie the maintainer disagreed with FPC; >> today the >> same checks are performed by Debian's lintian on .debs, but rpmlint still >> ignores them) >> >> I don't think this can resolved unless the rpmlint maintainer agrees >> to pay >> more attention to Fedora packaging guidelines. Right now rpmlint is >> whatever >> rpmlint maintainer feels is right. It may align or not with our own >> packaging >> guidelines. >> > > O.K. you and few others have answered one of my questions, rpmlint is > divorced from our guidelines. > > But I had another question, specifically about file permissions and if > there were guidelines. The question is in the context of system > services. I've looked at the file ownership and permissions under /etc > and /var/log and there doesn't seem to be a lot of consistency. > > My personal viewpoint is that for system services normal users should > not be able to read configuration files and logs. Files/directories > should have uid of root (0) and a gid belonging to the special daemon > user associated with the service (which implicitly includes a special > daemon group). Permissions should be set up to allow only root and the > daemon user access to read and write files and search directories for > that service. Normal users (e.g. users who are neither root nor in the > daemon special group) should not be given read permission on files nor > execute permission on directories. In other words the mode 755 is not > correct for files owned by system services, it should be either 770 or > 750 depending on the file/directory. Rpmlint is recommending 775 for > everything as far as I can tell and I think is wrong. Is there a > consensus on file permissions for "system" packages? The unspoken rule sofar has been: Unless a file contains "confident"/"security relevant" information it should be set 755. If it contains such infos it should not be set 755. This avoids user-side~, packager~ confusion and technical problems related to files which are required to be system-wide readable. > Would others agree > with the basic philosophy I outlined or do you take issue with it? No, I don't, for the reasons outlined above. > FWIW > I've never seen a recommendation written on this topic, it seems to be > anecdotal, historical and inconsistent rather than prescribed. It's not that inconsistant as you seem to presume :-=) Ralf From jcm at redhat.com Tue Dec 8 21:46:38 2009 From: jcm at redhat.com (Jon Masters) Date: Tue, 08 Dec 2009 16:46:38 -0500 Subject: [Fedora-packaging] file permissions, guidelines, rpmlint In-Reply-To: <4B1E8C33.1070007@freenet.de> References: <4B1D7FFD.4020307@redhat.com> <81317c09df84bd3b064d002b068e3cd9.squirrel@arekh.dyndns.org> <4B1E7986.6010907@redhat.com> <4B1E8C33.1070007@freenet.de> Message-ID: <1260308798.3027.391.camel@tonnant> On Tue, 2009-12-08 at 18:26 +0100, Ralf Corsepius wrote: > The unspoken rule sofar has been: > > Unless a file contains "confident"/"security relevant" information it > should be set 755. If it contains such infos it should not be set 755. > > This avoids user-side~, packager~ confusion and technical problems > related to files which are required to be system-wide readable. There's nothing wrong with readable configuration files unless there's something in them of a sensitive nature - no need to protect users so much from themselves that they can't see what's going on. Jon. From a.badger at gmail.com Wed Dec 9 02:49:16 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 8 Dec 2009 18:49:16 -0800 Subject: [Fedora-packaging] file permissions, guidelines, rpmlint In-Reply-To: <4B1E8C33.1070007@freenet.de> References: <4B1D7FFD.4020307@redhat.com> <81317c09df84bd3b064d002b068e3cd9.squirrel@arekh.dyndns.org> <4B1E7986.6010907@redhat.com> <4B1E8C33.1070007@freenet.de> Message-ID: <20091209024916.GB2652@clingman.lan> On Tue, Dec 08, 2009 at 06:26:11PM +0100, Ralf Corsepius wrote: > On 12/08/2009 05:06 PM, John Dennis wrote: > >On 12/08/2009 06:13 AM, Nicolas Mailhot wrote: > >> > >> > >>Le Lun 7 d?cembre 2009 23:21, John Dennis a ?crit : > >> > >>>* Should rpmlint really be emitting warnings and errors for items not in > >>>the guidelines? (not just about file/directory but a number of other > >>>issues which frankly seems dubious). If rpmlint and the guidelines are > >>>divergent then should rpmlint be a recommended tool during package > >>>review? > >> > >>rpmlint is very convenient but > >> > >>1. has been known to emit stupid warnings in the past (for example, > >>during > >>months it failed *any* spec file with UTF-8 inside, when UTF-8 was a > >>Fedora > >>choice, and while FPC had not asked for any filtering) > >> > >>2. has refused to include checks for some Fedora packaging guidelines > >>(because > >>they were "distro specific" (ie the maintainer disagreed with FPC; > >>today the > >>same checks are performed by Debian's lintian on .debs, but rpmlint still > >>ignores them) > >> > >>I don't think this can resolved unless the rpmlint maintainer agrees > >>to pay > >>more attention to Fedora packaging guidelines. Right now rpmlint is > >>whatever > >>rpmlint maintainer feels is right. It may align or not with our own > >>packaging > >>guidelines. > >> > > > >O.K. you and few others have answered one of my questions, rpmlint is > >divorced from our guidelines. > > Yes. rpmlint is required to be run on the packages by the packaging guidelines and generally the advice it gives is sensible and should be followed. However, there are times when it gives advice that is incorrect just as lint can sometimes be incorrect in its warnings about things happening in a C file. Rpmlint points out things that packagersand reviewers should consider before approving a package but sometimes that consideration leads to the conclusion that in this case, no change needs to be made. > >But I had another question, specifically about file permissions and if > >there were guidelines. The question is in the context of system > >services. I've looked at the file ownership and permissions under /etc > >and /var/log and there doesn't seem to be a lot of consistency. > > > >My personal viewpoint is that for system services normal users should > >not be able to read configuration files and logs. Files/directories > >should have uid of root (0) and a gid belonging to the special daemon > >user associated with the service (which implicitly includes a special > >daemon group). Permissions should be set up to allow only root and the > >daemon user access to read and write files and search directories for > >that service. Normal users (e.g. users who are neither root nor in the > >daemon special group) should not be given read permission on files nor > >execute permission on directories. In other words the mode 755 is not > >correct for files owned by system services, it should be either 770 or > >750 depending on the file/directory. Rpmlint is recommending 775 for > >everything as far as I can tell and I think is wrong. Is there a > >consensus on file permissions for "system" packages? > The unspoken rule sofar has been: > > Unless a file contains "confident"/"security relevant" information it > should be set 755. If it contains such infos it should not be set > 755. > > This avoids user-side~, packager~ confusion and technical problems > related to files which are required to be system-wide readable. > +1 If the files do not contain sensitive information then there's no reason to protect them with 0750 permissions. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From philipp_subx at redfish-solutions.com Thu Dec 10 19:09:22 2009 From: philipp_subx at redfish-solutions.com (Philip A. Prindeville) Date: Thu, 10 Dec 2009 11:09:22 -0800 Subject: [Fedora-packaging] Submission: Httpd module mod_proxy_html (updated) Message-ID: <4B214762.8060104@redfish-solutions.com> I have this building on FC11 (updated) and running. Seems to work fine. Just need someone to commit it. https://bugzilla.redhat.com/show_bug.cgi?id=452636 $ rpmlint ../../SPECS/mod_proxy_html.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. $ Updated the bug with new attachments (version 3.1.2). -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mod_proxy_html.spec URL: From rootoutcast at hushmail.com Fri Dec 11 20:38:03 2009 From: rootoutcast at hushmail.com (rootoutcast at hushmail.com) Date: Fri, 11 Dec 2009 13:38:03 -0700 Subject: [Fedora-packaging] New packager Message-ID: <20091211203803.C74F52803F@smtp.hushmail.com> Hi I am new to fedora packaging, I have followed the wiki as fare as setting up a fedora and bugzlla account and submitting my package. I am still unapproved for the packager group and was wondering how long the process usually takes? The reason is I uploaded the spec file and the Source rpm to rapid share and the links have a 90 day time limit, I'm concerned about the links expiring before my submission is looked at. Thanks Joey Schofield From tibbs at math.uh.edu Fri Dec 11 20:48:08 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 11 Dec 2009 14:48:08 -0600 Subject: [Fedora-packaging] New packager In-Reply-To: <20091211203803.C74F52803F@smtp.hushmail.com> (rootoutcast@hushmail.com's message of "Fri, 11 Dec 2009 13:38:03 -0700") References: <20091211203803.C74F52803F@smtp.hushmail.com> Message-ID: >>>>> "r" == rootoutcast writes: r> I am still unapproved for the packager group and was wondering how r> long the process usually takes? The process can take quite some time. It depends on whether you can snag a volunteer to look at your package. There are far more package submissions than there are reviewers; I suppose you can guess how that works out. r> The reason is I uploaded the spec file and the Source rpm to rapid r> share and the links have a 90 day time limit, It's a simple fact: most reviewers aren't going to click on rapidshare links and wait to download them. You need to make it as easy as possible on. I get the impression you might not have read through http://fedoraproject.org/wiki/Join_the_package_collection_maintainers. If you haven't, please do so; it tells you how to indicate that you need hosting for your packages. It and the documents to which it links also have many other useful and important pieces of information, such as how to participate in the review process and attract the interest of sponsors. - J< From jonathan.underwood at gmail.com Mon Dec 14 14:08:28 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 14 Dec 2009 14:08:28 +0000 Subject: [Fedora-packaging] Revised Emacs add-on guidelines In-Reply-To: <645d17210911170240v53ea4f86s29578b14f8870cf6@mail.gmail.com> References: <645d17210911071305h88141f7s28a6a97622fea6ae@mail.gmail.com> <645d17210911080226s7930fae4t642be561d25d3727@mail.gmail.com> <645d17210911080230p3595e4d4y547bdbac8aa8f8f@mail.gmail.com> <645d17210911140540q59419e81l9dc19d9a0db2a973@mail.gmail.com> <20091117041147.GC3153@clingman.lan> <645d17210911170240v53ea4f86s29578b14f8870cf6@mail.gmail.com> Message-ID: <645d17210912140608yee2de40sa3305eab0e879a99@mail.gmail.com> Hi, Since the FPC and FESCO have approved the updated emacs add-on packaging guidelines[1] can someone move the new guidelines to https://fedoraproject.org/wiki/Packaging:Emacs Thanks, Jonathan [1] http://meetbot.fedoraproject.org/fedora-meeting/2009-12-04/fesco.2009-12-04-17.00.log.html From keijser at stone-it.com Thu Dec 17 12:29:20 2009 From: keijser at stone-it.com (=?ISO-8859-1?Q?L=E9on?= Keijser) Date: Thu, 17 Dec 2009 13:29:20 +0100 Subject: [Fedora-packaging] how to check on upgrade rpm Message-ID: <1261052960.2423.19.camel@localhost.localdomain> Hi, I'm making a package of a webapp that consists mainly of php and image files. When installing the package for the first time, an '/install' directory is copied. The user accesses the webapp for the first time, configures it and has to remove the install directory for the webapp to function properly. But when doing an upgrade of the package it's not supposed to install the 'install' directory again, as the webapp will recognize the presence of the directory and fails to function afterwards. There are a number of ways on how to approach this, but what is the best method? I thought about placing these lines in the %install section: % define my_home /var/www/html/packagename if ! [ -d %{my_home} ]; then install -m 755 -d $RPM_BUILD_ROOT%{my_home}/install %define fresh_install 1 fi Then in the %files section: %if %{fresh_install} %dir %{my_home}/install %endif But that doesn't seem to work. -- L?on From limb at jcomserv.net Thu Dec 17 13:41:35 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 17 Dec 2009 07:41:35 -0600 Subject: [Fedora-packaging] how to check on upgrade rpm In-Reply-To: <1261052960.2423.19.camel@localhost.localdomain> References: <1261052960.2423.19.camel@localhost.localdomain> Message-ID: <4B2A350F.1090108@jcomserv.net> L?on Keijser wrote: > Hi, > > I'm making a package of a webapp that consists mainly of php and image > files. When installing the package for the first time, an '/install' > directory is copied. The user accesses the webapp for the first time, > configures it and has to remove the install directory for the webapp to > function properly. > > But when doing an upgrade of the package it's not supposed to install > the 'install' directory again, as the webapp will recognize the presence > of the directory and fails to function afterwards. > > There are a number of ways on how to approach this, but what is the best > method? > > I thought about placing these lines in the %install section: > > % define my_home /var/www/html/packagename > if ! [ -d %{my_home} ]; then > install -m 755 -d $RPM_BUILD_ROOT%{my_home}/install > %define fresh_install 1 > fi > > Then in the %files section: > > %if %{fresh_install} > %dir %{my_home}/install > %endif > > > But that doesn't seem to work. > > Check this out: http://docs.fedoraproject.org/drafts/rpm-guide-en/ch09s04.html#id2972291 You can create a script to test if it's an upgrade and if it is, remove the install. Such as: %post if [ "$1" = 2 ]; then rm -rf /path/to/install/thingy fi exit 0 And then maybe in $files %ghost /path/to/install/thingy But I'm not sure about the last part. No coffee yet. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie From keijser at stone-it.com Thu Dec 17 19:05:27 2009 From: keijser at stone-it.com (=?ISO-8859-1?Q?L=E9on?= Keijser) Date: Thu, 17 Dec 2009 20:05:27 +0100 Subject: [Fedora-packaging] how to check on upgrade rpm In-Reply-To: <4B2A350F.1090108@jcomserv.net> References: <1261052960.2423.19.camel@localhost.localdomain> <4B2A350F.1090108@jcomserv.net> Message-ID: <1261076727.2423.44.camel@localhost.localdomain> On Thu, 2009-12-17 at 07:41 -0600, Jon Ciesla wrote: > Check this out: > > http://docs.fedoraproject.org/drafts/rpm-guide-en/ch09s04.html#id2972291 > > You can create a script to test if it's an upgrade and if it is, remove > the install. Such as: > > %post > > if [ "$1" = 2 ]; then > > rm -rf /path/to/install/thingy > > fi > > exit 0 > I didn't know about that yet, thanks! Works like a charm. The %ghost line made yum complain a lot when installing the rpm, so i just left the subdir out and included everything in the toplevel dir. Don't know why i specified each subdir seperately in %files. -- L?on From Fedora at FamilleCollet.com Sat Dec 19 11:42:11 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sat, 19 Dec 2009 12:42:11 +0100 Subject: [Fedora-packaging] PHP Guidelines Message-ID: <4B2CBC13.7020607@FamilleCollet.com> Hi, Last draft https://fedoraproject.org/wiki/PackagingDrafts/PHP have been approved by FPC, but not change on official page ? I'd like to add a new change PEAR Packages from a non standard channel/repository A PEAR package MUST have: BuildRequires: php-channel(channelname) BuildRequires: php-pear(PEAR) Requires: php-pear(PEAR) -Requires(post): %{__pear} -Requires(postun): %{__pear} +Requires(post): php-channel(channelname) +Requires(postun): php-channel(channelname) Requires: php-channel(channelname) Provides: php-pear(channelname/foo) = %{version} This will solve issue with "channel" package uninstalled before pear package (postun scriptlet will fail) Remi. From richmattes at gmail.com Sun Dec 20 23:29:08 2009 From: richmattes at gmail.com (Rich Mattes) Date: Sun, 20 Dec 2009 18:29:08 -0500 Subject: [Fedora-packaging] Request for Guideline Clarification Message-ID: <4B2EB344.7050505@gmail.com> Hi all, I've been gathering bits and pieces of information regarding the packaging of shared libraries for a while now. As I understand it: - Normal .so libraries with versioned filenames go into the base package for a program when they exist - Unversioned .so libraries go into the -devel package -- If there are no versioned libraries for a program, should a versioned library be added or should the unversioned .so file be included in the base package? - Libraries which are used by other programs at runtime should be versioned, and in %{_libdir} -- Are there exceptions to this? When is it appropriate to leverage subdirectories and /etc/ld.so.conf.d/? - Libraries which are plugins to one specific program, and are dlopened by that program, do not need a versioned filename. They should go in their own subdierctory in %{_libdir} (e.g. /usr/lib/gstreamer-0.10) -- If packaged as seperate plugins, they should be in packages called packagename-plugins-pluginname, or something similar - All shared library filenames should begin with lib A lot of this isn't in the packaging guidelines, I think if these points could be clarified and included in the guidelines it would help to answer a lot of questions. Thanks, Rich From limb at jcomserv.net Mon Dec 21 21:31:08 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 21 Dec 2009 15:31:08 -0600 Subject: [Fedora-packaging] Request for Guideline Clarification In-Reply-To: <4B2EB344.7050505@gmail.com> References: <4B2EB344.7050505@gmail.com> Message-ID: <8716aadc06772f10732c1112146a5a6f.squirrel@secure.jcomserv.net> > Hi all, > > I've been gathering bits and pieces of information regarding the > packaging of shared libraries for a while now. As I understand it: > > - Normal .so libraries with versioned filenames go into the base package > for a program when they exist Yes. > - Unversioned .so libraries go into the -devel package Yes. > -- If there are no versioned libraries for a program, should a > versioned library be added or should the unversioned .so file be > included in the base package? Option B, I think, but someone else with more insight should chime in. . . > - Libraries which are used by other programs at runtime should be > versioned, and in %{_libdir} > -- Are there exceptions to this? When is it appropriate to leverage > subdirectories and /etc/ld.so.conf.d/? How so, by adding a path to /etc/ld.so.conf? > - Libraries which are plugins to one specific program, and are dlopened > by that program, do not need a versioned filename. They should go in > their own subdierctory in %{_libdir} (e.g. /usr/lib/gstreamer-0.10) > -- If packaged as seperate plugins, they should be in packages called > packagename-plugins-pluginname, or something similar > > - All shared library filenames should begin with lib ? > A lot of this isn't in the packaging guidelines, I think if these points > could be clarified and included in the guidelines it would help to > answer a lot of questions. If you like, you can write up a draft, and post here, or submit to the FPC. https://fedoraproject.org/wiki/Packaging:Committee ? > Thanks, > > Rich > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- in your fear, seek only peace in your fear, seek only love -d. bowie -------------- next part -------------- An HTML attachment was scrubbed... URL: From jussilehtola at fedoraproject.org Mon Dec 21 23:11:02 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Tue, 22 Dec 2009 01:11:02 +0200 Subject: [Fedora-packaging] Request for Guideline Clarification In-Reply-To: <8716aadc06772f10732c1112146a5a6f.squirrel@secure.jcomserv.net> References: <4B2EB344.7050505@gmail.com> <8716aadc06772f10732c1112146a5a6f.squirrel@secure.jcomserv.net> Message-ID: <1261437062.29908.17.camel@localhost> On Mon, 2009-12-21 at 15:31 -0600, Jon Ciesla wrote: > > - Libraries which are used by other programs at runtime should be > > versioned, and in %{_libdir} > > -- Are there exceptions to this? When is it appropriate to leverage > > subdirectories and /etc/ld.so.conf.d/? > > How so, by adding a path to /etc/ld.so.conf? At least the MPI packaging guidelines are an exception to this one: the libraries are placed in MPI flavor specific directories, e.g. %{_libdir}/openmpi/lib, which should not be visible to programs by default. Instead, it is the environment module that sets the relevant environment variables to make the libraries and runtimes usable. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org