From denis at poolshark.org Wed Oct 1 13:06:11 2008 From: denis at poolshark.org (Denis Leroy) Date: Wed, 01 Oct 2008 15:06:11 +0200 Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: <1222101610.12513.73.camel@rosebud> References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> Message-ID: <48E375C3.8050009@poolshark.org> seth vidal wrote: > On Mon, 2008-09-22 at 11:33 -0500, Bruno Wolff III wrote: >> While playing with custom repos I noticed that libgcj-devel requires a >> file from zlib-devel that isn't explicitly provided. In a mixed x86_86 / i386 >> environmentment this requires looking at the file lists to see that >> libgcj-devel-4.3.2-4.i386 needs zlib-1.2.3-18.fc9.i386 and that >> zlib-1.2.3-18.fc9.x86_64 isn't good enough. >> >> I am not sure if this is actually a bug though and if so, which package >> is at fault. I was hoping to get some guidance here on whether or not >> this is something I should bugzilla. > > I think that file dep is explicit - b/c libgcj-devel-4.3.2-4.i386 needs > the i386 version of that package - not the x86_64. do you know what is the technical reason for this dependency ? Exotic build system ? From paul at city-fan.org Wed Oct 1 15:36:43 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 01 Oct 2008 16:36:43 +0100 Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: <48E375C3.8050009@poolshark.org> References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <48E375C3.8050009@poolshark.org> Message-ID: <48E3990B.80305@city-fan.org> Denis Leroy wrote: > seth vidal wrote: >> On Mon, 2008-09-22 at 11:33 -0500, Bruno Wolff III wrote: >>> While playing with custom repos I noticed that libgcj-devel requires a >>> file from zlib-devel that isn't explicitly provided. In a mixed >>> x86_86 / i386 >>> environmentment this requires looking at the file lists to see that >>> libgcj-devel-4.3.2-4.i386 needs zlib-1.2.3-18.fc9.i386 and that >>> zlib-1.2.3-18.fc9.x86_64 isn't good enough. >>> >>> I am not sure if this is actually a bug though and if so, which package >>> is at fault. I was hoping to get some guidance here on whether or not >>> this is something I should bugzilla. >> >> I think that file dep is explicit - b/c libgcj-devel-4.3.2-4.i386 needs >> the i386 version of that package - not the x86_64. > > do you know what is the technical reason for this dependency ? Exotic > build system ? With a simple bump and rebuild of zlib (using the new rpm), zlib-devel would pick up provides of zlib-devel%{?_isa} (on i386 this would be zlib-devel(x86-32) and on x86_64 it would be zlib-devel(x86-64)). Dependencies of zlib-devel%{?_isa} could then be added in other packages where needed. Ideally there would be a mass rebuild prior to F10 of all packages where this is likely to be useful (e.g. everything providing a -devel package) that have not been rebuilt using the new rpm. This would ensure that spec files using %{?_isa} dependencies would be compatible with all supported Fedora releases after F10 goes gold. By this I mean that in F9 the expansion of the %{?_isa} macro would be empty and hence transparent, and for F10 onwards, any package that might be expected to provide %{?_isa} dependencies will do so. Without a rebuild prior to F10, it's possible for instance that a rebuild of zlib early in F11 development could lead to F11 packages having zlib-devel%{?_isa} dependencies added, but packages built from the same spec files on F10 would have broken deps because the zlib-devel%{?_isa} dependency would be unsatisfied there. Paul. From timothy.selivanow at virtualxistenz.com Wed Oct 1 23:59:24 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Wed, 01 Oct 2008 16:59:24 -0700 Subject: [Fedora-packaging] Procedure for renaming a package? Message-ID: <1222905564.3188.8.camel@himiko.beav.virtualxistenz.com> Since I have to do some updates to my (only, ) package, I'd also like to take the opportunity to change its name to something that fits the python naming guidelines better. Currently it is called 'pysvn', and I'd like to change it to 'python-pysvn'. Is there a special procedure for that, e.g. fill out some forms in triplicate, mail them to some P.O. Box in Indiana, wait 3-6 weeks, promise my unborn first child to a suspicious gnome-like old man, etc... Or is it just request the new package, and put in the obsoletes and virtual provides in the new spec? Thanks. From debarshi.ray at gmail.com Thu Oct 2 08:02:19 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Thu, 2 Oct 2008 13:32:19 +0530 Subject: [Fedora-packaging] Procedure for renaming a package? In-Reply-To: <1222905564.3188.8.camel@himiko.beav.virtualxistenz.com> References: <1222905564.3188.8.camel@himiko.beav.virtualxistenz.com> Message-ID: <3170f42f0810020102y371a8a12h984c25afe69bc41b@mail.gmail.com> > Since I have to do some updates to my (only, ) package, I'd also > like to take the opportunity to change its name to something that fits > the python naming guidelines better. Currently it is called 'pysvn', > and I'd like to change it to 'python-pysvn'. pysvn is fine. According to https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28python_modules.29 : "... There is an exception to this rule. If the upstream source has "py" (or "Py") in its name, you can use that name for the package. So, for example, pygtk is acceptable." Cheers, Debarshi From tcallawa at redhat.com Thu Oct 2 11:44:08 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 02 Oct 2008 07:44:08 -0400 Subject: [Fedora-packaging] Procedure for renaming a package? In-Reply-To: <1222905564.3188.8.camel@himiko.beav.virtualxistenz.com> References: <1222905564.3188.8.camel@himiko.beav.virtualxistenz.com> Message-ID: <1222947848.3685.14.camel@localhost.localdomain> On Wed, 2008-10-01 at 16:59 -0700, Timothy Selivanow wrote: > Since I have to do some updates to my (only, ) package, I'd also > like to take the opportunity to change its name to something that fits > the python naming guidelines better. Currently it is called 'pysvn', > and I'd like to change it to 'python-pysvn'. As was pointed out, you do not need to make this change. However, if you want to, just open a ticket with Fedora Release Engineering (http://fedorahosted.org/rel-eng) and request the renaming of the package. No wizened old men or unborn children required. ~spot From tmz at pobox.com Thu Oct 2 11:54:00 2008 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 2 Oct 2008 07:54:00 -0400 Subject: [Fedora-packaging] Broken links to initscript guidelines on Packaging/ScriptletSnippets Message-ID: <20081002115400.GB10172@inocybe.teonanacatl.org> It seems the links to the initscripts guidelines are broken on the ScriptletSnippets page. If someone with write privs has a moment, perhaps they could be fixed? https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Initscripts_Conventions -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The worst thing about history is that every time it repeats itself, the price goes up. -- Pillar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From tcallawa at redhat.com Thu Oct 2 13:26:07 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 02 Oct 2008 09:26:07 -0400 Subject: [Fedora-packaging] Broken links to initscript guidelines on Packaging/ScriptletSnippets In-Reply-To: <20081002115400.GB10172@inocybe.teonanacatl.org> References: <20081002115400.GB10172@inocybe.teonanacatl.org> Message-ID: <1222953967.3647.2.camel@localhost.localdomain> On Thu, 2008-10-02 at 07:54 -0400, Todd Zullinger wrote: > It seems the links to the initscripts guidelines are broken on the > ScriptletSnippets page. If someone with write privs has a moment, > perhaps they could be fixed? Fixed, thanks. ~spot From ville.skytta at iki.fi Thu Oct 2 19:32:15 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 2 Oct 2008 22:32:15 +0300 Subject: [Fedora-packaging] Procedure for renaming a package? In-Reply-To: <3170f42f0810020102y371a8a12h984c25afe69bc41b@mail.gmail.com> References: <1222905564.3188.8.camel@himiko.beav.virtualxistenz.com> <3170f42f0810020102y371a8a12h984c25afe69bc41b@mail.gmail.com> Message-ID: <200810022232.17296.ville.skytta@iki.fi> On Thursday 02 October 2008, Debarshi Ray wrote: > > Since I have to do some updates to my (only, ) package, I'd also > > like to take the opportunity to change its name to something that fits > > the python naming guidelines better. Currently it is called 'pysvn', > > and I'd like to change it to 'python-pysvn'. > > pysvn is fine. Right. But for other cases where renaming/replacing is more appropriate, we have documentation in the package naming guidelines: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages From petersen at redhat.com Fri Oct 3 04:35:38 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 3 Oct 2008 00:35:38 -0400 (EDT) Subject: [Fedora-packaging] package review template In-Reply-To: <1968487669.20781223008162806.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Hi Packagers, A lot of package reviewers already seem to have their own templates for doing package reviews, which is fine and well. I was thinking that this could benefit more reviewers, specially those who review less frequently or are newer to reviewing, if a link to a reference review template was added to Packaging/ReviewGuidelines that anyone could make use of. I could attach mine, which is just a trimmed version of the must and should items on the above page with "[]" checkboxes but maybe some of the top reviewer may have something better or more polished. Anyway if noone else wants to "throw the first stone" I could open a draft wiki page where we can flesh it out. Jens From rc040203 at freenet.de Fri Oct 3 05:03:51 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 03 Oct 2008 07:03:51 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1223010231.3564.815.camel@beck.corsepiu.local> On Fri, 2008-10-03 at 00:35 -0400, Jens Petersen wrote: > Hi Packagers, > > A lot of package reviewers already seem to have their own templates > for doing package reviews, which is fine and well. I was thinking > that this could benefit more reviewers, specially those who review > less frequently or are newer to reviewing, if a link to a reference > review template was added to Packaging/ReviewGuidelines that anyone > could make use of. > > I could attach mine, which is just a trimmed version of the must and > should items on the above page with "[]" checkboxes but maybe some of > the top reviewer may have something better or more polished. Anyway > if noone else wants to "throw the first stone" I could open a draft > wiki page where we can flesh it out. Do we really need this? I'd rather see reviewers, who "switch on their brains" instead of watching people who are mechanically filling out forms. I feel, we already have too many of the latter category in Fedora. Unfortunately, it's them who tend to be active. Ralf From opensource at till.name Fri Oct 3 08:04:42 2008 From: opensource at till.name (Till Maas) Date: Fri, 03 Oct 2008 10:04:42 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <1223010231.3564.815.camel@beck.corsepiu.local> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1223010231.3564.815.camel@beck.corsepiu.local> Message-ID: <200810031004.56888.opensource@till.name> On Fri October 3 2008, Ralf Corsepius wrote: > Do we really need this? I'd rather see reviewers, who "switch on their > brains" instead of watching people who are mechanically filling out > forms. I made the experience, that a review template helps to not forget to check something, especially when one does not review packages very often. It also helps a little to keep track of what was already checked in reviews that take longer than some days to complete. In case you think the review guidelines demand too many checks, then they should be adjusted. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pertusus at free.fr Fri Oct 3 08:03:18 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 3 Oct 2008 10:03:18 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <1968487669.20781223008162806.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <20081003080318.GB3270@free.fr> On Fri, Oct 03, 2008 at 12:35:38AM -0400, Jens Petersen wrote: > Hi Packagers, > > A lot of package reviewers already seem to have their own templates for doing package reviews, which is fine and well. I was thinking that this could benefit more reviewers, specially those who review less frequently or are newer to reviewing, if a link to a reference review template was added to Packaging/ReviewGuidelines that anyone could make use of. > > I could attach mine, which is just a trimmed version of the must and should items on the above page with "[]" checkboxes but maybe some of the top reviewer may have something better or more polished. Anyway if noone else wants to "throw the first stone" I could open a draft wiki page where we can flesh it out. I don't think we need that. If you have items that are not on http://fedoraproject.org/wiki/Packaging/ReviewGuidelines they could be added, but I don't think that a template would be more useful than the existing list, indeed it is up to the reviewer to pick what he thinks is important. Put it otherwise, growing his own list based on this page is, in my opinion, an important step in becoming reviewer, and a preexisting template could only hurt since the reviewer wouldn't make the effort to appropriate the guidelines. -- Pat From opensource at till.name Fri Oct 3 08:23:29 2008 From: opensource at till.name (Till Maas) Date: Fri, 03 Oct 2008 10:23:29 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <20081003080318.GB3270@free.fr> References: <1968487669.20781223008162806.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081003080318.GB3270@free.fr> Message-ID: <200810031023.39448.opensource@till.name> On Fri October 3 2008, Patrice Dumas wrote: > I don't think we need that. If you have items that are not on > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines > they could be added, but I don't think that a template would be more There are a lot of items that are in the Packaging Guidelines, Naming Guidelines, and the Packaging Guidelines for some special packages (python, java, perl, ...) that are not summarised in the Review Guidelines. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From rc040203 at freenet.de Fri Oct 3 09:00:35 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 03 Oct 2008 11:00:35 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <200810031004.56888.opensource@till.name> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1223010231.3564.815.camel@beck.corsepiu.local> <200810031004.56888.opensource@till.name> Message-ID: <1223024435.3564.826.camel@beck.corsepiu.local> On Fri, 2008-10-03 at 10:04 +0200, Till Maas wrote: > On Fri October 3 2008, Ralf Corsepius wrote: > > > Do we really need this? I'd rather see reviewers, who "switch on their > > brains" instead of watching people who are mechanically filling out > > forms. > > I made the experience, that a review template helps to not forget to check > something, especially when one does not review packages very often. It also > helps a little to keep track of what was already checked in reviews that take > longer than some days to complete. In case you think the review guidelines > demand too many checks, then they should be adjusted. Well, yes, I think the guidelines have grown fat and bloated. However, one of my actual point is a bit different: Once one starts formulating such a "template", people will start to nit-pick and to argue on (missing) details (e.g. corner-cases) and in longer terms will start to demand for "laws", "regulations" and "forms". Such demands will typically originate from people who don't actually understand why certain "guidelines" exist, but reduce "guidelines" to "formal bureaucratic regulations". Ralf From pertusus at free.fr Fri Oct 3 09:26:41 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 3 Oct 2008 11:26:41 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <200810031023.39448.opensource@till.name> References: <1968487669.20781223008162806.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081003080318.GB3270@free.fr> <200810031023.39448.opensource@till.name> Message-ID: <20081003092640.GE3270@free.fr> On Fri, Oct 03, 2008 at 10:23:29AM +0200, Till Maas wrote: > On Fri October 3 2008, Patrice Dumas wrote: > > > I don't think we need that. If you have items that are not on > > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines > > they could be added, but I don't think that a template would be more > > There are a lot of items that are in the Packaging Guidelines, Naming > Guidelines, and the Packaging Guidelines for some special packages (python, > java, perl, ...) that are not summarised in the Review Guidelines. Then what could be interesting is to have something lilke Review Guidelines for those languages, though only with the specific bits. -- Pat From opensource at till.name Fri Oct 3 09:34:51 2008 From: opensource at till.name (Till Maas) Date: Fri, 03 Oct 2008 11:34:51 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <1223024435.3564.826.camel@beck.corsepiu.local> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <200810031004.56888.opensource@till.name> <1223024435.3564.826.camel@beck.corsepiu.local> Message-ID: <200810031134.56974.opensource@till.name> On Fri October 3 2008, Ralf Corsepius wrote: > However, one of my actual point is a bit different: Once one starts > formulating such a "template", people will start to nit-pick and to > argue on (missing) details (e.g. corner-cases) and in longer terms will > start to demand for "laws", "regulations" and "forms". I guess we have different pictures about such a template. For me it would be an itemized list, where each item is a summary of one guideline from all the Guideline documents, maybe with an URL that links to the specific guideline. The nit-picking should then only affect the normal guidelines. > Such demands will typically originate from people who don't actually > understand why certain "guidelines" exist, but reduce "guidelines" to > "formal bureaucratic regulations". I am one of these who do not lnow why certain guidelines exist, but this is imho another problem, because it is not explained for most of the guidelines, why they exist. Iirc someone already suggested that each guideline should be explained, but I guess the one who know the reasons, do not have the time to explain them. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From rc040203 at freenet.de Fri Oct 3 09:48:07 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 03 Oct 2008 11:48:07 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <200810031134.56974.opensource@till.name> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <200810031004.56888.opensource@till.name> <1223024435.3564.826.camel@beck.corsepiu.local> <200810031134.56974.opensource@till.name> Message-ID: <1223027287.3564.848.camel@beck.corsepiu.local> On Fri, 2008-10-03 at 11:34 +0200, Till Maas wrote: > On Fri October 3 2008, Ralf Corsepius wrote: > > > However, one of my actual point is a bit different: Once one starts > > formulating such a "template", people will start to nit-pick and to > > argue on (missing) details (e.g. corner-cases) and in longer terms will > > start to demand for "laws", "regulations" and "forms". > > I guess we have different pictures about such a template. For me it would be > an itemized list, where each item is a summary of one guideline from all the > Guideline documents, maybe with an URL that links to the specific guideline. > The nit-picking should then only affect the normal guidelines. Let me put it differently: I am referring to certain particular people, of whom I find it very obious that they have no clue about what they are doing in reviews. > > Such demands will typically originate from people who don't actually > > understand why certain "guidelines" exist, but reduce "guidelines" to > > "formal bureaucratic regulations". > > I am one of these who do not lnow why certain guidelines exist, but this is > imho another problem, because it is not explained for most of the guidelines, > why they exist. Well, where is the problem? Restrict yourself to reviewing packages you understand and don't review packages you don't understand rsp. ask if you don't understand details. Ralf From dominik at greysector.net Fri Oct 3 10:49:17 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 3 Oct 2008 12:49:17 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <1223027287.3564.848.camel@beck.corsepiu.local> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <200810031004.56888.opensource@till.name> <1223024435.3564.826.camel@beck.corsepiu.local> <200810031134.56974.opensource@till.name> <1223027287.3564.848.camel@beck.corsepiu.local> Message-ID: <20081003104916.GA2669@mokona.greysector.net> On Friday, 03 October 2008 at 11:48, Ralf Corsepius wrote: > On Fri, 2008-10-03 at 11:34 +0200, Till Maas wrote: > > On Fri October 3 2008, Ralf Corsepius wrote: > > > > > However, one of my actual point is a bit different: Once one starts > > > formulating such a "template", people will start to nit-pick and to > > > argue on (missing) details (e.g. corner-cases) and in longer terms will > > > start to demand for "laws", "regulations" and "forms". > > > > I guess we have different pictures about such a template. For me it would be > > an itemized list, where each item is a summary of one guideline from all the > > Guideline documents, maybe with an URL that links to the specific guideline. > > The nit-picking should then only affect the normal guidelines. > Let me put it differently: I am referring to certain particular people, > of whom I find it very obious that they have no clue about what they are > doing in reviews. Oh, how I hate such vague accusations. Ralf! Please tell us exactly who you're referring to and what *exactly* makes you think they have no clue. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From pertusus at free.fr Fri Oct 3 14:02:03 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 3 Oct 2008 16:02:03 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <20081003104916.GA2669@mokona.greysector.net> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <200810031004.56888.opensource@till.name> <1223024435.3564.826.camel@beck.corsepiu.local> <200810031134.56974.opensource@till.name> <1223027287.3564.848.camel@beck.corsepiu.local> <20081003104916.GA2669@mokona.greysector.net> Message-ID: <20081003140203.GA3174@free.fr> On Fri, Oct 03, 2008 at 12:49:17PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > Oh, how I hate such vague accusations. Ralf! Please tell us exactly who > you're referring to and what *exactly* makes you think they have no clue. I have the same feeling than Ralf, some reviewer just do superficial reviewing without really looking at the relevant details. I won't tell names. I also think that it was much less the case in the past, say, roughly in the extras days. That being said, this is not really relevant to the issue here, I mean, template or not this issue will remain. And I think that I was in the category of the people who 'have no clue' when I did my first packages... Maybe the sponsor should look over sponsoree shoulder for some time until the packager is knowledgable enough about packaging that he can do reviews with an understanding of what he is doing, and not applying some cookbook recipes (like look at rpmlint and it's done). This is not an easy issue, though, especially since many veteran packagers from the beginning of fedora extras don't seem to show a lot of activity these days in the reviews. -- Pat From limb at jcomserv.net Fri Oct 3 14:17:17 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 3 Oct 2008 09:17:17 -0500 (CDT) Subject: [Fedora-packaging] package review template In-Reply-To: <20081003140203.GA3174@free.fr> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <200810031004.56888.opensource@till.name> <1223024435.3564.826.camel@beck.corsepiu.local> <200810031134.56974.opensource@till.name> <1223027287.3564.848.camel@beck.corsepiu.local> <20081003104916.GA2669@mokona.greysector.net> <20081003140203.GA3174@free.fr> Message-ID: <34168.198.175.55.5.1223043437.squirrel@mail.jcomserv.net> > On Fri, Oct 03, 2008 at 12:49:17PM +0200, Dominik 'Rathann' Mierzejewski > wrote: >> >> Oh, how I hate such vague accusations. Ralf! Please tell us exactly who >> you're referring to and what *exactly* makes you think they have no >> clue. > > I have the same feeling than Ralf, some reviewer just do superficial > reviewing without really looking at the relevant details. I won't tell > names. I also think that it was much less the case in the past, say, > roughly in the extras days. Are there any specific deficiencies you find particularly troubling? I suppose you can't really post links if you don't want to name names, but could you characterize something in general terms? Not looking to start a flamewar or witchhunt, just trying to make sure I understand the problem. > That being said, this is not really relevant to the issue here, I mean, > template or not this issue will remain. And I think that I was in the > category of the people who 'have no clue' when I did my first > packages... > > Maybe the sponsor should look over sponsoree shoulder for some time > until the packager is knowledgable enough about packaging that he can > do reviews with an understanding of what he is doing, and not applying > some cookbook recipes (like look at rpmlint and it's done). > > This is not an easy issue, though, especially since many veteran > packagers from the beginning of fedora extras don't seem to show a lot > of activity these days in the reviews. > > -- > Pat > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- novus ordo absurdum From berrange at redhat.com Fri Oct 3 14:11:56 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 3 Oct 2008 15:11:56 +0100 Subject: [Fedora-packaging] package review template In-Reply-To: <20081003140203.GA3174@free.fr> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <200810031004.56888.opensource@till.name> <1223024435.3564.826.camel@beck.corsepiu.local> <200810031134.56974.opensource@till.name> <1223027287.3564.848.camel@beck.corsepiu.local> <20081003104916.GA2669@mokona.greysector.net> <20081003140203.GA3174@free.fr> Message-ID: <20081003141156.GB18995@redhat.com> On Fri, Oct 03, 2008 at 04:02:03PM +0200, Patrice Dumas wrote: > On Fri, Oct 03, 2008 at 12:49:17PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > > > Oh, how I hate such vague accusations. Ralf! Please tell us exactly who > > you're referring to and what *exactly* makes you think they have no clue. > > I have the same feeling than Ralf, some reviewer just do superficial > reviewing without really looking at the relevant details. I won't tell > names. I also think that it was much less the case in the past, say, > roughly in the extras days. I think you're looking at this from the wrong point of view. The current packaging review guidelines are really huge, and take a long time to wade though. Some of them really can be just reduced to bullet point checklist items, while others need intelligent thought on the part of the reviewer. By providing a base template for package review, you make it easier to check off the really simple items, allowing more time to be focused on the ones without simple yes/no answers. If you want more in depth reviews you have to make the process more time efficient, otherwise people will inevitably just look at the superficial yes/no parts of the review. Refusing to take the tedium out of the review process by not providing the base review templates, is just counter-productive because as the initial poster pointed out, people just create their own templates which may or not not actually match current guidelines. We should embrace the the defacto standard practice by providing official review templates so we can ensure they're always update, and provide incentives to get more indepth reviews from people. 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 pertusus at free.fr Fri Oct 3 17:20:17 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 3 Oct 2008 19:20:17 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <34168.198.175.55.5.1223043437.squirrel@mail.jcomserv.net> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <200810031004.56888.opensource@till.name> <1223024435.3564.826.camel@beck.corsepiu.local> <200810031134.56974.opensource@till.name> <1223027287.3564.848.camel@beck.corsepiu.local> <20081003104916.GA2669@mokona.greysector.net> <20081003140203.GA3174@free.fr> <34168.198.175.55.5.1223043437.squirrel@mail.jcomserv.net> Message-ID: <20081003172017.GA2779@free.fr> On Fri, Oct 03, 2008 at 09:17:17AM -0500, Jon Ciesla wrote: > > > Not looking to start a flamewar or witchhunt, just trying to make sure I > understand the problem. Sometime the reviewer don't check the correctness of packaging but only that it superficially complies with the guidelines. It always involves not reviewing in more depth than what the guidelines oblige (and correspondingly whining when an issue that is not in the guidelines is pointed at). And sometime it is only rpmlint output that is commented. But this is another issue, really. -- Pat From pertusus at free.fr Fri Oct 3 17:28:47 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 3 Oct 2008 19:28:47 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <20081003141156.GB18995@redhat.com> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <200810031004.56888.opensource@till.name> <1223024435.3564.826.camel@beck.corsepiu.local> <200810031134.56974.opensource@till.name> <1223027287.3564.848.camel@beck.corsepiu.local> <20081003104916.GA2669@mokona.greysector.net> <20081003140203.GA3174@free.fr> <20081003141156.GB18995@redhat.com> Message-ID: <20081003172847.GB2779@free.fr> On Fri, Oct 03, 2008 at 03:11:56PM +0100, Daniel P. Berrange wrote: > > I think you're looking at this from the wrong point of view. The current > packaging review guidelines are really huge, and take a long time to > wade though. Some of them really can be just reduced to bullet point > checklist items, while others need intelligent thought on the part of > the reviewer. I can't see the point. And you are forgetting everything that is not in the guidelines and is still important. > By providing a base template for package review, you make it easier to > check off the really simple items, allowing more time to be focused on > the ones without simple yes/no answers. But simple items are always simple to check off, template or not. And simple items that are simple for all packages aren't really existing. Simple items that allow for automation are already automated (in rpmlint). > If you want more in depth > reviews you have to make the process more time efficient, otherwise people > will inevitably just look at the superficial yes/no parts of the review. I completly disagree. More in depth review is achieved if the review looks after quality and not time. Time efficiency is achieved by automation, when possible, and also reducing the amount of guidelines, not by using templates. > Refusing to take the tedium out of the review process by not providing > the base review templates, is just counter-productive because as the > initial poster pointed out, people just create their own templates which > may or not not actually match current guidelines. We should embrace the It is not what the initial poster says. He, like other seasonned packagers has digested the guidelines and found the point that are the most problematic in his view. > the defacto standard practice by providing official review templates so > we can ensure they're always update, and provide incentives to get more > indepth reviews from people. I don't think it will provide more incentives to do in-depth reviews. I honestly don't know what could achieve that, though. And maybe I am completly wrong and quick and dirty reviews are better than in-depth but costly ones. -- Pat From cweyl at alumni.drew.edu Fri Oct 3 19:21:04 2008 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 3 Oct 2008 12:21:04 -0700 Subject: [Fedora-packaging] time for a review-oh-matic? Message-ID: <7dd7ab490810031221p306a7883hb9216f3e7fc4c6af@mail.gmail.com> So, building on the spirited debate going on with respect to a suggested review template, is it time for a review-oh-matic type service? Many of the things we do for reviews are the same. Check it builds in mock (koji scratch), check the srpm sources against upstream, look @ rpmlint, look at the file lists, etc, etc... Wouldn't it make all our lives to have a simple little tool that a packager could submit a srpm for review to. It could then, say (and off the top of my head): 1) extract the spec, and push it + the srpm somewhere 2) file a review bug 2) kick off a koji scratch build 3) post a link to the build, success/failure, build logs (a la the FTBFS overlord) ==> success, pull the built rpms, and post to the review bug: * rpmlint, requires/provides * md5/sha1 of srpm provided source against upstream * a partial template, good bad, etc. Provisions could be made for dependencies -- e.g. pass blocking review bug; won't try to do any of the koji bits until the blocking bug(s) is closed. As the review process goes on, new srpms could be submitted against the same review and have the same automatic bits run. This certainly isn't intended to automatically review and approve packages, and wouldn't be an excuse for reviewers to just rubber stamp. But it certainly could make the process a little less painful and more reliable by consistently automating those bits that it's feasible to. -Chris -- Chris Weyl Ex astris, scientia From pertusus at free.fr Fri Oct 3 19:34:37 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 3 Oct 2008 21:34:37 +0200 Subject: [Fedora-packaging] time for a review-oh-matic? In-Reply-To: <7dd7ab490810031221p306a7883hb9216f3e7fc4c6af@mail.gmail.com> References: <7dd7ab490810031221p306a7883hb9216f3e7fc4c6af@mail.gmail.com> Message-ID: <20081003193437.GC2779@free.fr> On Fri, Oct 03, 2008 at 12:21:04PM -0700, Chris Weyl wrote: > So, building on the spirited debate going on with respect to a > suggested review template, is it time for a review-oh-matic type > service? Would be indeed very nice. -- Pat From rc040203 at freenet.de Fri Oct 3 19:48:38 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 03 Oct 2008 21:48:38 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <20081003104916.GA2669@mokona.greysector.net> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <200810031004.56888.opensource@till.name> <1223024435.3564.826.camel@beck.corsepiu.local> <200810031134.56974.opensource@till.name> <1223027287.3564.848.camel@beck.corsepiu.local> <20081003104916.GA2669@mokona.greysector.net> Message-ID: <1223063318.3564.881.camel@beck.corsepiu.local> On Fri, 2008-10-03 at 12:49 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Friday, 03 October 2008 at 11:48, Ralf Corsepius wrote: > > On Fri, 2008-10-03 at 11:34 +0200, Till Maas wrote: > > > On Fri October 3 2008, Ralf Corsepius wrote: > > > > > > > However, one of my actual point is a bit different: Once one starts > > > > formulating such a "template", people will start to nit-pick and to > > > > argue on (missing) details (e.g. corner-cases) and in longer terms will > > > > start to demand for "laws", "regulations" and "forms". > > > > > > I guess we have different pictures about such a template. For me it would be > > > an itemized list, where each item is a summary of one guideline from all the > > > Guideline documents, maybe with an URL that links to the specific guideline. > > > The nit-picking should then only affect the normal guidelines. > > > Let me put it differently: I am referring to certain particular people, > > of whom I find it very obious that they have no clue about what they are > > doing in reviews. > > Oh, how I hate such vague accusations. Ralf! Please tell us exactly who > you're referring to and what *exactly* makes you think they have no clue. I do not intend to flame people and therefore will not mention any names here. Ralf From berrange at redhat.com Fri Oct 3 19:55:22 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 3 Oct 2008 20:55:22 +0100 Subject: [Fedora-packaging] time for a review-oh-matic? In-Reply-To: <7dd7ab490810031221p306a7883hb9216f3e7fc4c6af@mail.gmail.com> References: <7dd7ab490810031221p306a7883hb9216f3e7fc4c6af@mail.gmail.com> Message-ID: <20081003195522.GG23876@redhat.com> On Fri, Oct 03, 2008 at 12:21:04PM -0700, Chris Weyl wrote: > So, building on the spirited debate going on with respect to a > suggested review template, is it time for a review-oh-matic type > service? > > Many of the things we do for reviews are the same. Check it builds in > mock (koji scratch), check the srpm sources against upstream, look @ > rpmlint, look at the file lists, etc, etc... Wouldn't it make all our > lives to have a simple little tool that a packager could submit a srpm > for review to. It could then, say (and off the top of my head): > > 1) extract the spec, and push it + the srpm somewhere > 2) file a review bug > 2) kick off a koji scratch build > 3) post a link to the build, success/failure, build logs (a la the > FTBFS overlord) > ==> success, pull the built rpms, and post to the review bug: > * rpmlint, requires/provides > * md5/sha1 of srpm provided source against upstream > * a partial template, good bad, etc. If you want to get really clever make a database to back this whole thing. Automate as many of the review points as possible and put the results into the database. Leave humans to review the points which need intelligent thought, and have some way to record their decisions for each point, if clarification was needed. eg for an unusual license the DB might storage a comment providing justification for the license being valid in Fedora. Or for each rpmlint check record the pass/warn/error state, and for ones which don't pass again allow for the review to addd a comment justifying why the warn/error is ok to be ignored, or why it must be fixed. Now fast forward a short while, and have it automatically re-run all checks for the automatable review points and report on changes. We focus alot on initial review, but have very little, if any, oversight' for ongoing package changes. Plenty of specfiles bit-rot and drift out of compliance with review guidelines. Of course this is all a huge job and I'm not volunteering to write it, but I think more formal automation in the package review process would be very beneficial, particularly if it could help us track or identify changes post-review. 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 rc040203 at freenet.de Fri Oct 3 21:17:38 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 03 Oct 2008 23:17:38 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <34168.198.175.55.5.1223043437.squirrel@mail.jcomserv.net> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <200810031004.56888.opensource@till.name> <1223024435.3564.826.camel@beck.corsepiu.local> <200810031134.56974.opensource@till.name> <1223027287.3564.848.camel@beck.corsepiu.local> <20081003104916.GA2669@mokona.greysector.net> <20081003140203.GA3174@free.fr> <34168.198.175.55.5.1223043437.squirrel@mail.jcomserv.net> Message-ID: <1223068658.3564.964.camel@beck.corsepiu.local> On Fri, 2008-10-03 at 09:17 -0500, Jon Ciesla wrote: > > On Fri, Oct 03, 2008 at 12:49:17PM +0200, Dominik 'Rathann' Mierzejewski > > wrote: > >> > >> Oh, how I hate such vague accusations. Ralf! Please tell us exactly who > >> you're referring to and what *exactly* makes you think they have no > >> clue. > > > > I have the same feeling than Ralf, some reviewer just do superficial > > reviewing without really looking at the relevant details. I won't tell > > names. I also think that it was much less the case in the past, say, > > roughly in the extras days. > > Are there any specific deficiencies you find particularly troubling? Yes, low quality and/or carelessly packaged packages making it in to Fedora. > I > suppose you can't really post links if you don't want to name names, Right, I do not want to post names, here. > but > could you characterize something in general terms? This is difficult to answer - Let me try it this way: The background behind reviews and the sponsorship model had been "quality of packaging". From this, the FPG had been developed, aiming at "best practices" to improve quality of packaging, quality of packages, seamless integration into the distro ... etc. This basically works, except that this has attracted * people who take the FPG as a "law" and are trying to make a career as "auxiliary/volunteer law enforcement guard/officer". For them, the "regulations" are the objective, not the packages nor the distro. * "mere bureaucrats". People who need forms and regulations for everything, everywhere, but don't think about what they are doing. For then, "the forms" are the objective, not the packages nor the distro. Note: I am not talking about diverging individual opinions or personal preferences during reviews, nor am I referring to "newcomer/newbie reviews". I am referring to people who mix up the actual purpose of the reviews with the review process itself. > > That being said, this is not really relevant to the issue here, I mean, > > template or not this issue will remain. And I think that I was in the > > category of the people who 'have no clue' when I did my first > > packages... > > > > Maybe the sponsor should look over sponsoree shoulder for some time > > until the packager is knowledgable enough about packaging that he can > > do reviews with an understanding of what he is doing, and not applying > > some cookbook recipes (like look at rpmlint and it's done). > > > > This is not an easy issue, though, especially since many veteran > > packagers from the beginning of fedora extras don't seem to show a lot > > of activity these days in the reviews. My reasons of not participating into reviews as much as I once did are: * Fedora bureaucracy and Fedora infrastructure issues have reached an extend, maintaining my packages in Fedora consumes up all time I have available for contributions to Fedora => Not much time left for reviews. * Most of the packages, which have been submitted in recent past, are mostly non-interesting to me. Most of the packages I am interested in are part of Fedora. * My general interest in the Fedora project and the Fedora distro have decreased over all these years. Fedora once had been an exciting project, but the way things have evolved are gradually driving me away. => I unfroze activities, I had suspended due Fedora (e.g. contributing to 3rd party repos). Ralf From cweyl at alumni.drew.edu Fri Oct 3 22:09:53 2008 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 3 Oct 2008 15:09:53 -0700 Subject: [Fedora-packaging] time for a review-oh-matic? In-Reply-To: <20081003195522.GG23876@redhat.com> References: <7dd7ab490810031221p306a7883hb9216f3e7fc4c6af@mail.gmail.com> <20081003195522.GG23876@redhat.com> Message-ID: <7dd7ab490810031509w49a3598u9e30eb44c12d55f8@mail.gmail.com> On Fri, Oct 3, 2008 at 12:55 PM, Daniel P. Berrange wrote: > On Fri, Oct 03, 2008 at 12:21:04PM -0700, Chris Weyl wrote: >> So, building on the spirited debate going on with respect to a >> suggested review template, is it time for a review-oh-matic type >> service? [...snip...] > Of course this is all a huge job and I'm not volunteering to write > it, but I think more formal automation in the package review process > would be very beneficial, particularly if it could help us track or > identify changes post-review. Also a good project -- but one, I think, whose scope and goals are different than a "just automate the brainless, repetitive tasks" sorta deal :-) -Chris -- Chris Weyl Ex astris, scientia From opensource at till.name Sat Oct 4 20:12:26 2008 From: opensource at till.name (Till Maas) Date: Sat, 04 Oct 2008 22:12:26 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <20081003172847.GB2779@free.fr> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081003141156.GB18995@redhat.com> <20081003172847.GB2779@free.fr> Message-ID: <200810042212.36044.opensource@till.name> On Fri October 3 2008, Patrice Dumas wrote: > On Fri, Oct 03, 2008 at 03:11:56PM +0100, Daniel P. Berrange wrote: > > I think you're looking at this from the wrong point of view. The current > > packaging review guidelines are really huge, and take a long time to > > wade though. Some of them really can be just reduced to bullet point > > checklist items, while others need intelligent thought on the part of > > the reviewer. > > I can't see the point. And you are forgetting everything that is not in > the guidelines and is still important. Imho the mistake here is, that it is not documented in the guidelines. If there are secret important issues that need to be checked, where should the new reviewers come from? > > By providing a base template for package review, you make it easier to > > check off the really simple items, allowing more time to be focused on > > the ones without simple yes/no answers. > > But simple items are always simple to check off, template or not. And > simple items that are simple for all packages aren't really existing. > Simple items that allow for automation are already automated (in > rpmlint). Even simple items can be easily forgotten, if it is a PITA to find them all in the huge collection of Guidelines. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pertusus at free.fr Sat Oct 4 21:45:54 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 4 Oct 2008 23:45:54 +0200 Subject: [Fedora-packaging] package review template In-Reply-To: <200810042212.36044.opensource@till.name> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081003141156.GB18995@redhat.com> <20081003172847.GB2779@free.fr> <200810042212.36044.opensource@till.name> Message-ID: <20081004214554.GA2670@free.fr> On Sat, Oct 04, 2008 at 10:12:26PM +0200, Till Maas wrote: > > Imho the mistake here is, that it is not documented in the guidelines. If > there are secret important issues that need to be checked, where should the > new reviewers come from? It is not secret, it is specific for a package or a class of packages. It comes from the brain. This is especially true for the integration issues that cannot all be in the guidelines. As a side note, if there was only things that are in the guidelines and can be put on a check list, packaging and reviewing packages would be very boring ;-) > Even simple items can be easily forgotten, if it is a PITA to find them all in > the huge collection of Guidelines. A template won't help, but removing things from the guidelines or arranging the guidelines to be easier to read. -- Pat From petersen at redhat.com Mon Oct 6 05:52:34 2008 From: petersen at redhat.com (Jens Petersen) Date: Mon, 6 Oct 2008 01:52:34 -0400 (EDT) Subject: [Fedora-packaging] time for a review-oh-matic? In-Reply-To: <2062441273.304091223272309699.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1401820817.304131223272354389.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> That's a great suggestion, Chris! I feel Fedora needs this and it would certainly make a good project. Jens From petersen at redhat.com Mon Oct 6 06:45:56 2008 From: petersen at redhat.com (Jens Petersen) Date: Mon, 6 Oct 2008 02:45:56 -0400 (EDT) Subject: [Fedora-packaging] package review template In-Reply-To: <22002703.308501223275106710.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1099052182.308951223275555986.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Thanks for all the comments following up to the original post. Since there seems to be a number of people who think having a template would be useful, I created the following draft page: https://fedoraproject.org/wiki/PackagingDrafts/ReviewTemplate If you are an experienced reviewer, feel free to improve or change the wording of the text and to add other template items you feel are missing. It occurs to me though that it might be better just to merge this into the current http://fedoraproject.org/wiki/Packaging/ReviewGuidelines page, otherwise it may just become one more duplication of information, that will have to be kept in sync. So I would like to see Packaging/ReviewGuidelines formatted or presented in such a way that it could used by copy'n'paste as a template for the formal part of the review. Jens From luca at foppiano.org Tue Oct 7 09:02:55 2008 From: luca at foppiano.org (Luca Foppiano) Date: Tue, 07 Oct 2008 11:02:55 +0200 Subject: [Fedora-packaging] looking for a sponsor and review ;) Message-ID: <1223370175.3900.24.camel@sboing.byte-code.lan> hi all ;-) I don't know if this is the right place to ask, but I submitted a package request review and I'm looking for a sponsor. The package is symbolic (https://fedorahosted.org/symbolic) and my request is here [1]. I think the spec file is pretty good, but I'm not sure it's perfect. Thanks in advance. Luca [1] https://bugzilla.redhat.com/show_bug.cgi?id=465478 -- Today is Setting Orange, the 61st day of Bureaucracy in the YOLD 3174 You will be married within a year. From rjones at redhat.com Tue Oct 7 09:21:30 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 7 Oct 2008 10:21:30 +0100 Subject: [Fedora-packaging] package review template In-Reply-To: <20081003141156.GB18995@redhat.com> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <200810031004.56888.opensource@till.name> <1223024435.3564.826.camel@beck.corsepiu.local> <200810031134.56974.opensource@till.name> <1223027287.3564.848.camel@beck.corsepiu.local> <20081003104916.GA2669@mokona.greysector.net> <20081003140203.GA3174@free.fr> <20081003141156.GB18995@redhat.com> Message-ID: <20081007092130.GA8763@amd.home.annexia.org> On Fri, Oct 03, 2008 at 03:11:56PM +0100, Daniel P. Berrange wrote: > I think you're looking at this from the wrong point of view. The current > packaging review guidelines are really huge, and take a long time to > wade though. Some of them really can be just reduced to bullet point > checklist items, while others need intelligent thought on the part of > the reviewer. It's actually worse than you state ... some of them are checked just fine by rpm/rpmlint, and so don't need to be checked at all. eg: rpmlint checks the License field is valid and rpm checks that there are no duplicate files in %files, so both of those are unnecessary. rpmlint could check a whole lot more too, eg. upstream URL exists, source matches tarball, all the pkgconfig stuff, all the ldconfig stuff, %doc includes license, license matches source, etc etc (not that I'm volunteering to do all that work). Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From tibbs at math.uh.edu Tue Oct 7 13:17:28 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Oct 2008 08:17:28 -0500 Subject: [Fedora-packaging] package review template In-Reply-To: <20081007092130.GA8763@amd.home.annexia.org> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <200810031004.56888.opensource@till.name> <1223024435.3564.826.camel@beck.corsepiu.local> <200810031134.56974.opensource@till.name> <1223027287.3564.848.camel@beck.corsepiu.local> <20081003104916.GA2669@mokona.greysector.net> <20081003140203.GA3174@free.fr> <20081003141156.GB18995@redhat.com> <20081007092130.GA8763@amd.home.annexia.org> Message-ID: >>>>> "RWMJ" == Richard W M Jones writes: RWMJ> eg: rpmlint checks the License field is valid and rpm checks RWMJ> that there are no duplicate files in %files, so both of those RWMJ> are unnecessary. Well, 1) rpmlint doesn't check that the license field is correct; it only makes sure its syntax is valid. A human actually needs to look at what's in the tarball. 2) You actually have to look closely at the build output to notice the rpm complaint about there not being duplicates in %files, because it doesn't terminate the build or even complain that loudly. If a human doesn't do the check, the check doesn't get done. The automated tools are just tools. Someone actually has to interpret the results. - J< From rdieter at math.unl.edu Tue Oct 7 13:50:54 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 07 Oct 2008 08:50:54 -0500 Subject: [Fedora-packaging] looking for a sponsor and review ;) In-Reply-To: <1223370175.3900.24.camel@sboing.byte-code.lan> References: <1223370175.3900.24.camel@sboing.byte-code.lan> Message-ID: <48EB693E.40002@math.unl.edu> Luca Foppiano wrote: > hi all ;-) > I don't know if this is the right place to ask, Probably not the best place (this is about packaging policy/guidelines), you'd have much better luck on fedora-devel list. -- Rex From luca at foppiano.org Tue Oct 7 14:09:30 2008 From: luca at foppiano.org (Luca Foppiano) Date: Tue, 07 Oct 2008 16:09:30 +0200 Subject: [Fedora-packaging] looking for a sponsor and review ;) In-Reply-To: <48EB693E.40002@math.unl.edu> References: <1223370175.3900.24.camel@sboing.byte-code.lan> <48EB693E.40002@math.unl.edu> Message-ID: <1223388570.3900.35.camel@sboing.byte-code.lan> On Tue, 2008-10-07 at 08:50 -0500, Rex Dieter wrote: > Luca Foppiano wrote: > > hi all ;-) > > I don't know if this is the right place to ask, > > Probably not the best place (this is about packaging policy/guidelines), > you'd have much better luck on fedora-devel list. Sorry. I posted there. Thanks Luca -- Today is Setting Orange, the 61st day of Bureaucracy in the YOLD 3174 Batteries not included. From a.badger at gmail.com Tue Oct 7 14:32:07 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 07 Oct 2008 07:32:07 -0700 Subject: [Fedora-packaging] package review template In-Reply-To: <20081007092130.GA8763@amd.home.annexia.org> References: <1018156668.20931223008538067.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <200810031004.56888.opensource@till.name> <1223024435.3564.826.camel@beck.corsepiu.local> <200810031134.56974.opensource@till.name> <1223027287.3564.848.camel@beck.corsepiu.local> <20081003104916.GA2669@mokona.greysector.net> <20081003140203.GA3174@free.fr> <20081003141156.GB18995@redhat.com> <20081007092130.GA8763@amd.home.annexia.org> Message-ID: <48EB72E7.70207@gmail.com> Richard W.M. Jones wrote: > On Fri, Oct 03, 2008 at 03:11:56PM +0100, Daniel P. Berrange wrote: >> I think you're looking at this from the wrong point of view. The current >> packaging review guidelines are really huge, and take a long time to >> wade though. Some of them really can be just reduced to bullet point >> checklist items, while others need intelligent thought on the part of >> the reviewer. > > It's actually worse than you state ... some of them are checked just > fine by rpm/rpmlint, and so don't need to be checked at all. > > eg: rpmlint checks the License field is valid and rpm checks that > there are no duplicate files in %files, so both of those are > unnecessary. > > rpmlint could check a whole lot more too, eg. upstream URL exists, > source matches tarball, Things like the URL and source URL are problematic to automate as they require judgement. A human should be verifying that the URL is the canonical location for the project in question rather than a machine verifying that the URL exists. I do agree with the general statement that more automation is good -- just be sure to understand what is being checked so you know if you're automating the correct thing. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jussi.lehtola at helsinki.fi Tue Oct 7 15:51:05 2008 From: jussi.lehtola at helsinki.fi (Jussi Lehtola) Date: Tue, 07 Oct 2008 18:51:05 +0300 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules Message-ID: <1223394665.3397.4.camel@tb900.no-ip.org> Hi, I'm working on a couple of packages (gromacs and gromacs3) that are going to use environment-modules since they have a lot of binaries that otherwise would go to /usr/bin and some of them have very generic names (e.g. wheel, luck and highway). This way a user can have both the new release series and the old stable series installed and decide which version to use. What is the correct place to put these (architecture dependent) binaries? Is it OK to use %{_libexecdir}/%{name} (or %{name}-%{version}) ? -- ------------------------------------------------------ Jussi Lehtola, FM, Tohtorikoulutettava Fysiikan laitos, Helsingin Yliopisto jussi.lehtola at helsinki.fi, p. 191 50623 ------------------------------------------------------ Mr. Jussi Lehtola, M. Sc., Doctoral Student Department of Physics, University of Helsinki, Finland jussi.lehtola at helsinki.fi ------------------------------------------------------ From tcallawa at redhat.com Tue Oct 7 16:04:20 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 07 Oct 2008 12:04:20 -0400 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <1223394665.3397.4.camel@tb900.no-ip.org> References: <1223394665.3397.4.camel@tb900.no-ip.org> Message-ID: <1223395460.3658.55.camel@localhost.localdomain> Moderator note: I let this one through the moderation queue, please be sure to CC Jussi on all replies. ~spot From petersen at redhat.com Wed Oct 8 00:07:39 2008 From: petersen at redhat.com (Jens Petersen) Date: Tue, 7 Oct 2008 20:07:39 -0400 (EDT) Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <1223394665.3397.4.camel@tb900.no-ip.org> Message-ID: <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Hi Jussi > I'm working on a couple of packages (gromacs and gromacs3) that are > going to use environment-modules since they have a lot of binaries > that > otherwise would go to /usr/bin and some of them have very generic > names > (e.g. wheel, luck and highway). This way a user can have both the new > release series and the old stable series installed and decide which > version to use. It would be better to use alternatives for this. Look at MTA packages or other packages that do this kind of thing already. I am not familiar with gromacs: is it really necessary to include both in Fedora?: normally we just tend to ship the latest major release. Jens From ed at eh3.com Wed Oct 8 01:15:34 2008 From: ed at eh3.com (Ed Hill) Date: Tue, 7 Oct 2008 21:15:34 -0400 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <20081007211534.12792c82@localhost.localdomain> On Tue, 7 Oct 2008 20:07:39 -0400 (EDT) Jens Petersen wrote: > > > I'm working on a couple of packages (gromacs and gromacs3) that are > > going to use environment-modules since they have a lot of binaries > > that > > otherwise would go to /usr/bin and some of them have very generic > > names > > (e.g. wheel, luck and highway). This way a user can have both the > > new release series and the old stable series installed and decide > > which version to use. > > It would be better to use alternatives for this. > > Look at MTA packages or other packages that do this kind of thing > already. > > I am not familiar with gromacs: is it really necessary to include > both in Fedora?: normally we just tend to ship the latest major > release. Jens Hi folks, *Please* stop suggesting alternatives. Alternatives is a total failure for user-space applications that are not *completely* generic and 100% interchangeable. Lets illustrate this point with three use cases: Use case 1 : Two users (Alice and Bob) are using the same system (machine) at the same time. Alice must use MPI implementation "A" since it is the only one that works properly with her application. And Bob wants to use the "B" implementation since it is the one that works best for his application. Since alternatives is a *system-wide* setting, it can only satisfy one user a time -- never both. Thus, it is a total failure for this use case. Use case 2 : A single user (Carl), wants to run two programs (Foo and Bar) simultaneously. The Foo program feeds its results to the Bar program. And the Foo program requires the "A" MPI implementation while Bar requires the "B" implementation. Since alternatives is a system-wide configuration setting, Carl cannot run the two programs at the same time. Again, alternatives is not up to the task. Use case 3 : Dan and Evan both want to use the Baz program but Dan requires certain features only available with Baz v1.0 while Evan must have features only present in Baz v2.0. As in use case #1, both Dan abd Evan are trying to use the same machine. Please notice that modules (aka "environment modules") is a perfectly workable solution for all the above scenarios and it does not require any help from an admin (or root/sudo perms). Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From petersen at redhat.com Wed Oct 8 03:50:54 2008 From: petersen at redhat.com (Jens Petersen) Date: Tue, 7 Oct 2008 23:50:54 -0400 (EDT) Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <20081007211534.12792c82@localhost.localdomain> Message-ID: <720020748.1390201223437854498.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Hi Ed, > *Please* stop suggesting alternatives. Ok, I hear what you're saying and think you have a point. On the other hand using alternatives would mean having to install the programs in separate "namespaces" in the filesystem anyway and then the alternatives would just determine which of the two are default: it only has to worry about conflicting files. But I take you point that using wrappers and environment variables say might provide a cleaner more generic solution. I don't know of any packages that use that off hand in fedora but as I said we tend not to ship multiple major versions of projects afap: so first of all it would be good to understand why both are needed, but that is getting a bit off topic so that conversation probably would be better done in fedora-devel-list. Jens From jussi.lehtola at iki.fi Wed Oct 8 06:57:46 2008 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Wed, 08 Oct 2008 09:57:46 +0300 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <20081007211534.12792c82@localhost.localdomain> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> Message-ID: <1223449066.3397.14.camel@tb900.no-ip.org> On Tue, 2008-10-07 at 21:15 -0400, Ed Hill wrote: > Hi folks, > > *Please* stop suggesting alternatives. > > Alternatives is a total failure for user-space applications that are > not *completely* generic and 100% interchangeable. Lets illustrate > this point with three use cases: > > Please notice that modules (aka "environment modules") is a perfectly > workable solution for all the above scenarios and it does not require > any help from an admin (or root/sudo perms). Exactly. Now the question still remains where to hide these. OpenMPI puts its wrappers in /usr/share/openmpi, but /usr/share is for architecture independent data. Since /usr/bin doesn't have any subdirectories to me it seems quite straightforward to use /usr/libexec/%{name} to "hide" the binaries. They are then automatically added to the path upon loading the module. My interpretation is that this is OK according to the Packaging guidelines: "Libexecdir (aka, /usr/libexec on Fedora systems) should be used as the directory for executable programs that are designed primarily to be run by other programs rather than by users." Alternatives are out of the question: at the moment, there are 184 belonging to the package. Also the users of the software are quite probably used to environment-modules, since they've been standard equipment on supercomputers for a long time. -- ------------------------------------------------------ Jussi Lehtola, FM, Tohtorikoulutettava Fysiikan laitos, Helsingin Yliopisto jussi.lehtola at helsinki.fi, p. 191 50623 ------------------------------------------------------ Mr. Jussi Lehtola, M. Sc., Doctoral Student Department of Physics, University of Helsinki, Finland jussi.lehtola at helsinki.fi ------------------------------------------------------ From denis at poolshark.org Wed Oct 8 08:28:35 2008 From: denis at poolshark.org (Denis Leroy) Date: Wed, 08 Oct 2008 10:28:35 +0200 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <1223394665.3397.4.camel@tb900.no-ip.org> References: <1223394665.3397.4.camel@tb900.no-ip.org> Message-ID: <48EC6F33.7040801@poolshark.org> Jussi Lehtola wrote: > Hi, > > > I'm working on a couple of packages (gromacs and gromacs3) that are > going to use environment-modules since they have a lot of binaries that > otherwise would go to /usr/bin and some of them have very generic names > (e.g. wheel, luck and highway). This way a user can have both the new > release series and the old stable series installed and decide which > version to use. > > What is the correct place to put these (architecture dependent) > binaries? Is it OK to use %{_libexecdir}/%{name} (or > %{name}-%{version}) ? I would recommend %{_libexecdir}/%{name} which seems fairly common. Or possibly %{_libexecdir}/%{name}-%{ABI} or %{name}-%{version}, but does it really make sense to have multiple versions installed at the same time ? Will that be a common scenario for gromacs users ? As for finding the binaries, I would personally prefer to patch the code to look for the binaries in the packaged directory rather than use profile.d. -denis From pertusus at free.fr Wed Oct 8 08:32:41 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 8 Oct 2008 10:32:41 +0200 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <48EC6F33.7040801@poolshark.org> References: <1223394665.3397.4.camel@tb900.no-ip.org> <48EC6F33.7040801@poolshark.org> Message-ID: <20081008083241.GB2861@free.fr> On Wed, Oct 08, 2008 at 10:28:35AM +0200, Denis Leroy wrote: > > As for finding the binaries, I would personally prefer to patch the code > to look for the binaries in the packaged directory rather than use > profile.d. Agreed, with the addition than the env variables should still be taken into account, but in case they are not defined, the default paths should be the right ones. -- Pat From jussi.lehtola at iki.fi Wed Oct 8 09:13:56 2008 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Wed, 08 Oct 2008 12:13:56 +0300 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <48EC6F33.7040801@poolshark.org> References: <1223394665.3397.4.camel@tb900.no-ip.org> <48EC6F33.7040801@poolshark.org> Message-ID: <1223457236.8198.7.camel@politzer.theorphys.helsinki.fi> On Wed, 2008-10-08 at 10:28 +0200, Denis Leroy wrote: > > What is the correct place to put these (architecture dependent) > > binaries? Is it OK to use %{_libexecdir}/%{name} (or > > %{name}-%{version}) ? > > I would recommend %{_libexecdir}/%{name} which seems fairly common. Or > possibly %{_libexecdir}/%{name}-%{ABI} or %{name}-%{version}, but does > it really make sense to have multiple versions installed at the same > time ? Will that be a common scenario for gromacs users ? OK, good. Thanks. Many people are using the older release series, since they have calculated stuff using it and do not want to use the new release series since it does things differently. That's the main reason why the older series should still be available. On Wed, 2008-10-08 at 10:32 +0200, Patrice Dumas wrote: On Wed, Oct 08, 2008 at 10:28:35AM +0200, Denis Leroy wrote: > > > > As for finding the binaries, I would personally prefer to patch the code > > to look for the binaries in the packaged directory rather than use > > profile.d. > > Agreed, with the addition than the env variables should still be taken > into account, but in case they are not defined, the default paths should > be the right ones. OK. Environment-modules automatically modifies the system paths in such a way that everything works as it should. I made a simple profile.d file: module load gromacs so that the new release series is automatically loaded. -- ------------------------------------------------------ Jussi Lehtola, FM, Tohtorikoulutettava Fysiikan laitos, Helsingin Yliopisto jussi.lehtola at helsinki.fi, p. 191 50632 ------------------------------------------------------ Mr. Jussi Lehtola, M. Sc., Doctoral Student Department of Physics, University of Helsinki, Finland jussi.lehtola at helsinki.fi ------------------------------------------------------ From tibbs at math.uh.edu Wed Oct 8 10:55:56 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Oct 2008 05:55:56 -0500 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <48EC6F33.7040801@poolshark.org> References: <1223394665.3397.4.camel@tb900.no-ip.org> <48EC6F33.7040801@poolshark.org> Message-ID: >>>>> "DL" == Denis Leroy writes: DL> I would recommend %{_libexecdir}/%{name} which seems fairly DL> common. Or possibly %{_libexecdir}/%{name}-%{ABI} or DL> %{name}-%{version}, but does it really make sense to have multiple DL> versions installed at the same time ? My understanding of the purpose of libexec is that this is fine for internal binaries, but not for binaries which are expected to be run by the end user. However, I don't think libexec is mentioned by FHS so I guess its up to us (FPC) to make a decision. The only example that comes to mind of something that has a non-standard location for binaries is kerberos (/usr/kerberos/bin) but that seems to be more of a historical thing. What other options are there? Something under /usr/lib? Does multilib come into this decision at all? - J< From rc040203 at freenet.de Wed Oct 8 11:15:21 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 08 Oct 2008 13:15:21 +0200 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: References: <1223394665.3397.4.camel@tb900.no-ip.org> <48EC6F33.7040801@poolshark.org> Message-ID: <1223464521.3564.1142.camel@beck.corsepiu.local> On Wed, 2008-10-08 at 05:55 -0500, Jason L Tibbitts III wrote: > >>>>> "DL" == Denis Leroy writes: > > DL> I would recommend %{_libexecdir}/%{name} which seems fairly > DL> common. Or possibly %{_libexecdir}/%{name}-%{ABI} or > DL> %{name}-%{version}, but does it really make sense to have multiple > DL> versions installed at the same time ? > > My understanding of the purpose of libexec is that this is fine for > internal binaries, but not for binaries which are expected to be run > by the end user. Right. > However, I don't think libexec is mentioned by FHS > so I guess its up to us (FPC) to make a decision. libexecdir has its origin in the GNU-standards. cf. http://www.gnu.org/prep/standards/standards.html#Directory-Variables > What other options are > there? Something under /usr/lib? Yes, this had been the traditional substitute being used by the FHS and by RH-based distros. > Does multilib come into this decision at all? Normally not. The files inside of libexec are supposed to be executables/applications, i.e. they normally don't make much sense to be multilib'ed, but should be treated analogous to files in $(bindir). Also, using $(libdir) would render application search paths "arch-dependent", while using $(libexec) would be arch-independent. Ralf From denis at poolshark.org Wed Oct 8 12:10:59 2008 From: denis at poolshark.org (Denis Leroy) Date: Wed, 08 Oct 2008 14:10:59 +0200 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <1223394665.3397.4.camel@tb900.no-ip.org> References: <1223394665.3397.4.camel@tb900.no-ip.org> Message-ID: <48ECA353.8060301@poolshark.org> Jussi Lehtola wrote: > Hi, > > > I'm working on a couple of packages (gromacs and gromacs3) that are > going to use environment-modules since they have a lot of binaries that > otherwise would go to /usr/bin and some of them have very generic names > (e.g. wheel, luck and highway). Are these generic-named executables meant to be ran directly by the user from a shell, or by another executable ? I assumed the latter in my previous response. From jussi.lehtola at iki.fi Wed Oct 8 12:24:49 2008 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Wed, 08 Oct 2008 15:24:49 +0300 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <48ECA353.8060301@poolshark.org> References: <1223394665.3397.4.camel@tb900.no-ip.org> <48ECA353.8060301@poolshark.org> Message-ID: <1223468689.8198.13.camel@politzer.theorphys.helsinki.fi> On Wed, 2008-10-08 at 14:10 +0200, Denis Leroy wrote: > Are these generic-named executables meant to be ran directly by the > user > from a shell, or by another executable ? I assumed the latter in my > previous response. Directly by the user. /usr/bin is out of the question due to a) two major versions need to be able to coexist on a system with the user having the liberty to choose among them b) the binaries with general names may clash with other packages. Of course this could be solved by renaming the executables in the spec file, but this would break compatibility with upstream naming. By using environment-modules the binaries themselves can be put anywhere, since loading the module appends the path to find them. -- ------------------------------------------------------ Jussi Lehtola, FM, Tohtorikoulutettava Fysiikan laitos, Helsingin Yliopisto jussi.lehtola at helsinki.fi, p. 191 50632 ------------------------------------------------------ Mr. Jussi Lehtola, M. Sc., Doctoral Student Department of Physics, University of Helsinki, Finland jussi.lehtola at helsinki.fi ------------------------------------------------------ From ed at eh3.com Wed Oct 8 13:28:11 2008 From: ed at eh3.com (Ed Hill) Date: Wed, 8 Oct 2008 09:28:11 -0400 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <1223449066.3397.14.camel@tb900.no-ip.org> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> Message-ID: <20081008092811.03cfe17f@localhost.localdomain> On Wed, 08 Oct 2008 09:57:46 +0300 Jussi Lehtola wrote: > On Tue, 2008-10-07 at 21:15 -0400, Ed Hill wrote: > > > > *Please* stop suggesting alternatives. > > > > Alternatives is a total failure for user-space applications that are > > not *completely* generic and 100% interchangeable. Lets illustrate > > this point with three use cases: > > > > Please notice that modules (aka "environment modules") is a > > perfectly workable solution for all the above scenarios and it does > > not require any help from an admin (or root/sudo perms). > > > Exactly. Now the question still remains where to hide these. OpenMPI > puts its wrappers in /usr/share/openmpi, but /usr/share is for > architecture independent data. > > Since /usr/bin doesn't have any subdirectories to me it seems quite > straightforward to use /usr/libexec/%{name} to "hide" the binaries. > They are then automatically added to the path upon loading the module. > > My interpretation is that this is OK according to the Packaging > guidelines: "Libexecdir (aka, /usr/libexec on Fedora systems) should > be used as the directory for executable programs that are designed > primarily to be run by other programs rather than by users." Yes!!! And +1 for a convention such as /usr/libexec/%{name} /usr/libexec/%{name}-%{version} that allows both names and, if desired, versions. Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dominik at greysector.net Wed Oct 8 13:38:15 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 8 Oct 2008 15:38:15 +0200 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <20081008092811.03cfe17f@localhost.localdomain> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> Message-ID: <20081008133814.GB4449@mokona.greysector.net> On Wednesday, 08 October 2008 at 15:28, Ed Hill wrote: > On Wed, 08 Oct 2008 09:57:46 +0300 Jussi Lehtola wrote: > > On Tue, 2008-10-07 at 21:15 -0400, Ed Hill wrote: > > > > > > *Please* stop suggesting alternatives. > > > > > > Alternatives is a total failure for user-space applications that are > > > not *completely* generic and 100% interchangeable. Lets illustrate > > > this point with three use cases: > > > > > > Please notice that modules (aka "environment modules") is a > > > perfectly workable solution for all the above scenarios and it does > > > not require any help from an admin (or root/sudo perms). > > > > > > Exactly. Now the question still remains where to hide these. OpenMPI > > puts its wrappers in /usr/share/openmpi, but /usr/share is for > > architecture independent data. > > > > Since /usr/bin doesn't have any subdirectories to me it seems quite > > straightforward to use /usr/libexec/%{name} to "hide" the binaries. > > They are then automatically added to the path upon loading the module. > > > > My interpretation is that this is OK according to the Packaging > > guidelines: "Libexecdir (aka, /usr/libexec on Fedora systems) should > > be used as the directory for executable programs that are designed > > primarily to be run by other programs rather than by users." > > > Yes!!! > > And +1 for a convention such as > > /usr/libexec/%{name} > /usr/libexec/%{name}-%{version} > > that allows both names and, if desired, versions. It still feels like a bit of an abuse of libexec. I prefer using %{_libdir}/%{name}(-%{version})/bin for this purpose. Some packages do that (that is, keep their binaries there). Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rdieter at math.unl.edu Wed Oct 8 13:42:46 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 08 Oct 2008 08:42:46 -0500 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <20081008133814.GB4449@mokona.greysector.net> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> Message-ID: <48ECB8D6.6050901@math.unl.edu> Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 08 October 2008 at 15:28, Ed Hill wrote: >> /usr/libexec/%{name} >> /usr/libexec/%{name}-%{version} >> >> that allows both names and, if desired, versions. > > It still feels like a bit of an abuse of libexec. > I prefer using %{_libdir}/%{name}(-%{version})/bin for this purpose. Agreed. As had been pointed out already, libexec is for private stuff, not exposed to the end-user. Also, while I'm not familiar with the app, it still feels odd to ship > 1 version, and should be avoided if reasonably possible. -- Rex From denis at poolshark.org Wed Oct 8 15:15:59 2008 From: denis at poolshark.org (Denis Leroy) Date: Wed, 08 Oct 2008 17:15:59 +0200 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <48ECB8D6.6050901@math.unl.edu> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <48ECB8D6.6050901@math.unl.edu> Message-ID: <48ECCEAF.7000502@poolshark.org> Rex Dieter wrote: > Dominik 'Rathann' Mierzejewski wrote: >> On Wednesday, 08 October 2008 at 15:28, Ed Hill wrote: > >>> /usr/libexec/%{name} >>> /usr/libexec/%{name}-%{version} >>> >>> that allows both names and, if desired, versions. >> >> It still feels like a bit of an abuse of libexec. >> I prefer using %{_libdir}/%{name}(-%{version})/bin for this purpose. > > Agreed. As had been pointed out already, libexec is for private stuff, > not exposed to the end-user. Agreed also. > Also, while I'm not familiar with the app, it still feels odd to ship > > 1 version, and should be avoided if reasonably possible. Yes I have a problem with that too. There are very few "leaf" (i.e. non-libs) packages that have multiple installable concurrent versions. gcc is an example, For compat-gcc-XXX, the "public" executables live in /usr/bin but have a version suffix added (i.e. "/usr/bin/gcc34"), while the "private" executables live in a versioned directory under /usr/libexec, and that path is hardcoded into the compat-gcc build. so there are 2 issues to discuss here: 1) multiple concurrent versions installed. Is that really necessary ? Is it a question of binary data compatibility, or a whole set of features that were removed by the new version ? 2) where to put the binaries. Gromacs seems to have 50+ executables (what's the exact number?). Most have non-trivial names with a "g_" prefix, a few are more conflict-prone, namely "wheel", "highway" or "editconf". From ed at eh3.com Wed Oct 8 16:24:22 2008 From: ed at eh3.com (Ed Hill) Date: Wed, 8 Oct 2008 12:24:22 -0400 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <20081008133814.GB4449@mokona.greysector.net> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> Message-ID: <20081008122422.1c2e16c3@localhost.localdomain> On Wed, 8 Oct 2008 15:38:15 +0200 "Dominik 'Rathann' Mierzejewski" wrote: > On Wednesday, 08 October 2008 at 15:28, Ed Hill wrote: > > > > And +1 for a convention such as > > > > /usr/libexec/%{name} > > /usr/libexec/%{name}-%{version} > > > > that allows both names and, if desired, versions. > > It still feels like a bit of an abuse of libexec. > I prefer using %{_libdir}/%{name}(-%{version})/bin for this purpose. > Some packages do that (that is, keep their binaries there). What reason(s) do you have for the preference ? If you use %{_libdir} then you will have to deal with multi-lib which, in my opinion, needlessly complicates paths in the environment-modules files. If you use %{_libexecdir} then you do *not* have to worry about any multilib issues -- they are automatically sorted out for you. Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Oct 8 16:25:48 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 08 Oct 2008 11:25:48 -0500 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <20081008122422.1c2e16c3@localhost.localdomain> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <20081008122422.1c2e16c3@localhost.localdomain> Message-ID: <48ECDF0C.8020802@math.unl.edu> Ed Hill wrote: > If you use %{_libdir} then you will have to deal with multi-lib What makes you say that? -- Rex From jussi.lehtola at iki.fi Wed Oct 8 15:28:58 2008 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Wed, 08 Oct 2008 18:28:58 +0300 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <48ECCEAF.7000502@poolshark.org> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <48ECB8D6.6050901@math.unl.edu> <48ECCEAF.7000502@poolshark.org> Message-ID: <1223479739.3367.12.camel@tb900.no-ip.org> On Wed, 2008-10-08 at 17:15 +0200, Denis Leroy wrote: > Rex Dieter wrote: > > Dominik 'Rathann' Mierzejewski wrote: > >> It still feels like a bit of an abuse of libexec. > >> I prefer using %{_libdir}/%{name}(-%{version})/bin for this purpose. > > > > Agreed. As had been pointed out already, libexec is for private stuff, > > not exposed to the end-user. > > Agreed also. OK, I'll put the binaries to %{_libdir}/%{name}-%{version}/bin . > so there are 2 issues to discuss here: > > 1) multiple concurrent versions installed. Is that really necessary ? Is > it a question of binary data compatibility, or a whole set of features > that were removed by the new version ? Yes, I think it is. Anyway, IMHO this is a side point for the discussion. > 2) where to put the binaries. Gromacs seems to have 50+ executables > (what's the exact number?). Most have non-trivial names with a "g_" > prefix, a few are more conflict-prone, namely "wheel", "highway" or > "editconf". Well, since there are single and double precision versions of every tool and a couple MPI enabled programs as well, the current total is 184, of which 66 don't have names beginning with g_ . -- ------------------------------------------------------ Jussi Lehtola, FM, Tohtorikoulutettava Fysiikan laitos, Helsingin Yliopisto jussi.lehtola at helsinki.fi, p. 191 50623 ------------------------------------------------------ Mr. Jussi Lehtola, M. Sc., Doctoral Student Department of Physics, University of Helsinki, Finland jussi.lehtola at helsinki.fi ------------------------------------------------------ From a.badger at gmail.com Wed Oct 8 18:50:59 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 08 Oct 2008 11:50:59 -0700 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <1223479739.3367.12.camel@tb900.no-ip.org> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <48ECB8D6.6050901@math.unl.edu> <48ECCEAF.7000502@poolshark.org> <1223479739.3367.12.camel@tb900.no-ip.org> Message-ID: <48ED0113.4060008@gmail.com> Jussi Lehtola wrote: > On Wed, 2008-10-08 at 17:15 +0200, Denis Leroy wrote: >> Rex Dieter wrote: >>> Dominik 'Rathann' Mierzejewski wrote: >>>> It still feels like a bit of an abuse of libexec. >>>> I prefer using %{_libdir}/%{name}(-%{version})/bin for this purpose. >>> Agreed. As had been pointed out already, libexec is for private stuff, >>> not exposed to the end-user. >> Agreed also. > > OK, I'll put the binaries to %{_libdir}/%{name}-%{version}/bin . > Hold on to that point for a few... I think Ed Hill and Ralf Corsepius have a valid point about %{_libexecdir}/%{name}-%{version}/bin being the proper place. I'm going to comment in the other subthread, though, so we don't get too scattered. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Wed Oct 8 18:59:09 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 08 Oct 2008 11:59:09 -0700 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <48ECDF0C.8020802@math.unl.edu> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <20081008122422.1c2e16c3@localhost.localdomain> <48ECDF0C.8020802@math.unl.edu> Message-ID: <48ED02FD.9080900@gmail.com> Rex Dieter wrote: > Ed Hill wrote: > >> If you use %{_libdir} then you will have to deal with multi-lib > > What makes you say that? > As Ralf said, when you place binaries into %{_libdir} you have to deal with different paths on different systems. On x86: /usr/lib/gromacs-2/bin/wheel On x86_64: /usr/lib64/gromacs-2/bin/wheel There's two possible ways to work around this: %{_libexecdir} /usr/libexec/gromacs-2/bin/wheel /usr/lib (*not* %{_libdir}): /usr/lib/gromacs-2/bin/wheel I don't know that I favor one of these over the other... they both have precedent. You could look at this as end-user applications or as environment-modules making these binaries "private" to the environment-modules "program". A third way to look at this would be to have an environment-modules directory and place things within that: /usr/libexec/environment-modules/gromacs-2/bin/wheel I'm not sure whether environment-modules only handles executables or if it also handles libraries, datafiles, etc, though. So I don't know whether that's the best place for an environment-modules directory to live. Ed, do you have a comment on whether this is a good or bad idea for use of environment-modules? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rdieter at math.unl.edu Wed Oct 8 19:07:04 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 08 Oct 2008 14:07:04 -0500 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <48ED02FD.9080900@gmail.com> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <20081008122422.1c2e16c3@localhost.localdomain> <48ECDF0C.8020802@math.unl.edu> <48ED02FD.9080900@gmail.com> Message-ID: <48ED04D8.9070600@math.unl.edu> Toshio Kuratomi wrote: > Rex Dieter wrote: >> Ed Hill wrote: >> >>> If you use %{_libdir} then you will have to deal with multi-lib >> What makes you say that? >> > As Ralf said, when you place binaries into %{_libdir} you have to deal > with different paths on different systems. OK, my confusion was based on a different meaning of "multi-lib" in this context. -- Rex From dominik at greysector.net Wed Oct 8 19:27:03 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 8 Oct 2008 21:27:03 +0200 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <48ED02FD.9080900@gmail.com> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <20081008122422.1c2e16c3@localhost.localdomain> <48ECDF0C.8020802@math.unl.edu> <48ED02FD.9080900@gmail.com> Message-ID: <20081008192702.GA7602@mokona.greysector.net> On Wednesday, 08 October 2008 at 20:59, Toshio Kuratomi wrote: > Rex Dieter wrote: > > Ed Hill wrote: > > > >> If you use %{_libdir} then you will have to deal with multi-lib > > > > What makes you say that? > > > As Ralf said, when you place binaries into %{_libdir} you have to deal > with different paths on different systems. > > On x86: > /usr/lib/gromacs-2/bin/wheel > > On x86_64: > /usr/lib64/gromacs-2/bin/wheel > > There's two possible ways to work around this: > %{_libexecdir} > /usr/libexec/gromacs-2/bin/wheel > > /usr/lib (*not* %{_libdir}): > /usr/lib/gromacs-2/bin/wheel Or just fixup the path in env-module config file. That's about the only technical argument in favour of libexec. Using libexec doesn't require hacking the config files. > I don't know that I favor one of these over the other... they both have > precedent. You could look at this as end-user applications or as > environment-modules making these binaries "private" to the > environment-modules "program". GROMACS is an end-user app IIUC and its binaries are used directly. > A third way to look at this would be to have an environment-modules > directory and place things within that: > /usr/libexec/environment-modules/gromacs-2/bin/wheel > > I'm not sure whether environment-modules only handles executables or if > it also handles libraries, datafiles, etc, though. It handles everything. > So I don't know > whether that's the best place for an environment-modules directory to > live. Ed, do you have a comment on whether this is a good or bad idea > for use of environment-modules? I don't think it is. That's certainly a way of thinking about env-modules I haven't considered, but I think treating GROMACS binaries as "private" of environment modules makes no sense. They have nothing to do with env-modules and they are not private. Rather, env-modules is a convenient way of allowing both gromacs3 and gromacs to be installed concurrently and avoiding polluting %{_bindir}. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jussi.lehtola at iki.fi Wed Oct 8 19:29:40 2008 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Wed, 08 Oct 2008 22:29:40 +0300 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <48ED02FD.9080900@gmail.com> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <20081008122422.1c2e16c3@localhost.localdomain> <48ECDF0C.8020802@math.unl.edu> <48ED02FD.9080900@gmail.com> Message-ID: <1223494180.3424.2.camel@tb900.no-ip.org> On Wed, 2008-10-08 at 11:59 -0700, Toshio Kuratomi wrote: > I'm not sure whether environment-modules only handles executables or if > it also handles libraries, datafiles, etc, though. So I don't know > whether that's the best place for an environment-modules directory to > live. Ed, do you have a comment on whether this is a good or bad idea > for use of environment-modules? It handles anything you otherwise can handle. With a module you can define all sorts of environment variables, such as PATH, LD_LIBRARY_PATH, MANPATH and so on. Just as long as a program has been written to be relocatable you can put it anywhere you like with environment-modules. -- ------------------------------------------------------ Jussi Lehtola, FM, Tohtorikoulutettava Fysiikan laitos, Helsingin Yliopisto jussi.lehtola at helsinki.fi, p. 191 50623 ------------------------------------------------------ Mr. Jussi Lehtola, M. Sc., Doctoral Student Department of Physics, University of Helsinki, Finland jussi.lehtola at helsinki.fi ------------------------------------------------------ From dominik at greysector.net Wed Oct 8 19:29:31 2008 From: dominik at greysector.net (dominik at greysector.net) Date: Wed, 8 Oct 2008 21:29:31 +0200 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <20081008122422.1c2e16c3@localhost.localdomain> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <20081008122422.1c2e16c3@localhost.localdomain> Message-ID: <20081008192930.GB7602@mokona.greysector.net> On Wednesday, 08 October 2008 at 18:24, Ed Hill wrote: > On Wed, 8 Oct 2008 15:38:15 +0200 "Dominik 'Rathann' Mierzejewski" > wrote: > > On Wednesday, 08 October 2008 at 15:28, Ed Hill wrote: > > > > > > And +1 for a convention such as > > > > > > /usr/libexec/%{name} > > > /usr/libexec/%{name}-%{version} > > > > > > that allows both names and, if desired, versions. > > > > It still feels like a bit of an abuse of libexec. > > I prefer using %{_libdir}/%{name}(-%{version})/bin for this purpose. > > Some packages do that (that is, keep their binaries there). > > > What reason(s) do you have for the preference ? > > If you use %{_libdir} then you will have to deal with multi-lib which, > in my opinion, needlessly complicates paths in the environment-modules > files. > > If you use %{_libexecdir} then you do *not* have to worry about any > multilib issues -- they are automatically sorted out for you. That is a good argument and I have considered it before. However, libexec is non-standard and its purpose is to keep application-internal binaries, not ones intended for user consumption. I think these points outweigh the little convenience which using libexec provides. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From ed at eh3.com Wed Oct 8 20:34:40 2008 From: ed at eh3.com (Ed Hill) Date: Wed, 8 Oct 2008 16:34:40 -0400 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <48ED02FD.9080900@gmail.com> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <20081008122422.1c2e16c3@localhost.localdomain> <48ECDF0C.8020802@math.unl.edu> <48ED02FD.9080900@gmail.com> Message-ID: <20081008163440.7d63f0e7@localhost.localdomain> On Wed, 08 Oct 2008 11:59:09 -0700 Toshio Kuratomi wrote: > > There's two possible ways to work around this: > %{_libexecdir} > /usr/libexec/gromacs-2/bin/wheel > > /usr/lib (*not* %{_libdir}): > /usr/lib/gromacs-2/bin/wheel > > I don't know that I favor one of these over the other... they both > have precedent. You could look at this as end-user applications or as > environment-modules making these binaries "private" to the > environment-modules "program". Yes, absolutely! I can think of examples where both /usr/lib and /usr/libexec have been used for "private" executables. I don't have a strong preference for either -- I just want one to be chosen as the "standard Fedora way" to handle the various use cases I described earlier. > A third way to look at this would be to have an environment-modules > directory and place things within that: > /usr/libexec/environment-modules/gromacs-2/bin/wheel I'm against the inclusion of "environment-modules" in the path since you don't *have* to use environment-modules to take advantage of the multiple implementations or versions once they are made available. One can always add the desired paths by hand or via ~/.bash_profile or some other way. > I'm not sure whether environment-modules only handles executables or > if it also handles libraries, datafiles, etc, though. So I don't know > whether that's the best place for an environment-modules directory to > live. Ed, do you have a comment on whether this is a good or bad idea > for use of environment-modules? The environment-variables system can and does (and is often used at cluster and/or "supercomputer" sites) to handle all sorts of environment variables including: PATH, MANPATH, LD_LIBRARY_PATH, CFLAGS, LDFLAGS, etc. The environment-modules can also depend upon each other (so using one automatically pulls in all its dependencies). But that's another topic... Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Wed Oct 8 20:52:13 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 08 Oct 2008 13:52:13 -0700 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <20081008192702.GA7602@mokona.greysector.net> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <20081008122422.1c2e16c3@localhost.localdomain> <48ECDF0C.8020802@math.unl.edu> <48ED02FD.9080900@gmail.com> <20081008192702.GA7602@mokona.greysector.net> Message-ID: <48ED1D7D.8010004@gmail.com> Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 08 October 2008 at 20:59, Toshio Kuratomi wrote: >> Rex Dieter wrote: >>> Ed Hill wrote: >>> >>>> If you use %{_libdir} then you will have to deal with multi-lib >>> What makes you say that? >>> >> As Ralf said, when you place binaries into %{_libdir} you have to deal >> with different paths on different systems. >> >> On x86: >> /usr/lib/gromacs-2/bin/wheel >> >> On x86_64: >> /usr/lib64/gromacs-2/bin/wheel >> >> There's two possible ways to work around this: >> %{_libexecdir} >> /usr/libexec/gromacs-2/bin/wheel >> >> /usr/lib (*not* %{_libdir}): >> /usr/lib/gromacs-2/bin/wheel Thought of a big reason not to use /usr/lib -- the binaries placed within there would be architecture dependent. So we'd have x86_64 binaries living in /usr/lib. > > Or just fixup the path in env-module config file. That's about the only > technical argument in favour of libexec. Using libexec doesn't require > hacking the config files. > [snip] >> So I don't know >> whether that's the best place for an environment-modules directory to >> live. Ed, do you have a comment on whether this is a good or bad idea >> for use of environment-modules? > > I don't think it is. That's certainly a way of thinking about env-modules > I haven't considered, but I think treating GROMACS binaries as "private" > of environment modules makes no sense. They have nothing to do with > env-modules and they are not private. Rather, env-modules is a convenient > way of allowing both gromacs3 and gromacs to be installed concurrently > and avoiding polluting %{_bindir}. Sure, that's the way I had been thinking about them until I started comparing it to what alternatives does. Here's another thought: /usr/libexec is not in the FHS, so we're using the GNU definition in specifying that it should be used for programs that are called by other programs. However, the reason we include /usr/libexec in Fedora even though it's not in the FHS is that we need someplace to put executables that aren't in users' paths but need to match up with the host's architecture. This matches the description of the directory we need in this case. And as you say, doing path fixups in the env-module file is an alternate way to fix things. I just don't like having the complexity in user scripts when this seems more straightforward. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From dominik at greysector.net Wed Oct 8 22:32:40 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 9 Oct 2008 00:32:40 +0200 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <48ED1D7D.8010004@gmail.com> References: <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <20081008122422.1c2e16c3@localhost.localdomain> <48ECDF0C.8020802@math.unl.edu> <48ED02FD.9080900@gmail.com> <20081008192702.GA7602@mokona.greysector.net> <48ED1D7D.8010004@gmail.com> Message-ID: <20081008223239.GC7602@mokona.greysector.net> On Wednesday, 08 October 2008 at 22:52, Toshio Kuratomi wrote: > Dominik 'Rathann' Mierzejewski wrote: > > On Wednesday, 08 October 2008 at 20:59, Toshio Kuratomi wrote: > >> Rex Dieter wrote: > >>> Ed Hill wrote: > >>> > >>>> If you use %{_libdir} then you will have to deal with multi-lib > >>> What makes you say that? > >>> > >> As Ralf said, when you place binaries into %{_libdir} you have to deal > >> with different paths on different systems. > >> > >> On x86: > >> /usr/lib/gromacs-2/bin/wheel > >> > >> On x86_64: > >> /usr/lib64/gromacs-2/bin/wheel > >> > >> There's two possible ways to work around this: > >> %{_libexecdir} > >> /usr/libexec/gromacs-2/bin/wheel > >> > >> /usr/lib (*not* %{_libdir}): > >> /usr/lib/gromacs-2/bin/wheel > > Thought of a big reason not to use /usr/lib -- the binaries placed > within there would be architecture dependent. So we'd have x86_64 > binaries living in /usr/lib. > > > > > Or just fixup the path in env-module config file. That's about the only > > technical argument in favour of libexec. Using libexec doesn't require > > hacking the config files. > > > [snip] > > >> So I don't know > >> whether that's the best place for an environment-modules directory to > >> live. Ed, do you have a comment on whether this is a good or bad idea > >> for use of environment-modules? > > > > I don't think it is. That's certainly a way of thinking about env-modules > > I haven't considered, but I think treating GROMACS binaries as "private" > > of environment modules makes no sense. They have nothing to do with > > env-modules and they are not private. Rather, env-modules is a convenient > > way of allowing both gromacs3 and gromacs to be installed concurrently > > and avoiding polluting %{_bindir}. > > Sure, that's the way I had been thinking about them until I started > comparing it to what alternatives does. > > Here's another thought: > > /usr/libexec is not in the FHS, so we're using the GNU definition in > specifying that it should be used for programs that are called by other > programs. However, the reason we include /usr/libexec in Fedora even > though it's not in the FHS is that we need someplace to put executables > that aren't in users' paths but need to match up with the host's > architecture. This matches the description of the directory we need in > this case. > > And as you say, doing path fixups in the env-module file is an alternate > way to fix things. I just don't like having the complexity in user > scripts when this seems more straightforward. Here's an old discussion that seems to have good arguments to support your view: http://www.redhat.com/archives/rhl-devel-list/2005-May/msg00240.html So, I have no further objections against using /usr/libexec. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From petersen at redhat.com Thu Oct 9 01:41:19 2008 From: petersen at redhat.com (Jens Petersen) Date: Wed, 8 Oct 2008 21:41:19 -0400 (EDT) Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <48ED02FD.9080900@gmail.com> Message-ID: <1756807630.1840661223516479871.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> > As Ralf said, when you place binaries into %{_libdir} you have to deal > with different paths on different systems. > > On x86: > /usr/lib/gromacs-2/bin/wheel > > On x86_64: > /usr/lib64/gromacs-2/bin/wheel I don't see any problem with using %{_libdir} for this: it should be straight forward to script into the environment modules and it would even allow multilib if for some obscure user that were desirable. Jens From rc040203 at freenet.de Thu Oct 9 03:46:56 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 09 Oct 2008 05:46:56 +0200 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <20081008163440.7d63f0e7@localhost.localdomain> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <20081008122422.1c2e16c3@localhost.localdomain> <48ECDF0C.8020802@math.unl.edu> <48ED02FD.9080900@gmail.com> <20081008163440.7d63f0e7@localhost.localdomain> Message-ID: <1223524016.3564.1168.camel@beck.corsepiu.local> On Wed, 2008-10-08 at 16:34 -0400, Ed Hill wrote: > On Wed, 08 Oct 2008 11:59:09 -0700 Toshio Kuratomi wrote: > > > > There's two possible ways to work around this: > > %{_libexecdir} > > /usr/libexec/gromacs-2/bin/wheel > > > > /usr/lib (*not* %{_libdir}): > > /usr/lib/gromacs-2/bin/wheel > > > > I don't know that I favor one of these over the other... they both > > have precedent. You could look at this as end-user applications or as > > environment-modules making these binaries "private" to the > > environment-modules "program". > > Yes, absolutely! I can think of examples where both /usr/lib > and /usr/libexec have been used for "private" executables. Yes, there are. Wrt. the GNU-Standards, packages with "private" executables in in /usr/lib qualify as packaging bugs. In Fedora reality however, most packages shipping "private" executables in /usr/lib inherited this either from their RH packaging history or from their packagers/upstream's ignorance/unawareness on the GNU-Standards. > I don't > have a strong preference for either -- I just want one to be chosen as > the "standard Fedora way" to handle the various use cases I described > earlier. Internal applications => libexec User-callable applications => bindir User-callable add-on applications => /usr/lib/ (!) or % libdir/ Multi-arched applications => %libdir/ Ralf From rc040203 at freenet.de Thu Oct 9 04:06:33 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 09 Oct 2008 06:06:33 +0200 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <1756807630.1840661223516479871.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <1756807630.1840661223516479871.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1223525193.3564.1181.camel@beck.corsepiu.local> On Wed, 2008-10-08 at 21:41 -0400, Jens Petersen wrote: > > As Ralf said, when you place binaries into %{_libdir} you have to deal > > with different paths on different systems. > > > > On x86: > > /usr/lib/gromacs-2/bin/wheel > > > > On x86_64: > > /usr/lib64/gromacs-2/bin/wheel > > I don't see any problem with using %{_libdir} for this: it should be > straight forward to script into the environment modules and it would > even allow multilib if for some obscure user that were desirable. Well, on Linux applications are always linked against one architecture only (or noarched), i.e. multilibs are not of any importance, here. Multi-arch'ing (The ability to run "non-native" application; e.g. running ix86 binaries on x86_64) can be relevant in some cases. However, in practice, such cases are rare. Apart of applications which lack full "native support" (e.g. firefox plugins), the only cases I've encountered so far is packages containing library testsuites/example applications. To package them, %libdir/... seem to be the only viable option. Ralf From debarshi.ray at gmail.com Thu Oct 9 13:41:42 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Thu, 9 Oct 2008 19:11:42 +0530 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <1223524016.3564.1168.camel@beck.corsepiu.local> References: <1223394665.3397.4.camel@tb900.no-ip.org> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <20081008122422.1c2e16c3@localhost.localdomain> <48ECDF0C.8020802@math.unl.edu> <48ED02FD.9080900@gmail.com> <20081008163440.7d63f0e7@localhost.localdomain> <1223524016.3564.1168.camel@beck.corsepiu.local> Message-ID: <3170f42f0810090641r79850bf3gb7fe5260295a015d@mail.gmail.com> > Wrt. the GNU-Standards, packages with "private" executables in > in /usr/lib qualify as packaging bugs. > > In Fedora reality however, most packages shipping "private" executables > in /usr/lib inherited this either from their RH packaging history > or from their packagers/upstream's ignorance/unawareness on the > GNU-Standards. I have a package, 'bouml', which invokes private executables placed inside %{_libdir}/bouml/. Is this serious enough to patch the package or try to convince upstream to change? The package is somewhat big, and I would not like to patch it if it was not really needed. Cheerio, Debarshi From rc040203 at freenet.de Thu Oct 9 15:59:40 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 09 Oct 2008 17:59:40 +0200 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <3170f42f0810090641r79850bf3gb7fe5260295a015d@mail.gmail.com> References: <1223394665.3397.4.camel@tb900.no-ip.org> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <20081008122422.1c2e16c3@localhost.localdomain> <48ECDF0C.8020802@math.unl.edu> <48ED02FD.9080900@gmail.com> <20081008163440.7d63f0e7@localhost.localdomain> <1223524016.3564.1168.camel@beck.corsepiu.local> <3170f42f0810090641r79850bf3gb7fe5260295a015d@mail.gmail.com> Message-ID: <1223567980.3564.1191.camel@beck.corsepiu.local> On Thu, 2008-10-09 at 19:11 +0530, Debarshi Ray wrote: > > Wrt. the GNU-Standards, packages with "private" executables in > > in /usr/lib qualify as packaging bugs. > > > > In Fedora reality however, most packages shipping "private" executables > > in /usr/lib inherited this either from their RH packaging history > > or from their packagers/upstream's ignorance/unawareness on the > > GNU-Standards. > > I have a package, 'bouml', which invokes private executables placed > inside %{_libdir}/bouml/. Is this serious enough to patch the package No, there are plenty of packages which do so as well ;-) > or try to convince upstream to change? If I were you, I'd try to do so. If what you say applies, their package simply doesn't comply to the GNU-Standards. > The package is somewhat big, > and I would not like to patch it if it was not really needed. I don't know this package, but if they are using automake, such a change should be pretty easy and straight forward to implement. Ralf From xkdcc at 163.com Fri Oct 10 04:55:04 2008 From: xkdcc at 163.com (xkdcc) Date: Fri, 10 Oct 2008 12:55:04 +0800 (CST) Subject: [Fedora-packaging] how to update the unifdef without network when compiling kernel src for x86_64 arch Message-ID: <4016968.931391223614504970.JavaMail.coremail@bj163app18.163.com> Hi. 1. Configuration: Fedora 6 (KERNEL-2.6-18-1.2798) 2. I don't have my NIC drivers. 3. Then I have the NIC drivers source, I need compile it with kernel source support. 4. I copy the kernel source rpm to my F6 by USB Flash Dis. But I need to use commands below: rpm -ivh KERNEL-2.6-18-1.2798.fc6.src.rpm rpmbuild -bp --target=x86_64 /usr/src/redhat/SPECS/kernel-2.6.spec Building target platforms: x86_64 Building for target x86_64 error: Failed build dependencies: unifdef is need by kernel-2.6-18-1.2798.x86_64 5. I got information that someone suggest me to do command: yum install unifdef but it needs connect to network. You know, I can't now withou NIC drivers! 6. What else can I do? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at city-fan.org Fri Oct 10 06:32:15 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 10 Oct 2008 07:32:15 +0100 Subject: [Fedora-packaging] how to update the unifdef without network when compiling kernel src for x86_64 arch In-Reply-To: <4016968.931391223614504970.JavaMail.coremail@bj163app18.163.com> References: <4016968.931391223614504970.JavaMail.coremail@bj163app18.163.com> Message-ID: <20081010073215.5fa5d159@metropolis.intra.city-fan.org> On Fri, 10 Oct 2008 12:55:04 +0800 (CST) xkdcc wrote: > Hi. > > > 1. Configuration: Fedora 6 (KERNEL-2.6-18-1.2798) > 2. I don't have my NIC drivers. > 3. Then I have the NIC drivers source, I need compile it with kernel > source support. 4. I copy the kernel source rpm to my F6 by USB Flash > Dis. But I need to use commands below: rpm -ivh > KERNEL-2.6-18-1.2798.fc6.src.rpm rpmbuild -bp > --target=x86_64 /usr/src/redhat/SPECS/kernel-2.6.spec Building target > platforms: x86_64 Building for target x86_64 > error: Failed build dependencies: > unifdef is need by kernel-2.6-18-1.2798.x86_64 > 5. I got information that someone suggest me to do command: > yum install unifdef > but it needs connect to network. You know, I can't now withou NIC > drivers! 6. What else can I do? This question is off-topic for this list and is better suited to fedora-list. However, now you're here: You can get unifdef by downloading it from your network-connected machine from here: http://archives.fedoraproject.org/pub/archive/fedora/linux/core/6/x86_64/os/Fedora/RPMS/unifdef-1.171-5.fc6.x86_64.rpm Transfer it to your target machine using your USB stick, then install it using RPM: # rpm -Uvh unifdef-1.171-5.fc6.x86_64.rpm (this package may actually be on your install media). Paul. From jussi.lehtola at iki.fi Fri Oct 10 09:18:38 2008 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Fri, 10 Oct 2008 12:18:38 +0300 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <1223524016.3564.1168.camel@beck.corsepiu.local> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <20081008122422.1c2e16c3@localhost.localdomain> <48ECDF0C.8020802@math.unl.edu> <48ED02FD.9080900@gmail.com> <20081008163440.7d63f0e7@localhost.localdomain> <1223524016.3564.1168.camel@beck.corsepiu.local> Message-ID: <1223630318.29099.8.camel@politzer.theorphys.helsinki.fi> On Thu, 2008-10-09 at 05:46 +0200, Ralf Corsepius wrote: > On Wed, 2008-10-08 at 16:34 -0400, Ed Hill wrote: > > I don't > > have a strong preference for either -- I just want one to be chosen as > > the "standard Fedora way" to handle the various use cases I described > > earlier. > > Internal applications => libexec > > User-callable applications => bindir > > User-callable add-on applications => /usr/lib/ (!) or % > libdir/ > > Multi-arched applications => %libdir/ So... for a program (gromacs) using environment-modules the location would be %libdir/%name ..? Do you agree? -- ------------------------------------------------------ Jussi Lehtola, FM, Tohtorikoulutettava Fysiikan laitos, Helsingin Yliopisto jussi.lehtola at helsinki.fi, p. 191 50632 ------------------------------------------------------ Mr. Jussi Lehtola, M. Sc., Doctoral Student Department of Physics, University of Helsinki, Finland jussi.lehtola at helsinki.fi ------------------------------------------------------ From xkdcc at 163.com Fri Oct 10 09:53:02 2008 From: xkdcc at 163.com (xkdcc) Date: Fri, 10 Oct 2008 17:53:02 +0800 (CST) Subject: [Fedora-packaging] how to update the unifdef without network when compiling kernel src for x86_64 arch In-Reply-To: <20081010073215.5fa5d159@metropolis.intra.city-fan.org> References: <20081010073215.5fa5d159@metropolis.intra.city-fan.org> <4016968.931391223614504970.JavaMail.coremail@bj163app18.163.com> Message-ID: <3511197.1216371223632382779.JavaMail.coremail@app141.163.com> Got it! Thank you very much! Best Regards, Brant. 2008-10-10?"Paul Howarth" say? >On Fri, 10 Oct 2008 12:55:04 +0800 (CST) >xkdcc -------------- next part -------------- An HTML attachment was scrubbed... URL: From rc040203 at freenet.de Fri Oct 10 10:48:22 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 10 Oct 2008 12:48:22 +0200 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <1223630318.29099.8.camel@politzer.theorphys.helsinki.fi> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <20081008122422.1c2e16c3@localhost.localdomain> <48ECDF0C.8020802@math.unl.edu> <48ED02FD.9080900@gmail.com> <20081008163440.7d63f0e7@localhost.localdomain> <1223524016.3564.1168.camel@beck.corsepiu.local> <1223630318.29099.8.camel@politzer.theorphys.helsinki.fi> Message-ID: <1223635702.3564.1235.camel@beck.corsepiu.local> On Fri, 2008-10-10 at 12:18 +0300, Jussi Lehtola wrote: > On Thu, 2008-10-09 at 05:46 +0200, Ralf Corsepius wrote: > > On Wed, 2008-10-08 at 16:34 -0400, Ed Hill wrote: > > > I don't > > > have a strong preference for either -- I just want one to be chosen as > > > the "standard Fedora way" to handle the various use cases I described > > > earlier. > > > > Internal applications => libexec > > > > User-callable applications => bindir > > > > User-callable add-on applications => /usr/lib/ (!) or % > > libdir/ > > > > Multi-arched applications => %libdir/ > > So... for a program (gromacs) using environment-modules No idea what you mean by "environment-modules". > the location > would be %libdir/%name ..? Do you agree? Ralf From jussi.lehtola at iki.fi Fri Oct 10 11:08:24 2008 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Fri, 10 Oct 2008 14:08:24 +0300 Subject: [Fedora-packaging] The role of %{_libexecdir} for using environment-modules In-Reply-To: <1223635702.3564.1235.camel@beck.corsepiu.local> References: <1223394665.3397.4.camel@tb900.no-ip.org> <371395756.1372311223424459119.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20081007211534.12792c82@localhost.localdomain> <1223449066.3397.14.camel@tb900.no-ip.org> <20081008092811.03cfe17f@localhost.localdomain> <20081008133814.GB4449@mokona.greysector.net> <20081008122422.1c2e16c3@localhost.localdomain> <48ECDF0C.8020802@math.unl.edu> <48ED02FD.9080900@gmail.com> <20081008163440.7d63f0e7@localhost.localdomain> <1223524016.3564.1168.camel@beck.corsepiu.local> <1223630318.29099.8.camel@politzer.theorphys.helsinki.fi> <1223635702.3564.1235.camel@beck.corsepiu.local> Message-ID: <1223636904.30904.2.camel@politzer.theorphys.helsinki.fi> On Fri, 2008-10-10 at 12:48 +0200, Ralf Corsepius wrote: > Internal applications => libexec > > > > > > User-callable applications => bindir > > > > > > User-callable add-on applications => /usr/lib/ (!) or % > > > libdir/ > > > > > > Multi-arched applications => %libdir/ > > > > So... for a program (gromacs) using environment-modules > No idea what you mean by "environment-modules". See http://modules.sourceforge.net/ . As a reminder, here's Ed's mail from a couple of days ago. On Tue, 2008-10-07 at 21:15 -0400, Ed Hill wrote: Hi folks, > > *Please* stop suggesting alternatives. > > Alternatives is a total failure for user-space applications that are > not *completely* generic and 100% interchangeable. Lets illustrate > this point with three use cases: > > Use case 1 : Two users (Alice and Bob) are using the same system > (machine) at the same time. Alice must use MPI implementation > "A" since it is the only one that works properly with her > application. And Bob wants to use the "B" implementation since > it is the one that works best for his application. Since > alternatives is a *system-wide* setting, it can only satisfy one > user a time -- never both. Thus, it is a total failure for this > use case. > > Use case 2 : A single user (Carl), wants to run two programs > (Foo and Bar) simultaneously. The Foo program feeds its results > to the Bar program. And the Foo program requires the "A" MPI > implementation while Bar requires the "B" implementation. Since > alternatives is a system-wide configuration setting, Carl cannot > run the two programs at the same time. Again, alternatives is > not up to the task. > > Use case 3 : Dan and Evan both want to use the Baz program but Dan > requires certain features only available with Baz v1.0 while > Evan must have features only present in Baz v2.0. As in use case > #1, both Dan abd Evan are trying to use the same machine. > > > Please notice that modules (aka "environment modules") is a perfectly > workable solution for all the above scenarios and it does not require > any help from an admin (or root/sudo perms). > > Ed -- ------------------------------------------------------ Jussi Lehtola, FM, Tohtorikoulutettava Fysiikan laitos, Helsingin Yliopisto jussi.lehtola at helsinki.fi, p. 191 50632 ------------------------------------------------------ Mr. Jussi Lehtola, M. Sc., Doctoral Student Department of Physics, University of Helsinki, Finland jussi.lehtola at helsinki.fi ------------------------------------------------------ From hubert at lshift.net Fri Oct 10 12:49:59 2008 From: hubert at lshift.net (Hubert Plociniczak) Date: Fri, 10 Oct 2008 13:49:59 +0100 Subject: [Fedora-packaging] how to include rpm-specific files in the spec Message-ID: <48EF4F77.10202@lshift.net> Hello, I couldn't find answer to my question on any guidelines page, so I am going to ask the question on the list. The problem I have is that we have a rpm package (obviously) that uses some general tarball of the product as a source. Additionally we have rpm-specific files like .spec, init.d script, README, other scripts etc. Now the question is how should we include them in the package. I see two options: 1) include them as another source in the spec, so we will have two source tarballs 2) include rpm-specific files as a patch Are there any others? Now, under debian, the debian-specific files are included in diff.tar.gz so I was wondering if under rpm the recommended way is option 2. Thanks for help. Hubert -- [][][] Hubert Plociniczak [][] LShift Ltd [] [] www.lshift.net From michel.sylvan at gmail.com Fri Oct 10 13:02:35 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Fri, 10 Oct 2008 09:02:35 -0400 Subject: [Fedora-packaging] Packaging emacs modes: EL/F compatibility Message-ID: When packaging a package that contains Emacs mode files, should the Emacs subpackage require emacs(bin) or emacs? emacs(bin) seems to be commonly used, but this is not provided by RedHat/Fedora Emacs packages until version 22; RHEL 5.2 is still on 21.4 and thus EPEL packages would have to be specially handled. So the question is: is it better to use an %ifdef for non-Fedora releases or to just depend on emacs? Thanks, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From rdieter at math.unl.edu Fri Oct 10 13:18:55 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 10 Oct 2008 08:18:55 -0500 Subject: [Fedora-packaging] how to include rpm-specific files in the spec In-Reply-To: <48EF4F77.10202@lshift.net> References: <48EF4F77.10202@lshift.net> Message-ID: <48EF563F.7080807@math.unl.edu> Hubert Plociniczak wrote: > Hello, > > I couldn't find answer to my question on any guidelines page, so I am > going to ask the question on the list. > > The problem I have is that we have a rpm package (obviously) that uses > some general tarball of the product as a source. Additionally we have > rpm-specific files like .spec, init.d script, README, other scripts etc. > Now the question is how should we include them in the package. > I see two options: > 1) include them as another source in the spec, so we will have two > source tarballs option 1 is reasonable. -- Rex From hubert at lshift.net Fri Oct 10 13:21:48 2008 From: hubert at lshift.net (Hubert Plociniczak) Date: Fri, 10 Oct 2008 14:21:48 +0100 Subject: [Fedora-packaging] how to include rpm-specific files in the spec In-Reply-To: <48EF4F77.10202@lshift.net> References: <48EF4F77.10202@lshift.net> Message-ID: <48EF56EC.4030309@lshift.net> Hubert Plociniczak wrote: > Additionally we have > rpm-specific files like .spec, init.d script, README, other scripts etc. > My mistake, spec file doesn't belong to this group of files. One other, most commonly option is to just include tarball with already included rpm specific file. But then the source tarball would be different from the one that is publicly available... Hopefully someone will clarify this to me. Thanks, hubert -- [][][] Hubert Plociniczak [][] LShift Ltd [] [] www.lshift.net From jarod at redhat.com Fri Oct 10 13:19:50 2008 From: jarod at redhat.com (Jarod Wilson) Date: Fri, 10 Oct 2008 09:19:50 -0400 Subject: [Fedora-packaging] how to include rpm-specific files in the spec In-Reply-To: <48EF4F77.10202@lshift.net> References: <48EF4F77.10202@lshift.net> Message-ID: <200810100919.50828.jarod@redhat.com> On Friday 10 October 2008 08:49:59 Hubert Plociniczak wrote: > Hello, > > I couldn't find answer to my question on any guidelines page, so I am > going to ask the question on the list. > > The problem I have is that we have a rpm package (obviously) that uses > some general tarball of the product as a source. Additionally we have > rpm-specific files like .spec, init.d script, README, other scripts etc. > Now the question is how should we include them in the package. > I see two options: > 1) include them as another source in the spec, so we will have two > source tarballs > 2) include rpm-specific files as a patch > > Are there any others? > Now, under debian, the debian-specific files are included in diff.tar.gz > so I was wondering if under rpm the recommended way is option 2. Either 1 or 2 is acceptable, or even a mix of the two. Note that for #1, they don't necessarily have to be tarballs, the can be individual files if it makes sense. Pretty much up to the packager's best judgment how to get the additional bits included, the most important part is that the primary tarball(s) are pristine upstream sources (barring any license or patent issues that require ripping something out). -- Jarod Wilson jarod at redhat.com From jarod at redhat.com Fri Oct 10 13:26:45 2008 From: jarod at redhat.com (Jarod Wilson) Date: Fri, 10 Oct 2008 09:26:45 -0400 Subject: [Fedora-packaging] how to include rpm-specific files in the spec In-Reply-To: <48EF56EC.4030309@lshift.net> References: <48EF4F77.10202@lshift.net> <48EF56EC.4030309@lshift.net> Message-ID: <200810100926.45259.jarod@redhat.com> On Friday 10 October 2008 09:21:48 Hubert Plociniczak wrote: > Hubert Plociniczak wrote: > > Additionally we have > > rpm-specific files like .spec, init.d script, README, other scripts etc. > > My mistake, spec file doesn't belong to this group of files. > > One other, most commonly option is to just include tarball with already > included rpm specific file. But then the source tarball would be different > from the one that is publicly available... That's definitely a no-no. -- Jarod Wilson jarod at redhat.com From michel.sylvan at gmail.com Fri Oct 10 13:45:13 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Fri, 10 Oct 2008 09:45:13 -0400 Subject: [Fedora-packaging] Re: Packaging emacs modes: EL/F compatibility In-Reply-To: References: Message-ID: On Fri, Oct 10, 2008 at 9:02 AM, Michel Salim wrote: > When packaging a package that contains Emacs mode files, should the > Emacs subpackage require emacs(bin) or emacs? emacs(bin) seems to be > commonly used, but this is not provided by RedHat/Fedora Emacs > packages until version 22; RHEL 5.2 is still on 21.4 and thus EPEL > packages would have to be specially handled. > A related question: why emacs(bin) ? xemacs provides xemacs(bin) too so the question applies there. We don't ever plan for the binary to be provided in a subpackage, do we? Thanks, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From Matt_Domsch at dell.com Fri Oct 10 16:32:42 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 10 Oct 2008 11:32:42 -0500 Subject: [Fedora-packaging] app-local feature libraries, plugins Message-ID: <20081010163242.GB32643@auslistsprd01.us.dell.com> What are the best practices for handling app-local dynamically loaded libraries? Case in point: sblim-sfcb https://bugzilla.redhat.com/show_bug.cgi?id=466183 This has a bunch of .so files, specific application features, which it calls with dlopen() as those features become used. Current packaging has these all dumped into %{_libdir}/ which seems wrong to me. IMHO they belThis ong in %{_libdir}/%{name}/, and rather than add to /etc/ld.so.conf.d/, the application should simply dlopen() them from that directory directly. It appears this is what apache does. As a follow-on, should this same mechanism be used for plugin .so libs? Does it make sense to include something about this in the guidelines? Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From ville.skytta at iki.fi Fri Oct 10 17:12:26 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 10 Oct 2008 20:12:26 +0300 Subject: [Fedora-packaging] Re: Packaging emacs modes: EL/F compatibility In-Reply-To: References: Message-ID: <200810102012.26733.ville.skytta@iki.fi> On Friday 10 October 2008, Michel Salim wrote: > On Fri, Oct 10, 2008 at 9:02 AM, Michel Salim wrote: > > When packaging a package that contains Emacs mode files, should the > > Emacs subpackage require emacs(bin) or emacs? Depends. In the vast majority of cases "emacs(bin)", but it the elisp stuff specifically requires a full featured/X11 enabled emacs and does not work with emacs-nox, then "emacs" would be appropriate. Ditto for xemacs. > > emacs(bin) seems to be > > commonly used, but this is not provided by RedHat/Fedora Emacs > > packages until version 22; RHEL 5.2 is still on 21.4 and thus EPEL > > packages would have to be specially handled. > > A related question: why emacs(bin) ? Most elisp packages work fine with either emacs or emacs-nox installed. emacs(bin) is provided by both of them, and requiring it in lisp packages where appropriate is helpful so that the full featured (and much more dependency heavy) emacs package is not pulled in in setups that are fine with -nox, such as headless servers etc. > xemacs provides xemacs(bin) too > so the question applies there. We don't ever plan for the binary to be > provided in a subpackage, do we? We already have it kind of that way for both emacs and xemacs. The emacs, emacs-nox, xemacs, and xemacs-nox packages don't contain much more than just the respective executable. From jeff at ocjtech.us Fri Oct 10 17:00:16 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Fri, 10 Oct 2008 12:00:16 -0500 Subject: [Fedora-packaging] app-local feature libraries, plugins In-Reply-To: <20081010163242.GB32643@auslistsprd01.us.dell.com> References: <20081010163242.GB32643@auslistsprd01.us.dell.com> Message-ID: <935ead450810101000u5f87157eo6a74083fbf47fb6c@mail.gmail.com> On Fri, Oct 10, 2008 at 11:32 AM, Matt Domsch wrote: > What are the best practices for handling app-local dynamically loaded > libraries? > > IMHO > they belThis ong in %{_libdir}/%{name}/, and rather than add to > /etc/ld.so.conf.d/, the application should simply dlopen() them from > that directory directly. > > It appears this is what apache does. This is what Asterisk and CallWeaver do as well. -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From jdennis at redhat.com Fri Oct 10 17:43:38 2008 From: jdennis at redhat.com (John Dennis) Date: Fri, 10 Oct 2008 13:43:38 -0400 Subject: [Fedora-packaging] app-local feature libraries, plugins In-Reply-To: <935ead450810101000u5f87157eo6a74083fbf47fb6c@mail.gmail.com> References: <20081010163242.GB32643@auslistsprd01.us.dell.com> <935ead450810101000u5f87157eo6a74083fbf47fb6c@mail.gmail.com> Message-ID: <48EF944A.5060004@redhat.com> Jeffrey Ollie wrote: > On Fri, Oct 10, 2008 at 11:32 AM, Matt Domsch wrote: > >> What are the best practices for handling app-local dynamically loaded >> libraries? >> >> IMHO >> they belThis ong in %{_libdir}/%{name} >> >> It appears this is what apache does. >> > > This is what Asterisk and CallWeaver do as well. > And freeradius too. -- John Dennis -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matt_Domsch at dell.com Fri Oct 10 21:51:58 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 10 Oct 2008 16:51:58 -0500 Subject: [Fedora-packaging] app-local feature libraries, plugins In-Reply-To: <20081010163242.GB32643@auslistsprd01.us.dell.com> References: <20081010163242.GB32643@auslistsprd01.us.dell.com> Message-ID: <20081010215158.GA19434@auslistsprd01.us.dell.com> On Fri, Oct 10, 2008 at 11:32:42AM -0500, Matt Domsch wrote: > What are the best practices for handling app-local dynamically loaded > libraries? > > Case in point: sblim-sfcb > https://bugzilla.redhat.com/show_bug.cgi?id=466183 bug filed with sblim-sfcb upstream: https://sourceforge.net/tracker/?func=detail&atid=712784&aid=2158091&group_id=128809 Author acked: >Comment By: Chris Buccella (buccella) Date: 2008-10-10 17:41 Message: It's true; sfcb is currently a little messy. There is one sfcb .so that is used by another application (sfcc). Might need to direct sfcc on where libcimcClientSfcbLocal.so is moved to. -Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From michel.sylvan at gmail.com Fri Oct 10 23:33:45 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Fri, 10 Oct 2008 19:33:45 -0400 Subject: [Fedora-packaging] Re: Packaging emacs modes: EL/F compatibility In-Reply-To: <200810102012.26733.ville.skytta@iki.fi> References: <200810102012.26733.ville.skytta@iki.fi> Message-ID: On Fri, Oct 10, 2008 at 1:12 PM, Ville Skytt? wrote: >> A related question: why emacs(bin) ? > > Most elisp packages work fine with either emacs or emacs-nox installed. > emacs(bin) is provided by both of them, and requiring it in lisp packages > where appropriate is helpful so that the full featured (and much more > dependency heavy) emacs package is not pulled in in setups that are fine > with -nox, such as headless servers etc. > Unfortunately RHEL's emacs / emacs-nox do not seem to provide emacs(bin), so in that case, since RPM does not allow for either-or dependencies, what would the best solution be? 1. Requires: emacs and disenfranchise emacs-nox users 2. Requires: /usr/bin/emacs and draw the ire of yum users having to download filelists. Thanks, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From smooge at gmail.com Fri Oct 10 23:38:52 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 10 Oct 2008 17:38:52 -0600 Subject: [Fedora-packaging] Re: Packaging emacs modes: EL/F compatibility In-Reply-To: References: <200810102012.26733.ville.skytta@iki.fi> Message-ID: <80d7e4090810101638m4826f33ag86b098ca12a22b6e@mail.gmail.com> On Fri, Oct 10, 2008 at 5:33 PM, Michel Salim wrote: > On Fri, Oct 10, 2008 at 1:12 PM, Ville Skytt? wrote: > >>> A related question: why emacs(bin) ? >> >> Most elisp packages work fine with either emacs or emacs-nox installed. >> emacs(bin) is provided by both of them, and requiring it in lisp packages >> where appropriate is helpful so that the full featured (and much more >> dependency heavy) emacs package is not pulled in in setups that are fine >> with -nox, such as headless servers etc. >> > Unfortunately RHEL's emacs / emacs-nox do not seem to provide > emacs(bin), so in that case, since RPM does not allow for either-or > dependencies, what would the best solution be? > > 1. Requires: emacs and disenfranchise emacs-nox users > 2. Requires: /usr/bin/emacs and draw the ire of yum users having to > download filelists. > 3. Get RHEL to fix its packages? 4.x/5.x are still under support and could get updates. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From pertusus at free.fr Fri Oct 10 23:57:23 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 11 Oct 2008 01:57:23 +0200 Subject: [Fedora-packaging] Re: Packaging emacs modes: EL/F compatibility In-Reply-To: References: <200810102012.26733.ville.skytta@iki.fi> Message-ID: <20081010235723.GI3381@free.fr> On Fri, Oct 10, 2008 at 07:33:45PM -0400, Michel Salim wrote: > On Fri, Oct 10, 2008 at 1:12 PM, Ville Skytt? wrote: > > Unfortunately RHEL's emacs / emacs-nox do not seem to provide > emacs(bin), so in that case, since RPM does not allow for either-or > dependencies, what would the best solution be? > > 1. Requires: emacs and disenfranchise emacs-nox users > 2. Requires: /usr/bin/emacs and draw the ire of yum users having to > download filelists. /usr/bin/ is always downloaded. -- Pat From michel.sylvan at gmail.com Sat Oct 11 00:19:21 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Fri, 10 Oct 2008 20:19:21 -0400 Subject: [Fedora-packaging] Re: Packaging emacs modes: EL/F compatibility In-Reply-To: <20081010235723.GI3381@free.fr> References: <200810102012.26733.ville.skytta@iki.fi> <20081010235723.GI3381@free.fr> Message-ID: On Fri, Oct 10, 2008 at 7:57 PM, Patrice Dumas wrote: > On Fri, Oct 10, 2008 at 07:33:45PM -0400, Michel Salim wrote: >> On Fri, Oct 10, 2008 at 1:12 PM, Ville Skytt? wrote: >> >> Unfortunately RHEL's emacs / emacs-nox do not seem to provide >> emacs(bin), so in that case, since RPM does not allow for either-or >> dependencies, what would the best solution be? >> >> 1. Requires: emacs and disenfranchise emacs-nox users >> 2. Requires: /usr/bin/emacs and draw the ire of yum users having to >> download filelists. > > /usr/bin/ is always downloaded. > Ah, so one gets that for free? (the guideline should really mention that). I'll wait for an official word on the bug report, https://bugzilla.redhat.com/show_bug.cgi?id=466580 but if nothing comes up in the next few days, I might just do that. Thanks, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From a.badger at gmail.com Sat Oct 11 05:41:26 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 10 Oct 2008 22:41:26 -0700 Subject: [Fedora-packaging] Re: Packaging emacs modes: EL/F compatibility In-Reply-To: References: <200810102012.26733.ville.skytta@iki.fi> <20081010235723.GI3381@free.fr> Message-ID: <48F03C86.60607@gmail.com> Michel Salim wrote: > On Fri, Oct 10, 2008 at 7:57 PM, Patrice Dumas wrote: >> On Fri, Oct 10, 2008 at 07:33:45PM -0400, Michel Salim wrote: >>> On Fri, Oct 10, 2008 at 1:12 PM, Ville Skytt? wrote: >>> >>> Unfortunately RHEL's emacs / emacs-nox do not seem to provide >>> emacs(bin), so in that case, since RPM does not allow for either-or >>> dependencies, what would the best solution be? >>> >>> 1. Requires: emacs and disenfranchise emacs-nox users >>> 2. Requires: /usr/bin/emacs and draw the ire of yum users having to >>> download filelists. >> /usr/bin/ is always downloaded. >> > Ah, so one gets that for free? (the guideline should really mention > that). I'll wait for an official word on the bug report, > https://bugzilla.redhat.com/show_bug.cgi?id=466580 > The Guideline does mention that: """ - SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. """ The full Guideline[1]_ (linked from the above) repeats that information and also tells why those directories are okay. .. _[1]: https://fedoraproject.org/wiki/Packaging/Guidelines#FileDeps -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From dtimms at iinet.net.au Sun Oct 12 03:13:07 2008 From: dtimms at iinet.net.au (David Timms) Date: Sun, 12 Oct 2008 14:13:07 +1100 Subject: [Fedora-packaging] Re: rakarrack - alternative desktop categories In-Reply-To: <48853048.3080407@iinet.net.au> References: <487FBDC4.2070004@iinet.net.au> <1216557315.6668.42.camel@cage.kgw.TU-Berlin.DE> <48853048.3080407@iinet.net.au> Message-ID: <48F16B43.4050701@iinet.net.au> David Timms wrote: > Fernando Lopez-Lezcano wrote: >> 0.2.x is now in Planet CCRMA thanks to Arnaud from IRCAM. Great if you >> can/want to migrate it to Fedora! > I did submit a package review that I think meets the Fedora guidelines: > https://bugzilla.redhat.com/show_bug.cgi?id=455953 > >> I would appreciate it if you could >> keep the extra categories in the desktop file, they are used to classify >> audio apps in an extra menu I added to Planet CCRMA (and rakarrack would >> drop out of it if they were ommited). > The question you ask is a good one, and I understand where you are > coming from: {ccrma .spec} > ===== > # desktop file categories > BASE="X-Fedora Application AudioVideo" > XTRA="X-Digital_Processing X-Jack" > > %{__mkdir} -p %{buildroot}%{_datadir}/applications > desktop-file-install --vendor fedora \ > --dir %{buildroot}%{_datadir}/applications \ > `for c in ${BASE} ${XTRA} ; do echo "--add-category $c " ; done` \ > %{SOURCE1} > ===== > As I understand it, a Fedora package can use only the categories present > in the freedesktop.org spec: > http://fedoraproject.org/wiki/Packaging/Guidelines#.desktop_file_creation > http://standards.freedesktop.org/menu-spec/latest/apa.html > > Can a package use it's own categories, or must they meet the standards ? > > If there will be many audio apps {aka ccrma} packages, it would be best > to have them grouped in the same menu; the AudioVideo menu on my machine > is already overflowing more than a screenful, so I think it would be > good if these audio {only} apps get their own menu ? I have been making progress with the above review request, and am getting pretty close. It would be good if anyone having a definitive answer on this one could provide some guidance ;-) DaveT. From mclasen at redhat.com Sun Oct 12 03:30:52 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 11 Oct 2008 23:30:52 -0400 Subject: [Fedora-packaging] Re: rakarrack - alternative desktop categories In-Reply-To: <48F16B43.4050701@iinet.net.au> References: <487FBDC4.2070004@iinet.net.au> <1216557315.6668.42.camel@cage.kgw.TU-Berlin.DE> <48853048.3080407@iinet.net.au> <48F16B43.4050701@iinet.net.au> Message-ID: <1223782252.3474.3.camel@localhost.localdomain> On Sun, 2008-10-12 at 14:13 +1100, David Timms wrote: > > > > Can a package use it's own categories, or must they meet the standards ? > > > > If there will be many audio apps {aka ccrma} packages, it would be best > > to have them grouped in the same menu; the AudioVideo menu on my machine > > is already overflowing more than a screenful, so I think it would be > > good if these audio {only} apps get their own menu ? > I have been making progress with the above review request, and am > getting pretty close. It would be good if anyone having a definitive > answer on this one could provide some guidance ;-) > I don't see anything wrong with using non-standard categories, as long as they are prefixed with X-, as recommended in the menu spec, and are used _in addition_ to one of the registered main categories. Matthias From braden at endoframe.com Sun Oct 12 05:16:49 2008 From: braden at endoframe.com (Braden McDaniel) Date: Sun, 12 Oct 2008 01:16:49 -0400 Subject: [Fedora-packaging] PackagingDrafts/AutoConf Message-ID: <1223788609.13589.442.camel@hinge.endoframe.net> I would like to make some progress on this: The goal, I think, is incorporation of something like this into Fedora's Packaging Guidelines. I'm told this is the place to come. -- Braden McDaniel e-mail: Jabber: From dtimms at iinet.net.au Sun Oct 12 07:27:45 2008 From: dtimms at iinet.net.au (David Timms) Date: Sun, 12 Oct 2008 18:27:45 +1100 Subject: [Fedora-packaging] Re: rakarrack - alternative desktop categories In-Reply-To: <1223782252.3474.3.camel@localhost.localdomain> References: <487FBDC4.2070004@iinet.net.au> <1216557315.6668.42.camel@cage.kgw.TU-Berlin.DE> <48853048.3080407@iinet.net.au> <48F16B43.4050701@iinet.net.au> <1223782252.3474.3.camel@localhost.localdomain> Message-ID: <48F1A6F1.8020104@iinet.net.au> Matthias Clasen wrote: > On Sun, 2008-10-12 at 14:13 +1100, David Timms wrote: > >>> Can a package use it's own categories, or must they meet the standards ? >>> >>> If there will be many audio apps {aka ccrma} packages, it would be best >>> to have them grouped in the same menu; the AudioVideo menu on my machine >>> is already overflowing more than a screenful, so I think it would be >>> good if these audio {only} apps get their own menu ? >> I have been making progress with the above review request, and am >> getting pretty close. It would be good if anyone having a definitive >> answer on this one could provide some guidance ;-) >> > > I don't see anything wrong with using non-standard categories, as long > as they are prefixed with X-, as recommended in the menu spec, and are > used _in addition_ to one of the registered main categories. Thanks, Matthias. I can see that I was being overly strict in my interpretation of the standards. I'll definitely be adding the extra categories in addition to the registered categories. DaveT. From nicolas.mailhot at laposte.net Sun Oct 12 14:04:05 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 12 Oct 2008 16:04:05 +0200 Subject: [Fedora-packaging] Fontconfig rules installation guidelines change proposal Message-ID: <1223820245.9402.18.camel@arekh.okg> Hi all, I've queued the following small guideline change proposal for FPC consideration: http://fedoraproject.org/wiki/PackagingDrafts/Fonts_spec_template_correction_(fontconfig) Please add comments, reactions and corrections in the wiki. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From paul at all-the-johnsons.co.uk Tue Oct 14 09:11:45 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 14 Oct 2008 10:11:45 +0100 Subject: [Fedora-packaging] libgdiplus-devel subpackage Message-ID: <1223975505.18629.43.camel@PB3.Linux> Hi, Currently libgdiplus is broken into devel and the main package as per the packaging rules. However, the .so.0 files in the main package symlink to the -devel, so without the -devel subpackage, libgdiplus has problems. In mono, this is fixed (kind of) by having mono-winforms requiring libgdiplus-devel (which pulls in libgdiplus if it's not already installed). Not the best solution, but one which works. Obviously, this can't be used for libgdiplus. Given the nature of libgdiplus can an exception be made to this package so the .so file is bundled with the main package as well as the .pc file? I know it breaks the packaging regs, but I can't think of another way around it. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- 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 sergio.pasra at gmail.com Tue Oct 14 09:25:22 2008 From: sergio.pasra at gmail.com (Sergio Pascual) Date: Tue, 14 Oct 2008 11:25:22 +0200 Subject: [Fedora-packaging] libgdiplus-devel subpackage In-Reply-To: <1223975505.18629.43.camel@PB3.Linux> References: <1223975505.18629.43.camel@PB3.Linux> Message-ID: <89b36810810140225q5efbe00fp57080f15ed590280@mail.gmail.com> And why .so.0 file in the main package symlinks to the so in devel instead of linking to the .so.0.0.0 in main? Sergio On Tue, Oct 14, 2008 at 11:11 AM, Paul wrote: > Hi, > > Currently libgdiplus is broken into devel and the main package as per > the packaging rules. However, the .so.0 files in the main package > symlink to the -devel, so without the -devel subpackage, libgdiplus has > problems. > > In mono, this is fixed (kind of) by having mono-winforms requiring > libgdiplus-devel (which pulls in libgdiplus if it's not already > installed). Not the best solution, but one which works. Obviously, this > can't be used for libgdiplus. > > Given the nature of libgdiplus can an exception be made to this package > so the .so file is bundled with the main package as well as the .pc > file? I know it breaks the packaging regs, but I can't think of another > way around it. > > TTFN > > Paul > > -- > ?Sie k?nnen mich aufreizen und wirklich hei? machen! > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > > From rc040203 at freenet.de Tue Oct 14 11:09:24 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 14 Oct 2008 13:09:24 +0200 Subject: [Fedora-packaging] libgdiplus-devel subpackage In-Reply-To: <1223975505.18629.43.camel@PB3.Linux> References: <1223975505.18629.43.camel@PB3.Linux> Message-ID: <1223982564.3029.286.camel@beck.corsepiu.local> On Tue, 2008-10-14 at 10:11 +0100, Paul wrote: > Hi, > > Currently libgdiplus is broken into devel and the main package as per > the packaging rules. However, the .so.0 files in the main package > symlink to the -devel, so without the -devel subpackage, libgdiplus has > problems. > > In mono, this is fixed (kind of) by having mono-winforms requiring > libgdiplus-devel (which pulls in libgdiplus if it's not already > installed). Not the best solution, but one which works. Obviously, this > can't be used for libgdiplus. > > Given the nature of libgdiplus can an exception be made to this package > so the .so file is bundled with the main package as well as the .pc > file? No. > I know it breaks the packaging regs, but I can't think of another > way around it. Please explain, why libgdiplus.so must be part of the run-time. Ralf From tcallawa at redhat.com Tue Oct 14 14:50:24 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 14 Oct 2008 10:50:24 -0400 Subject: [Fedora-packaging] PackagingDrafts/AutoConf In-Reply-To: <1223788609.13589.442.camel@hinge.endoframe.net> References: <1223788609.13589.442.camel@hinge.endoframe.net> Message-ID: <1223995824.8459.5.camel@localhost.localdomain> On Sun, 2008-10-12 at 01:16 -0400, Braden McDaniel wrote: > I would like to make some progress on this: > > > > The goal, I think, is incorporation of something like this into Fedora's > Packaging Guidelines. I'm told this is the place to come. This is the right place... do you feel that Draft is ready for us to consider it for inclusion in the Packaging Guidelines as is? ~spot From a.badger at gmail.com Wed Oct 15 01:14:14 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 14 Oct 2008 18:14:14 -0700 Subject: [Fedora-packaging] PackagingDrafts/AutoConf In-Reply-To: <1223788609.13589.442.camel@hinge.endoframe.net> References: <1223788609.13589.442.camel@hinge.endoframe.net> Message-ID: <48F543E6.7060001@gmail.com> Braden McDaniel wrote: > I would like to make some progress on this: > > > > The goal, I think, is incorporation of something like this into Fedora's > Packaging Guidelines. I'm told this is the place to come. > Note that I will vote against this draft as written but I'm only one person on the FPC :-) I outlined in the other thread what kind of draft I would vote for. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From braden at endoframe.com Wed Oct 15 05:19:15 2008 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 15 Oct 2008 01:19:15 -0400 Subject: [Fedora-packaging] PackagingDrafts/AutoConf In-Reply-To: <1223995824.8459.5.camel@localhost.localdomain> References: <1223788609.13589.442.camel@hinge.endoframe.net> <1223995824.8459.5.camel@localhost.localdomain> Message-ID: <1224047955.8635.125.camel@hinge.endoframe.net> On Tue, 2008-10-14 at 10:50 -0400, Tom "spot" Callaway wrote: > On Sun, 2008-10-12 at 01:16 -0400, Braden McDaniel wrote: > > I would like to make some progress on this: > > > > > > > > The goal, I think, is incorporation of something like this into Fedora's > > Packaging Guidelines. I'm told this is the place to come. > > This is the right place... do you feel that Draft is ready for us to > consider it for inclusion in the Packaging Guidelines as is? After some discussion on fedora-devel, I'd say "not yet". While I do think it's appropriate to steer packagers toward patching configure and Makefile.in for trivial cases, I'm coming around to the notion that for more complex cases the prose should restrict itself to being informational. But I continue to think that certain invocations of the tools should be practically forbidden. ("autoreconf -f", I'm looking at you.) I'll ping back here when I think it's ready. -- Braden McDaniel e-mail: Jabber: From rc040203 at freenet.de Wed Oct 15 05:48:34 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 15 Oct 2008 07:48:34 +0200 Subject: [Fedora-packaging] PackagingDrafts/AutoConf In-Reply-To: <1224047955.8635.125.camel@hinge.endoframe.net> References: <1223788609.13589.442.camel@hinge.endoframe.net> <1223995824.8459.5.camel@localhost.localdomain> <1224047955.8635.125.camel@hinge.endoframe.net> Message-ID: <1224049714.3029.482.camel@beck.corsepiu.local> On Wed, 2008-10-15 at 01:19 -0400, Braden McDaniel wrote: > On Tue, 2008-10-14 at 10:50 -0400, Tom "spot" Callaway wrote: > > On Sun, 2008-10-12 at 01:16 -0400, Braden McDaniel wrote: > > > I would like to make some progress on this: > > > > > > > > > > > > The goal, I think, is incorporation of something like this into Fedora's > > > Packaging Guidelines. I'm told this is the place to come. > > > > This is the right place... do you feel that Draft is ready for us to > > consider it for inclusion in the Packaging Guidelines as is? > > After some discussion on fedora-devel, I'd say "not yet". ACK. > While I do think it's appropriate to steer packagers toward patching > configure and Makefile.in for trivial cases, I'm coming around to the > notion that for more complex cases the prose should restrict itself to > being informational. Not ACK. Patching auto-tools sources and generated files is always preferred, because only this guarantees deterministic builds. If I were to decide, I would ban all calls to the autotools inside of specs, unfortunately, many people do not want to accept this thought, and consider running the autotools inside of *specs to be superior. It's not a secret, I consider this practice to be "naive maintainers outsmarting themselves" and these people to be exposing Fedora packages to risks. Unfortunately, I am preaching at walls :) > But I continue to think that certain invocations > of the tools should be practically forbidden. ("autoreconf -f", I'm > looking at you.) autoreconf is just a wrapper aiming at automating invocations of the tools underneath and at replacing the plethora of (often broken) "bootstrap.sh / autogen.sh etc." scripts. So, if you intend to ban autoreconf, you should be consequent and ban all calls to the autotools. If you are aiming at banning "autoreconf -f" (Note: -f), then you are right, "autoreconf -f" is harmful in many cases. Ralf From braden at endoframe.com Wed Oct 15 06:57:19 2008 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 15 Oct 2008 02:57:19 -0400 Subject: [Fedora-packaging] PackagingDrafts/AutoConf In-Reply-To: <1224049714.3029.482.camel@beck.corsepiu.local> References: <1223788609.13589.442.camel@hinge.endoframe.net> <1223995824.8459.5.camel@localhost.localdomain> <1224047955.8635.125.camel@hinge.endoframe.net> <1224049714.3029.482.camel@beck.corsepiu.local> Message-ID: <1224053839.8635.151.camel@hinge.endoframe.net> On Wed, 2008-10-15 at 07:48 +0200, Ralf Corsepius wrote: > On Wed, 2008-10-15 at 01:19 -0400, Braden McDaniel wrote: > > On Tue, 2008-10-14 at 10:50 -0400, Tom "spot" Callaway wrote: > > > On Sun, 2008-10-12 at 01:16 -0400, Braden McDaniel wrote: > > > > I would like to make some progress on this: > > > > > > > > > > > > > > > > The goal, I think, is incorporation of something like this into Fedora's > > > > Packaging Guidelines. I'm told this is the place to come. > > > > > > This is the right place... do you feel that Draft is ready for us to > > > consider it for inclusion in the Packaging Guidelines as is? > > > > After some discussion on fedora-devel, I'd say "not yet". > ACK. > > > While I do think it's appropriate to steer packagers toward patching > > configure and Makefile.in for trivial cases, I'm coming around to the > > notion that for more complex cases the prose should restrict itself to > > being informational. > Not ACK. Patching auto-tools sources and generated files is always > preferred, because only this guarantees deterministic builds. "and"? If you're patching both the sources *and* the generated files, couldn't you wind up in a situation where the source is newer than the generated files (i.e., the source gets patched after the generated file)? If that happens, "make" calls the tools to regenerated stuff and you've just outsmarted yourself. This subtlety is avoidable with multiple different patches (applied in the correct order), of course; but for the purpose of a guideline, I'm inclined not to recommend patching both. > If I were to decide, I would ban all calls to the autotools inside of > specs, unfortunately, many people do not want to accept this thought, > and consider running the autotools inside of *specs to be superior. I agree, but I'm inclined to take a pragmatic approach where a package maintainer might need to do extensive patching to the build scripts. I think it's an exceptional case, but I don't want to make that guy's life hell. OTOH, I would certainly want the guideline to make clear that the autotools should not be run just for the hell of it (i.e., because the package maintainer wants to make sure the "latest stuff" gets used). > It's not a secret, I consider this practice to be "naive maintainers > outsmarting themselves" and these people to be exposing Fedora packages > to risks. > > Unfortunately, I am preaching at walls :) We're on the same page ideologically. But I want to find something that will be palatable to most packagers while addressing the most glaring potential for breakage. > > But I continue to think that certain invocations > > of the tools should be practically forbidden. ("autoreconf -f", I'm > > looking at you.) > > autoreconf is just a wrapper aiming at automating invocations of the > tools underneath and at replacing the plethora of (often broken) > "bootstrap.sh / autogen.sh etc." scripts. > > So, if you intend to ban autoreconf, you should be consequent and ban > all calls to the autotools. My motivation for banning autoreconf would be that it is a shotgun. I don't know if it can be relied upon to check timestamps and regenerate only what needs regenerating. I wouldn't want someone who needs to patch Makefile.[am/in] to wind up regenerating configure--that's silly. If it *can* be relied upon to respect timestamps, then I have no more quarrel with its use than I have with invoking any of the autotools directly. (Which is not to say that I have no quarrel with it.) > If you are aiming at banning "autoreconf -f" (Note: -f), then you are > right, "autoreconf -f" is harmful in many cases. I'd say every case. -- Braden McDaniel e-mail: Jabber: From rc040203 at freenet.de Wed Oct 15 07:39:02 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 15 Oct 2008 09:39:02 +0200 Subject: [Fedora-packaging] PackagingDrafts/AutoConf In-Reply-To: <1224053839.8635.151.camel@hinge.endoframe.net> References: <1223788609.13589.442.camel@hinge.endoframe.net> <1223995824.8459.5.camel@localhost.localdomain> <1224047955.8635.125.camel@hinge.endoframe.net> <1224049714.3029.482.camel@beck.corsepiu.local> <1224053839.8635.151.camel@hinge.endoframe.net> Message-ID: <1224056342.3029.501.camel@beck.corsepiu.local> On Wed, 2008-10-15 at 02:57 -0400, Braden McDaniel wrote: > On Wed, 2008-10-15 at 07:48 +0200, Ralf Corsepius wrote: > > On Wed, 2008-10-15 at 01:19 -0400, Braden McDaniel wrote: > > > On Tue, 2008-10-14 at 10:50 -0400, Tom "spot" Callaway wrote: > > > > On Sun, 2008-10-12 at 01:16 -0400, Braden McDaniel wrote: > > > > > I would like to make some progress on this: > > > > > > > > > > > > > > > > > > > > The goal, I think, is incorporation of something like this into Fedora's > > > > > Packaging Guidelines. I'm told this is the place to come. > > > > > > > > This is the right place... do you feel that Draft is ready for us to > > > > consider it for inclusion in the Packaging Guidelines as is? > > > > > > After some discussion on fedora-devel, I'd say "not yet". > > ACK. > > > > > While I do think it's appropriate to steer packagers toward patching > > > configure and Makefile.in for trivial cases, I'm coming around to the > > > notion that for more complex cases the prose should restrict itself to > > > being informational. > > Not ACK. Patching auto-tools sources and generated files is always > > preferred, because only this guarantees deterministic builds. > > "and"? If you're patching both the sources *and* the generated files, > couldn't you wind up in a situation where the source is newer than the > generated files (i.e., the source gets patched after the generated > file)? Yes, it would require preserving timestamps and/or touching files. Preserving timestamps isn't easily doable with rpm (c.f. option -T in man patch), but touching often is very simple. Depending on the complexity of a patch and the complexity of a package, normally reduces to very few touch'es (working principle: set the time stamps of modified files to that of an unmodified file at the root of auto*tools dependency) e.g. often a touch -r aclocal.m4 configure.* or similar after applying a patch works. > > > But I continue to think that certain invocations > > > of the tools should be practically forbidden. ("autoreconf -f", I'm > > > looking at you.) > > > > autoreconf is just a wrapper aiming at automating invocations of the > > tools underneath and at replacing the plethora of (often broken) > > "bootstrap.sh / autogen.sh etc." scripts. > > > > So, if you intend to ban autoreconf, you should be consequent and ban > > all calls to the autotools. > > My motivation for banning autoreconf would be that it is a shotgun. Agreed. > I > don't know if it can be relied upon to check timestamps and regenerate > only what needs regenerating. AFAICT, older autoreconf's had been problematic, but newer ones seem to work quite well with packages having been developed with modern autotools - At least, I haven't see a breakage for while a while. > I wouldn't want someone who needs to > patch Makefile.[am/in] to wind up regenerating configure--that's silly. It's not that silly, because newer automake/aclocal's require newer autoconf's. The effects only show on rare occasions, nevertheless they occasionally show. However, more often you encounter cases, where regenerating Makefile.am's with new automakes breaks Makefile.ins, which had been developed with old automakes. > If it *can* be relied upon to respect timestamps, then I have no more > quarrel with its use than I have with invoking any of the autotools > directly. (Which is not to say that I have no quarrel with it.) > > > If you are aiming at banning "autoreconf -f" (Note: -f), then you are > > right, "autoreconf -f" is harmful in many cases. > > I'd say every case. :) Ralf From enrico.scholz at informatik.tu-chemnitz.de Wed Oct 15 07:52:51 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 15 Oct 2008 09:52:51 +0200 Subject: [Fedora-packaging] Re: PackagingDrafts/AutoConf In-Reply-To: <1224053839.8635.151.camel@hinge.endoframe.net> (Braden McDaniel's message of "Wed, 15 Oct 2008 02:57:19 -0400") References: <1223788609.13589.442.camel@hinge.endoframe.net> <1223995824.8459.5.camel@localhost.localdomain> <1224047955.8635.125.camel@hinge.endoframe.net> <1224049714.3029.482.camel@beck.corsepiu.local> <1224053839.8635.151.camel@hinge.endoframe.net> Message-ID: <87prm2cn1o.fsf@sheridan.bigo.ensc.de> Braden McDaniel writes: >> Not ACK. Patching auto-tools sources and generated files is always >> preferred, because only this guarantees deterministic builds. > > "and"? If you're patching both the sources *and* the generated files, > couldn't you wind up in a situation where the source is newer than the > generated files (i.e., the source gets patched after the generated > file)? Use 'touch --reference' and submit an patch to upstream which adds 'AM_MAINTAINER_MODE' to configure.ac. Enrico From pertusus at free.fr Wed Oct 15 08:10:45 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 15 Oct 2008 10:10:45 +0200 Subject: [Fedora-packaging] PackagingDrafts/AutoConf In-Reply-To: <1224047955.8635.125.camel@hinge.endoframe.net> References: <1223788609.13589.442.camel@hinge.endoframe.net> <1223995824.8459.5.camel@localhost.localdomain> <1224047955.8635.125.camel@hinge.endoframe.net> Message-ID: <20081015081045.GD2795@free.fr> On Wed, Oct 15, 2008 at 01:19:15AM -0400, Braden McDaniel wrote: > On Tue, 2008-10-14 at 10:50 -0400, Tom "spot" Callaway wrote: > > On Sun, 2008-10-12 at 01:16 -0400, Braden McDaniel wrote: > > > I would like to make some progress on this: > > > > > > > > > > > > The goal, I think, is incorporation of something like this into Fedora's > > > Packaging Guidelines. I'm told this is the place to come. > > > > This is the right place... do you feel that Draft is ready for us to > > consider it for inclusion in the Packaging Guidelines as is? > > After some discussion on fedora-devel, I'd say "not yet". > > While I do think it's appropriate to steer packagers toward patching > configure and Makefile.in for trivial cases, I'm coming around to the > notion that for more complex cases the prose should restrict itself to > being informational. But I continue to think that certain invocations I think that it would be very nice if you could summary the whole conversation in http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks with a (controversial) in the title. I personnally think that this kind of complicate recommendation should not be in the guideline in any case, the guidelines are already too big, but it should definitively be somewhere such that one has just to point to the text when doing reviews. -- Pat From braden at endoframe.com Wed Oct 15 08:19:21 2008 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 15 Oct 2008 04:19:21 -0400 Subject: [Fedora-packaging] Re: PackagingDrafts/AutoConf In-Reply-To: <87prm2cn1o.fsf@sheridan.bigo.ensc.de> References: <1223788609.13589.442.camel@hinge.endoframe.net> <1223995824.8459.5.camel@localhost.localdomain> <1224047955.8635.125.camel@hinge.endoframe.net> <1224049714.3029.482.camel@beck.corsepiu.local> <1224053839.8635.151.camel@hinge.endoframe.net> <87prm2cn1o.fsf@sheridan.bigo.ensc.de> Message-ID: <1224058761.8635.154.camel@hinge.endoframe.net> On Wed, 2008-10-15 at 09:52 +0200, Enrico Scholz wrote: > Braden McDaniel writes: > > >> Not ACK. Patching auto-tools sources and generated files is always > >> preferred, because only this guarantees deterministic builds. > > > > "and"? If you're patching both the sources *and* the generated files, > > couldn't you wind up in a situation where the source is newer than the > > generated files (i.e., the source gets patched after the generated > > file)? > > Use 'touch --reference' and submit an patch to upstream which adds > 'AM_MAINTAINER_MODE' to configure.ac. Many maintainers have made a conscious choice not to use that macro. I know I have. -- Braden McDaniel e-mail: Jabber: From opensource at till.name Wed Oct 15 08:53:11 2008 From: opensource at till.name (Till Maas) Date: Wed, 15 Oct 2008 10:53:11 +0200 Subject: [Fedora-packaging] Re: PackagingDrafts/AutoConf In-Reply-To: <1224058761.8635.154.camel@hinge.endoframe.net> References: <1223788609.13589.442.camel@hinge.endoframe.net> <87prm2cn1o.fsf@sheridan.bigo.ensc.de> <1224058761.8635.154.camel@hinge.endoframe.net> Message-ID: <200810151053.18295.opensource@till.name> On Wed October 15 2008, Braden McDaniel wrote: > On Wed, 2008-10-15 at 09:52 +0200, Enrico Scholz wrote: > > Use 'touch --reference' and submit an patch to upstream which adds > > 'AM_MAINTAINER_MODE' to configure.ac. > > Many maintainers have made a conscious choice not to use that macro. I > know I have. Why? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From rc040203 at freenet.de Wed Oct 15 09:09:19 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 15 Oct 2008 11:09:19 +0200 Subject: [Fedora-packaging] Re: PackagingDrafts/AutoConf In-Reply-To: <200810151053.18295.opensource@till.name> References: <1223788609.13589.442.camel@hinge.endoframe.net> <87prm2cn1o.fsf@sheridan.bigo.ensc.de> <1224058761.8635.154.camel@hinge.endoframe.net> <200810151053.18295.opensource@till.name> Message-ID: <1224061759.3029.541.camel@beck.corsepiu.local> On Wed, 2008-10-15 at 10:53 +0200, Till Maas wrote: > On Wed October 15 2008, Braden McDaniel wrote: > > On Wed, 2008-10-15 at 09:52 +0200, Enrico Scholz wrote: > > > > Use 'touch --reference' and submit an patch to upstream which adds > > > 'AM_MAINTAINER_MODE' to configure.ac. > > > > Many maintainers have made a conscious choice not to use that macro. I > > know I have. > > Why? I can't speak for Braden, but AM_MAINTAINER_MODE is _VERY_ controversial. Some people like it, others hate it. Read "info Automake" for more details. In a nutshell: AM_MAINTAINER_MODE suppresses the deps we are discussing here. This allows people to get away with packages containing broken timestamps, which introduces risks to upstreams if not handled with care and is unhandy for upstream usage. FWIW: I am upstream maintainer of a package, which uses AM_MAINTAINER_MODE. The most frequently answered question related to building issues is: "Did you pass --enable-maintainer-mode?" Openly said, I regret ever having introduce it to this package's configuration. Ralf From enrico.scholz at informatik.tu-chemnitz.de Wed Oct 15 09:47:08 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 15 Oct 2008 11:47:08 +0200 Subject: [Fedora-packaging] Re: PackagingDrafts/AutoConf In-Reply-To: <1224061759.3029.541.camel@beck.corsepiu.local> (Ralf Corsepius's message of "Wed, 15 Oct 2008 11:09:19 +0200") References: <1223788609.13589.442.camel@hinge.endoframe.net> <87prm2cn1o.fsf@sheridan.bigo.ensc.de> <1224058761.8635.154.camel@hinge.endoframe.net> <200810151053.18295.opensource@till.name> <1224061759.3029.541.camel@beck.corsepiu.local> Message-ID: <87ej2i42cj.fsf@fc5.bigo.ensc.de> Ralf Corsepius writes: > AM_MAINTAINER_MODE suppresses the deps we are discussing here. > > This allows people to get away with packages containing broken > timestamps, which introduces risks to upstreams if not handled with > care and is unhandy for upstream usage. When you are upstream, you have probably mechanism/scripts to call configure with special parameters (e.g. adding '-g3' to CFLAGS, setting a writable '--prefix', setting another CC). Putting an '--enable-maintainer-mode' there does not harm. > I am upstream maintainer of a package, which uses AM_MAINTAINER_MODE. The > most frequently answered question related to building issues is: "Did you > pass --enable-maintainer-mode?" Reducing stability (-> occasional autotool invocations in uncontrolled environments) and removing features (-> ability to patch configure) just to avoid some support requests is a bad deal. Enrico From rc040203 at freenet.de Wed Oct 15 10:11:37 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 15 Oct 2008 12:11:37 +0200 Subject: [Fedora-packaging] Re: PackagingDrafts/AutoConf In-Reply-To: <87ej2i42cj.fsf@fc5.bigo.ensc.de> References: <1223788609.13589.442.camel@hinge.endoframe.net> <87prm2cn1o.fsf@sheridan.bigo.ensc.de> <1224058761.8635.154.camel@hinge.endoframe.net> <200810151053.18295.opensource@till.name> <1224061759.3029.541.camel@beck.corsepiu.local> <87ej2i42cj.fsf@fc5.bigo.ensc.de> Message-ID: <1224065497.3029.546.camel@beck.corsepiu.local> On Wed, 2008-10-15 at 11:47 +0200, Enrico Scholz wrote: > Ralf Corsepius writes: > > > AM_MAINTAINER_MODE suppresses the deps we are discussing here. > > > > This allows people to get away with packages containing broken > > timestamps, which introduces risks to upstreams if not handled with > > care and is unhandy for upstream usage. > > When you are upstream, you have probably mechanism/scripts to call > configure with special parameters (e.g. adding '-g3' to CFLAGS, > setting a writable '--prefix', setting another CC). Putting an > '--enable-maintainer-mode' there does not harm. My problem is a bit different (cf. below). > > I am upstream maintainer of a package, which uses AM_MAINTAINER_MODE. The > > most frequently answered question related to building issues is: "Did you > > pass --enable-maintainer-mode?" > > Reducing stability (-> occasional autotool invocations in uncontrolled > environments) and removing features (-> ability to patch configure) just > to avoid some support requests is a bad deal. People (developers) are working on CVS check outs and wonder why the Makefile don't do what they expect rsp. why their autotool-generated files don't get updated, when rebuilding their works. Cause: They forgot --enable-maintainer-mode. Ralf From nicolas.mailhot at laposte.net Wed Oct 15 20:34:16 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 15 Oct 2008 22:34:16 +0200 Subject: [Fedora-packaging] Re: Fontconfig rules installation guidelines change proposal In-Reply-To: <48F6401F.3040301@behdad.org> References: <1223820245.9402.18.camel@arekh.okg> <48F6401F.3040301@behdad.org> Message-ID: <1224102856.4844.12.camel@arekh.okg> Le mercredi 15 octobre 2008 ? 15:10 -0400, Behdad Esfahbod a ?crit : conf.avail and conf.dyyyyyyyyyyyyyyy > Hi Nicolas, Hi Behdad, Thank you for reviewing it, > I like the direction of it. > > The idea of having separate conf.avail and conf.d is that sysadmins can > symlink/unlink entries into conf.d to enable/disable configuration for their > system. This would only work if upgrading fontconfig/fonts rpms does not > reinstate the unlinked symlink. However, last time I checked this was not > working correctly. Can you check this first? I didn't write it in the wiki, but as far as I understand rpm it is not possible to tell it "if this file/symlink does not exist do not install it". So this bit of conf.avail/conf.d design will never work on rpm systems. And even if it worked, what you'd actually need would be "if this file does not exist and was installed by a previous rpm" to handle initial deployment. Which starts to be real hairy. (more generally treating absence of an item as disabling this item is a broken computer pattern IMHO.) However (someone please check this) it's probably possible to disable an entry permanently by creating a symlink with the same name pointing somewhere else (how does fontconfig reacts to /dev/null symlinks or symlinks pointing to empty files)? So having a repository of pre-deployed config snippets is fine with me. Also (and this bit is traced on the wiki) as I understand the FHS /etc/.../conf.avail is a complete no-go and should be moved to /usr/share/something if we want to be clean. And that before /etc/.../conf.avail is duplicated in many packages. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From braden at endoframe.com Wed Oct 15 23:44:42 2008 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 15 Oct 2008 19:44:42 -0400 Subject: [Fedora-packaging] Re: PackagingDrafts/AutoConf In-Reply-To: <200810151053.18295.opensource@till.name> References: <1223788609.13589.442.camel@hinge.endoframe.net> <87prm2cn1o.fsf@sheridan.bigo.ensc.de> <1224058761.8635.154.camel@hinge.endoframe.net> <200810151053.18295.opensource@till.name> Message-ID: <1224114282.8635.162.camel@hinge.endoframe.net> On Wed, 2008-10-15 at 10:53 +0200, Till Maas wrote: > On Wed October 15 2008, Braden McDaniel wrote: > > On Wed, 2008-10-15 at 09:52 +0200, Enrico Scholz wrote: > > > > Use 'touch --reference' and submit an patch to upstream which adds > > > 'AM_MAINTAINER_MODE' to configure.ac. > > > > Many maintainers have made a conscious choice not to use that macro. I > > know I have. > > Why? * Many users expect the dependency checking it turns off by default to be on by default. * I think it is entirely appropriate to expect those who play with the timestamps of files in a distribution to take care when doing so. And what Ralf said. And as Ralf noted, this macro is controversial enough to have that controversy noted in its documentation in the Automake manual. Rehashing that controversy here isn't going to change anything. -- Braden McDaniel e-mail: Jabber: From nicolas.mailhot at laposte.net Thu Oct 16 07:39:56 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 16 Oct 2008 09:39:56 +0200 (CEST) Subject: [Fedora-packaging] Re: Fontconfig rules installation guidelines change proposal In-Reply-To: <48F654EF.5000505@behdad.org> References: <1223820245.9402.18.camel@arekh.okg> <48F6401F.3040301@behdad.org> <1224102856.4844.12.camel@arekh.okg> <48F654EF.5000505@behdad.org> Message-ID: <4122c5e09deac33103f3079265aedf3a.squirrel@arekh.dyndns.org> Le Mer 15 octobre 2008 22:39, Behdad Esfahbod a ?crit : > > Nicolas Mailhot wrote: >> Le mercredi 15 octobre 2008 ? 15:10 -0400, Behdad Esfahbod a ?crit : >>> The idea of having separate conf.avail and conf.d is that sysadmins >>> can >>> symlink/unlink entries into conf.d to enable/disable configuration >>> for their >>> system. This would only work if upgrading fontconfig/fonts rpms >>> does not >>> reinstate the unlinked symlink. However, last time I checked this >>> was not >>> working correctly. Can you check this first? >> >> I didn't write it in the wiki, but as far as I understand rpm it is >> not >> possible to tell it "if this file/symlink does not exist do not >> install >> it". So this bit of conf.avail/conf.d design will never work on rpm >> systems. And even if it worked, what you'd actually need would be >> "if >> this file does not exist and was installed by a previous rpm" to >> handle >> initial deployment. Which starts to be real hairy. > > Well, it is: don't include the symlink in the RPM but create it in > %post, and > only if no previous versions of the package were installed ($1 = 0 > IIRC). Yurk. How safe is it WRT package renames? Because we've been renaming font packages a lot in the past (and I plan another mass rename for F11, hopefully the last one but I wouldn't bet anything I care about on it). Really this is being too clever for your own good IMHO. >> However (someone please check this) it's probably possible to >> disable an >> entry permanently by creating a symlink with the same name pointing >> somewhere else > > This can be ok. If it works, we can document it. >> Also (and this bit is traced on the wiki) as I understand the >> FHS /etc/.../conf.avail is a complete no-go and should be moved >> to /usr/share/something if we want to be clean. And that >> before /etc/.../conf.avail is duplicated in many packages. > > Really? Where does it talk about those kind of stuff? In conf.avail files are not really user-editable config files (in fact you don't use config(noreplace) so any package update will stomp on user modifications). They're more static configuration blocks users can not change but only activate/desactivate in conf.d via symlinks, and as such they match the "read-only architecture independent data files" definition of /usr/share. That rpmlint complains of %config files without noreplace in /etc is a pretty strong hint those files are misplaced. In fact one can wonder what's good is there %config-ing them at all. IIRC there was a pretty long thread on the subject in fedora-devel in the last months, but I don't have the time to pull it from archives. -- Nicolas Mailhot From braden at endoframe.com Thu Oct 16 06:43:49 2008 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 16 Oct 2008 02:43:49 -0400 Subject: [Fedora-packaging] PackagingDrafts/AutoConf In-Reply-To: <1224056342.3029.501.camel@beck.corsepiu.local> References: <1223788609.13589.442.camel@hinge.endoframe.net> <1223995824.8459.5.camel@localhost.localdomain> <1224047955.8635.125.camel@hinge.endoframe.net> <1224049714.3029.482.camel@beck.corsepiu.local> <1224053839.8635.151.camel@hinge.endoframe.net> <1224056342.3029.501.camel@beck.corsepiu.local> Message-ID: <1224139429.8635.173.camel@hinge.endoframe.net> On Wed, 2008-10-15 at 09:39 +0200, Ralf Corsepius wrote: > On Wed, 2008-10-15 at 02:57 -0400, Braden McDaniel wrote: [snip] > > I wouldn't want someone who needs to > > patch Makefile.[am/in] to wind up regenerating configure--that's silly. > It's not that silly, because newer automake/aclocal's require newer > autoconf's. Good point; but automake isn't terribly aggressive about this. For instance, I don't think automake 1.10 depends on any autoconf features/fixes past 2.59. In general, I think one is better off using the packaged configure until it breaks. -- Braden McDaniel e-mail: Jabber: From overholt at redhat.com Fri Oct 17 14:53:56 2008 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 17 Oct 2008 10:53:56 -0400 Subject: [Fedora-packaging] Updates to Eclipse Plugin packaging guidelines Message-ID: <20081017145355.GA17890@redhat.com> Hi, I have a few updates to the Eclipse Plugin packaging guidelines. They include some clarifications, typos, and updates for Eclipse 3.4.x. The only bit of real substance is modifying the template to note how we're using the dropins mechanism for plugin installation in 3.4.x and above. I've attached a diff 'cause I don't think I can commit it. Can someone else? Thanks, Andrew -------------- next part -------------- --- EclipsePlugins.orig.txt 2008-10-17 10:17:07.000000000 -0400 +++ EclipsePlugins.txt 2008-10-17 10:37:25.000000000 -0400 @@ -36,10 +36,10 @@ Eclipse plugins '''SHOULD''' be built with the Eclipse Plugin Development Environment (PDE; PDE Build specifically) because these builds are generally easier to maintain. ant builds are acceptable, but are generally more difficult to maintain. Following what upstream does is the best practice. === pdebuild === -As of Fedora 9, there is a script that makes invoking PDE Build easy: /usr/share/eclipse/buildscripts/pdebuild: +As of Fedora 9, there is a script that makes invoking PDE Build easy: /usr/lib{,64}/eclipse/buildscripts/pdebuild: 
-usage: /usr/share/eclipse/buildscripts/pdebuild [] 
+usage: /usr/lib{,64}/eclipse/buildscripts/pdebuild [] 
 
 Use PDE Build to build Eclipse features
 
@@ -52,6 +52,7 @@
 -j      VM arguments (ex. -DJ2SE-1.5=%{_jvmdir}/java/jre/lib/rt.jar)
 -v      Be verbose
 -D      Debug platform itself (passes -consolelog -debug to Eclipse)
+-o      Orbit dependencies
{{Template:Warning}} Note: PDE Build must be called explicitly in Fedora 8 and earlier (including EPEL 5). The following snippet may be used to replace the pdebuild call in the template: @@ -80,7 +81,7 @@ ==== EPEL 5 ==== -The copy-platform script is in a different location on RHEL 5 than it is in Fedora. If calling copy-platform explicitly, the following snippet may be useful to facilitate Eclipse plugins for EPEL 5: +The copy-platform script is in a different location on RHEL 5 than it is in Fedora. If calling copy-platform explicitly, the following snippet may be useful to facilitate building Eclipse plugins for EPEL 5: 
 %if 0%{?rhel} == 5
 /bin/sh -x %{_libdir}/eclipse/buildscripts/copy-platform SDK %{eclipse_base}
@@ -90,14 +91,23 @@
== File Locations == -All plugin jars should go into %{_datadir}/eclipse/plugins and features should go into %{_datadir}/eclipse/features. The only exception is for fragments which should go into %{_libdir}/eclipse/plugins (and features if applicable). +All platform-independent plugins/features should go into %{_datadir}/eclipse/dropins/. JARs should therefore go into %{_datadir}/eclipse/dropins//plugins and features should go into %{_datadir}/eclipse/dropins//features. Architecture-specific plugins/features should go into %{_libdir}/eclipse/dropins/. JARs should therefore go into %{_libdir}/eclipse/dropins//plugins and features should go into %{_datadir}/eclipse/dropins//features. Example: + +
+%install
+rm -rf %{buildroot}
+installDir=%{buildroot}%{_datadir}/eclipse/dropins/quickrex
+install -d -m 755 $installDir
+unzip -q -d $installDir \
+ build/rpmBuild/de.babe.eclipse.plugins.QuickREx.zip
+
== Arch vs. noarch == While many Eclipse plugins will be architecture-independent, please follow the ["Packaging/GCJGuidelines"] with regards to gcj ahead-of-time compilation. As those guidelines specify, gcj-compiled packages are arch-dependent and are thus not noarch. == Things to avoid == === Pre-built binaries === -If Eclipse plugins depend upon third party libraries (and licensing permits it), developers often include these libraries directly in their source control system. In this case, the libraries must exist as other packages in Fedora and their contents (such as their jars) be symlinked from within the source and build trees of the Eclipse plugin being packaged. While it may make source archives smaller in size if they are cleansed of these pre-built files, it is not necessary to do so unless the libraries themselves are not redistributable. Binary RPMs '''MUST NOT''' include pre-built files. +If Eclipse plugins depend upon third party libraries (and licensing permits it), developers often include these libraries directly in their source control system. In this case, the libraries must exist as other packages in Fedora and their contents (such as their JARs) be symlinked from within the source and build trees of the Eclipse plugin being packaged. While it may make source archives smaller in size if they are cleansed of these pre-built files, it is not necessary to do so unless the libraries themselves are not redistributable. Binary RPMs '''MUST NOT''' include pre-built files. {{Template:Note}} A simple check which may be run at the end of %prep (courtesy David Walluck (I think that's who gave it to Ben Konrath)): 
@@ -108,21 +118,21 @@
 fi
 done
 if [ ! -z "$JARS" ] ; then
-echo "These jars should be deleted and symlinked to system jars: $JARS"
+echo "These JARs should be deleted and symlinked to system JARs: $JARS"
 exit 1
 fi
=== Differing from upstream === Plugins that are jarred should remain jarred and those that are expanded should be expanded in their RPM. There are two cases (that we can think of as of this writing) that warrant diverging from upstream: -1. Symlinking to a binary jar from another package -1. Expanding a jar to allow for symlinking to a binary jar from another package +# Symlinking to a binary JAR from another package +# Expanding a JAR to allow for symlinking to a binary JAR from another package -See below for a tip on how to deal with the expanded jar case. +See below for a tip on how to deal with the expanded JAR case. == Specfile Template == 
-%define eclipse_base        %{_datadir}/eclipse
+%define eclipse_base        %{_libdir}/eclipse
 
 Name:           eclipse-plugin
 Version:        1.0
@@ -162,10 +172,10 @@
 
 %install
 rm -rf $RPM_BUILD_ROOT
-install -d -m 755 $RPM_BUILD_ROOT%{eclipse_base}
-unzip -q -d $RPM_BUILD_ROOT%{eclipse_base}/.. \
+install -d -m 755 $RPM_BUILD_ROOT%{_datadir}/eclipse/dropins/plugin-a
+unzip -q -d $RPM_BUILD_ROOT%{_datadir}/eclipse/dropins/plugin-a \
 build/rpmBuild/org.eclipse.plugin_feature.zip
-unzip -q -d $RPM_BUILD_ROOT%{eclipse_base}/.. \
+unzip -q -d $RPM_BUILD_ROOT%{_datadir}/eclipse/dropins/plugin-b \
 build/rpmBuild/org.eclipse.plugin.b_feature.zip
 
 %clean
@@ -173,23 +183,16 @@
 
 %files
 %defattr(-,root,root,-)
-%{eclipse_base}/plugins/org.eclipse.plugin.a_*.jar
-%{eclipse_base}/plugins/org.eclipse.plugin.c_*.jar
-%dir %{eclipse_base}/features/org.eclipse.plugin_feature_*
-%doc %{eclipse_base}/features/org.eclipse.plugin_feature_*/license.html
-%doc %{eclipse_base}/features/org.eclipse.plugin_feature_*/about.html
-%doc %{eclipse_base}/features/org.eclipse.plugin_feature_*/epl-v10.html
-%{eclipse_base}/features/org.eclipse.plugin_feature_*/feature.xml
+%{_datadir}/eclipse/dropins/plugin-a
 
 %files b
 %defattr(-,root,root,-)
-%{eclipse_base}/plugins/org.eclipse.plugin.b_*.jar
-%dir %{eclipse_base}/features/org.eclipse.plugin.b_feature_*
-%doc %{eclipse_base}/features/org.eclipse.plugin.b_feature_*/license.html
-%doc %{eclipse_base}/features/org.eclipse.plugin.b_feature_*/epl-v10.html
-%{eclipse_base}/features/org.eclipse.plugin.b_feature_*/feature.xml
+%{_datadir}/eclipse/dropins/plugin-b
 
 %changelog
+* Fri Oct 17 2008 Andrew Overholt  1.0-2
+- Update for Eclipse 3.4.x
+
 * Fri Feb 29 2008 Andrew Overholt  1.0-1
 - Initial Fedora package
@@ -197,7 +200,7 @@ == Tips and Notes == === Common Defines === -%define eclipse_base %{_datadir}/eclipse and, if necessary %define eclipse_lib_base %{_libdir}/eclipse. +%define eclipse_base %{_libdir}/eclipse. === Requires === Until rpmstubby (see below) is released and/or more widespread, Requires on bits provided by the Eclipse SDK (RCP, SWT, Platform, JDT, PDE, CVS, etc.) should only be on the binary package providing the required functionality (ex. eclipse-cvs-client or eclipse-rcp). For IDE features, the most common requirement will be eclipse-platform. @@ -224,7 +227,7 @@ 98051 12-20-07 20:08 lib-xmlrpc/xmlrpc-common-3.0.jar -Note that we have embedded jars which we would like to turn into symlinks to existing jars (from other packages). If we simply unzip the plugin jar and symlink, one would think we would be okay: +Note that we have embedded JARs which we would like to turn into symlinks to existing JARs (from other packages). If we simply unzip the plugin JAR and symlink, one would think we would be okay: 
 $ unzip -qq org.eclipse.mylyn.web.core_2.2.0.I20071220-1700.jar
@@ -234,7 +237,7 @@
 $
-However, we end up with the plugin classes themselves being expanded in the org directory. [https://bugzilla.redhat.com/273881 Bug #273881] causes build failures when building debuginfo packages in this case. The acceptable workaround is to modify the build.properties file in the plugin to jar the plugin code separately (ex. mylyn-webcore.jar) and include it within this expanded plugin directory. An example of this work-around can be seen in [http://cvs.fedoraproject.org/viewcvs/devel/eclipse-mylyn/ eclipse-mylyn] (specifically the patches related to org.eclipse.mylyn.webcore). +However, we end up with the plugin classes themselves being expanded in the org directory. [https://bugzilla.redhat.com/273881 Bug #273881] causes build failures when building debuginfo packages in this case. The acceptable workaround is to modify the build.properties file in the plugin to JAR the plugin code separately (ex. mylyn-webcore.jar) and include it within this expanded plugin directory. An example of this work-around can be seen in [http://cvs.fedoraproject.org/viewcvs/devel/eclipse-mylyn/ eclipse-mylyn] (specifically the patches related to org.eclipse.mylyn.webcore). === OSGi === OSGi bundles contain metadata just like RPMs do. This metadata can be used to automatically generate Provides and Requires similar to how it is done for mono packages. This functionality exists in Fedora's current rpm package but requires some investigation as at the time of this writing it does not appear to be functioning properly. From tcallawa at redhat.com Fri Oct 17 15:11:58 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 17 Oct 2008 11:11:58 -0400 Subject: [Fedora-packaging] Updates to Eclipse Plugin packaging guidelines In-Reply-To: <20081017145355.GA17890@redhat.com> References: <20081017145355.GA17890@redhat.com> Message-ID: <1224256318.3176.7.camel@localhost.localdomain> On Fri, 2008-10-17 at 10:53 -0400, Andrew Overholt wrote: > Hi, > > I have a few updates to the Eclipse Plugin packaging guidelines. They > include some clarifications, typos, and updates for Eclipse 3.4.x. The > only bit of real substance is modifying the template to note how we're > using the dropins mechanism for plugin installation in 3.4.x and above. +1 to this diff. ~spot From tibbs at math.uh.edu Fri Oct 17 16:28:33 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 17 Oct 2008 11:28:33 -0500 Subject: [Fedora-packaging] Updates to Eclipse Plugin packaging guidelines In-Reply-To: <20081017145355.GA17890@redhat.com> References: <20081017145355.GA17890@redhat.com> Message-ID: +1 to these changes. -- Jason L Tibbitts III - tibbs at math.uh.edu - 713/743-3486 - 660PGH - 94 PC800 System Manager: University of Houston Department of Mathematics And with death The knowledge comes It was the life all along We'd been afraid of From pertusus at free.fr Fri Oct 17 21:45:44 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 17 Oct 2008 23:45:44 +0200 Subject: [Fedora-packaging] package without .elc files and emacs guidelines Message-ID: <20081017214544.GE2681@free.fr> Hello, In the librep there are some .el files, and Michal Jaegermann explained in https://bugzilla.redhat.com/show_bug.cgi?id=431250#c23 that the .elc files are not needed (and sometimes harmful). This is not very consistent with the Emacs guidelines. Maybe the guidelines could be amended for this case? -- Pat From opensource at till.name Sun Oct 19 15:57:53 2008 From: opensource at till.name (Till Maas) Date: Sun, 19 Oct 2008 17:57:53 +0200 Subject: [Fedora-packaging] Re: PackagingDrafts/AutoConf In-Reply-To: <1224065497.3029.546.camel@beck.corsepiu.local> References: <1223788609.13589.442.camel@hinge.endoframe.net> <87ej2i42cj.fsf@fc5.bigo.ensc.de> <1224065497.3029.546.camel@beck.corsepiu.local> Message-ID: <200810191758.07415.opensource@till.name> On Wed October 15 2008, Ralf Corsepius wrote: > People (developers) are working on CVS check outs and wonder why the > Makefile don't do what they expect rsp. why their autotool-generated > files don't get updated, when rebuilding their works. > > Cause: They forgot --enable-maintainer-mode. I guess it would help to add "--enable-maintainer-mode" to the autogen.sh script or create such a script that should be run by maintainers, instead of making everyone type this option manually. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From paul at all-the-johnsons.co.uk Mon Oct 20 22:41:31 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 20 Oct 2008 23:41:31 +0100 Subject: [Fedora-packaging] Moonlight support within MonoDevelop Message-ID: <1224542491.19767.4.camel@PB3.Linux> Hi, I know that moonlight is a no-go area due to Novell's insanity and love up with the Borg, but is support for moonlight from within MonoDevelop also a no-go area? I've asked on the Mono-packaging list if there is a way to disable moonlight support within MD, but I doubt there will be an easy solution. Advice required on this. I don't want to have to start hacking things around if support doesn't violate the rules. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- 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 tcallawa at redhat.com Tue Oct 21 15:02:45 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 21 Oct 2008 11:02:45 -0400 Subject: [Fedora-packaging] Moonlight support within MonoDevelop In-Reply-To: <1224542491.19767.4.camel@PB3.Linux> References: <1224542491.19767.4.camel@PB3.Linux> Message-ID: <1224601365.3343.24.camel@localhost.localdomain> On Mon, 2008-10-20 at 23:41 +0100, Paul wrote: > Hi, > > I know that moonlight is a no-go area due to Novell's insanity and love > up with the Borg, but is support for moonlight from within MonoDevelop > also a no-go area? > > I've asked on the Mono-packaging list if there is a way to disable > moonlight support within MD, but I doubt there will be an easy solution. > > Advice required on this. I don't want to have to start hacking things > around if support doesn't violate the rules. Yeah. We can't enable moonlight support in MD. I'm sorry about this, because I know it is painful, but Novell is to blame for this. ~spot From denis at poolshark.org Tue Oct 21 16:39:04 2008 From: denis at poolshark.org (Denis Leroy) Date: Tue, 21 Oct 2008 18:39:04 +0200 Subject: [Fedora-packaging] Updates to Eclipse Plugin packaging guidelines In-Reply-To: <20081017145355.GA17890@redhat.com> References: <20081017145355.GA17890@redhat.com> Message-ID: <48FE05A8.8040901@poolshark.org> Andrew Overholt wrote: > Hi, > > I have a few updates to the Eclipse Plugin packaging guidelines. They > include some clarifications, typos, and updates for Eclipse 3.4.x. The > only bit of real substance is modifying the template to note how we're > using the dropins mechanism for plugin installation in 3.4.x and above. > > I've attached a diff 'cause I don't think I can commit it. Can someone > else? +1 from me From jonathan.underwood at gmail.com Wed Oct 22 17:06:14 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 22 Oct 2008 18:06:14 +0100 Subject: [Fedora-packaging] package without .elc files and emacs guidelines In-Reply-To: <20081017214544.GE2681@free.fr> References: <20081017214544.GE2681@free.fr> Message-ID: <645d17210810221006h3a4c4c71w592b650ae0f897b1@mail.gmail.com> 2008/10/17 Patrice Dumas : > Hello, > > In the librep there are some .el files, and Michal Jaegermann explained > in > https://bugzilla.redhat.com/show_bug.cgi?id=431250#c23 > that the .elc files are not needed (and sometimes harmful). This is not > very consistent with the Emacs guidelines. Maybe the guidelines could be > amended for this case? I think he's wrong. If something doesn't work when byte compiled (.elc), then that's a bug. When loading many lisp files at startup, byte compilation still provides noticeable speedup, even on recent machines. So, no, I'd oppose changing the guidelines in this regard. It's a bit like saying "we don't need .pyc" files, as we can work just from the .py files (except that emacs doesn't do automatic byte compilation in the way that python does if a pyc isn't present or is older than the .py). Michal does allude to one ugliness of byte compilation - you do often need a packages .el files around when doing byte compilation of another package for function definitions, and this can lead to bootstrapping needs (see emacs-vm and emacs-bbdb for an example). [As an aside, that package should really be putting its files in a subdirectory of %{emacs_lispdir}.] From ville.skytta at iki.fi Thu Oct 23 21:24:26 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 24 Oct 2008 00:24:26 +0300 Subject: [Fedora-packaging] package without .elc files and emacs guidelines In-Reply-To: <645d17210810221006h3a4c4c71w592b650ae0f897b1@mail.gmail.com> References: <20081017214544.GE2681@free.fr> <645d17210810221006h3a4c4c71w592b650ae0f897b1@mail.gmail.com> Message-ID: <200810240024.27390.ville.skytta@iki.fi> On Wednesday 22 October 2008, Jonathan Underwood wrote: > 2008/10/17 Patrice Dumas : > > Hello, > > > > In the librep there are some .el files, and Michal Jaegermann explained > > in > > https://bugzilla.redhat.com/show_bug.cgi?id=431250#c23 > > that the .elc files are not needed (and sometimes harmful). This is not > > very consistent with the Emacs guidelines. Maybe the guidelines could be > > amended for this case? > > I think he's wrong. If something doesn't work when byte compiled > (.elc), then that's a bug. Strictly speaking, I don't think it's always quite that black and white. Depending on the .el, byte compilation in one configuration may end up "optimizing away" things that are not needed in that configuration, but might be needed in other configurations where the .elc is supposed to be used. Or the other way around, it may end up byte compiling things that are needed in the build configuration but are not needed and can cause duplicate definitions or other weirdness in others. For example detecting availability of some features - typically .el that supports multiple *Emacs versions by providing internal replacements for some things not found in the build configuration - and conditionally byte compiling them. Reviewing eval-when-compile's in the .el might reveal some but not all potential problems. defmacro's are another thing that could be useful to check (AFAIU, IIRC, but then again I don't have that deep knowledge about these things). In practice this is rarely a problem in Fedora as the .elc are quite likely to be used in pretty much the same configuration (Emacs version, other lisp libs loaded from load-path) as with what they were built with. But if configurations differ enough such as .elc byte compiled with Emacs ending up in XEmacs' load path or vice versa, or .elc byte compiled with one *Emacs version and run with another, breakage is not at all unlikely. Granted, the best fix for these situations is not omitting byte-compilation altogether, but rather ensuring incompatible *emacs don't mess around with .elcs in each others' load paths, and using strict enough rpm level dependency versioning on the target *emacs. From jonathan.underwood at gmail.com Fri Oct 24 11:07:15 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 24 Oct 2008 12:07:15 +0100 Subject: [Fedora-packaging] package without .elc files and emacs guidelines In-Reply-To: <200810240024.27390.ville.skytta@iki.fi> References: <20081017214544.GE2681@free.fr> <645d17210810221006h3a4c4c71w592b650ae0f897b1@mail.gmail.com> <200810240024.27390.ville.skytta@iki.fi> Message-ID: <645d17210810240407o6bd1a1b3ief703431f68ed40f@mail.gmail.com> 2008/10/23 Ville Skytt? : > On Wednesday 22 October 2008, Jonathan Underwood wrote: >> 2008/10/17 Patrice Dumas : >> > Hello, >> > >> > In the librep there are some .el files, and Michal Jaegermann explained >> > in >> > https://bugzilla.redhat.com/show_bug.cgi?id=431250#c23 >> > that the .elc files are not needed (and sometimes harmful). This is not >> > very consistent with the Emacs guidelines. Maybe the guidelines could be >> > amended for this case? >> >> I think he's wrong. If something doesn't work when byte compiled >> (.elc), then that's a bug. > > Strictly speaking, I don't think it's always quite that black and white. > > Depending on the .el, byte compilation in one configuration may end > up "optimizing away" things that are not needed in that configuration, but > might be needed in other configurations where the .elc is supposed to be > used. Or the other way around, it may end up byte compiling things that are > needed in the build configuration but are not needed and can cause duplicate > definitions or other weirdness in others. For example detecting availability > of some features - typically .el that supports multiple *Emacs versions by > providing internal replacements for some things not found in the build > configuration - and conditionally byte compiling them. > > Reviewing eval-when-compile's in the .el might reveal some but not all > potential problems. defmacro's are another thing that could be useful to > check (AFAIU, IIRC, but then again I don't have that deep knowledge about > these things). > > In practice this is rarely a problem in Fedora as the .elc are quite likely to > be used in pretty much the same configuration (Emacs version, other lisp libs > loaded from load-path) as with what they were built with. Yes, key here is having the correct BuildRequires to ensure other elisp packages of relevance are installed at build time (eg. emacs-vm and emacs-bbdb require each other at build time to ensure the correct macros are compiled). But if > configurations differ enough such as .elc byte compiled with Emacs ending up > in XEmacs' load path or vice versa, or .elc byte compiled with one *Emacs > version and run with another, breakage is not at all unlikely. Granted, the > best fix for these situations is not omitting byte-compilation altogether, > but rather ensuring incompatible *emacs don't mess around with .elcs in each > others' load paths, and using strict enough rpm level dependency versioning > on the target *emacs. Agreed, but currently we try to mitigate that by having packages Require the version of Emacs that was used for byte compilation (or a later version) with the rather messy macros in the guidelines. If we want to broaden our scope further to allow for multiple emacs versions to be installed, then we can do what Debian does. But, really, I think that's an unnecessary world of pain. From pertusus at free.fr Sat Oct 25 13:40:44 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 25 Oct 2008 15:40:44 +0200 Subject: [Fedora-packaging] BR exception could be simplified Message-ID: <20081025134044.GE2608@free.fr> Hello, I think that at http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2 the sentence 'The derived list of all deps pulled in by this list is on Packaging/FullExceptionList . ' should be removed, and the Packaging/FullExceptionList page should also be removed. -- Pat From pertusus at free.fr Sat Oct 25 13:47:55 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 25 Oct 2008 15:47:55 +0200 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora Message-ID: <20081025134755.GF2608@free.fr> Hello, In http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description I suggest changing README.Fedora to README.Dist, see for an argumentation: http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_using_fedora_or_redhat -- Pat From dominik at greysector.net Sat Oct 25 14:07:23 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sat, 25 Oct 2008 16:07:23 +0200 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025134755.GF2608@free.fr> References: <20081025134755.GF2608@free.fr> Message-ID: <20081025140722.GA3363@mokona.greysector.net> On Saturday, 25 October 2008 at 15:47, Patrice Dumas wrote: > Hello, > > In > http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description > > I suggest changing README.Fedora to README.Dist, see for an > argumentation: > http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_using_fedora_or_redhat +1 I'm not sure if the new name is informative enough, but I don't have any better alternatives right now. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From mtasaka at ioa.s.u-tokyo.ac.jp Sat Oct 25 14:11:31 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 25 Oct 2008 23:11:31 +0900 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025134755.GF2608@free.fr> References: <20081025134755.GF2608@free.fr> Message-ID: <49032913.2060201@ioa.s.u-tokyo.ac.jp> Patrice Dumas wrote, at 10/25/2008 10:47 PM +9:00: > Hello, > > In > http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description > > I suggest changing README.Fedora to README.Dist, see for an > argumentation: > http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_using_fedora_or_redhat > But README.fedora may be _really_ Fedora specific issue (e.g. for better performance another files are needed but packaging them altogether cannot be done due to Fedora policy, as you and I wrote on xtide-common package) Mamoru From pertusus at free.fr Sat Oct 25 14:22:01 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 25 Oct 2008 16:22:01 +0200 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <49032913.2060201@ioa.s.u-tokyo.ac.jp> References: <20081025134755.GF2608@free.fr> <49032913.2060201@ioa.s.u-tokyo.ac.jp> Message-ID: <20081025142201.GG2608@free.fr> On Sat, Oct 25, 2008 at 11:11:31PM +0900, Mamoru Tasaka wrote: > Patrice Dumas wrote, at 10/25/2008 10:47 PM +9:00: >> Hello, >> >> In >> http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description >> >> I suggest changing README.Fedora to README.Dist, see for an >> argumentation: >> http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_using_fedora_or_redhat >> > > But README.fedora may be _really_ Fedora specific issue > (e.g. for better performance another files are needed but packaging > them altogether cannot be done due to Fedora policy, as you and I wrote > on xtide-common package) These are not really fedora specific. If I was to review xtide I would have insisted on this file being called xtide-README.dist. For example it is also true for EPEL. And it is also certainly true for any free software distribution. So I think that this is a bug in xtide. Would you accept patches to correct this? -- Pat From pertusus at free.fr Sat Oct 25 14:25:15 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 25 Oct 2008 16:25:15 +0200 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <49032913.2060201@ioa.s.u-tokyo.ac.jp> References: <20081025134755.GF2608@free.fr> <49032913.2060201@ioa.s.u-tokyo.ac.jp> Message-ID: <20081025142514.GH2608@free.fr> On Sat, Oct 25, 2008 at 11:11:31PM +0900, Mamoru Tasaka wrote: > > But README.fedora may be _really_ Fedora specific issue > (e.g. for better performance another files are needed but packaging > them altogether cannot be done due to Fedora policy, as you and I wrote > on xtide-common package) It may happen, to have something really fedora specific, and not specific of a rpm distribution, but I think that this only happens for a tiny number of packages. In fact I have never seen this case in real life. So it seem to me that the guidelines should address the most common case which is README.Dist. -- Pat From jussi.lehtola at iki.fi Sat Oct 25 14:41:23 2008 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Sat, 25 Oct 2008 17:41:23 +0300 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025142201.GG2608@free.fr> References: <20081025134755.GF2608@free.fr> <49032913.2060201@ioa.s.u-tokyo.ac.jp> <20081025142201.GG2608@free.fr> Message-ID: <1224945683.3373.6.camel@tb900.no-ip.org> On Sat, 2008-10-25 at 16:22 +0200, Patrice Dumas wrote: > These are not really fedora specific. If I was to review xtide I would > have insisted on this file being called xtide-README.dist. For example > it is also true for EPEL. And it is also certainly true for any > free software distribution. So I think that this is a bug in xtide. To me README.dist is too generic - it sounds like it's from upstream. README.Fedora clearly tells you that the file is Fedora-specific. Isn't EPEL also part of Fedora? I don't find anything wrong with using Fedora in EPEL packages. Or, if README.Fedora seems illogical to you to use in EPEL, make conditionals in the spec file so that the file is README.Fedora in Fedora and README.EPEL in EPEL. Of course, if you want to use the same package in other RPM-based distributions than Fedora/EPEL, then the Fedora suffix is out of the question. -- Jussi Lehtola From pertusus at free.fr Sat Oct 25 14:49:35 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 25 Oct 2008 16:49:35 +0200 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <1224945683.3373.6.camel@tb900.no-ip.org> References: <20081025134755.GF2608@free.fr> <49032913.2060201@ioa.s.u-tokyo.ac.jp> <20081025142201.GG2608@free.fr> <1224945683.3373.6.camel@tb900.no-ip.org> Message-ID: <20081025144934.GI2608@free.fr> On Sat, Oct 25, 2008 at 05:41:23PM +0300, Jussi Lehtola wrote: > On Sat, 2008-10-25 at 16:22 +0200, Patrice Dumas wrote: > > These are not really fedora specific. If I was to review xtide I would > > have insisted on this file being called xtide-README.dist. For example > > it is also true for EPEL. And it is also certainly true for any > > free software distribution. So I think that this is a bug in xtide. > > To me README.dist is too generic - it sounds like it's from upstream. > README.Fedora clearly tells you that the file is Fedora-specific. But in general those files are not fedora specific. That being said I'd have no problem with a file named something else than README.dist or README.distribution that convey the idea that it is added by the distributor, and not upstream. What do you propose? > Isn't EPEL also part of Fedora? I don't find anything wrong with using > Fedora in EPEL packages. It is confusing at best. > Or, if README.Fedora seems illogical to you to > use in EPEL, make conditionals in the spec file so that the file is > README.Fedora in Fedora and README.EPEL in EPEL. That's much too complicated, especially when the file is not really fedora specific as it is the case in all the cases I have seen. > Of course, if you want to use the same package in other RPM-based > distributions than Fedora/EPEL, then the Fedora suffix is out of the > question. It is not really the issue here. The point is that these files are in general not fedora specific, it is not about the intention, but about the status of the file. -- Pat From fedora at leemhuis.info Sat Oct 25 14:53:42 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 25 Oct 2008 16:53:42 +0200 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025134755.GF2608@free.fr> References: <20081025134755.GF2608@free.fr> Message-ID: <490332F6.3040504@leemhuis.info> On 25.10.2008 15:47, Patrice Dumas wrote: > > In > http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description > > I suggest changing README.Fedora to README.Dist, see for an > argumentation: > http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_using_fedora_or_redhat I really appreciate the general idea, but I don't like the term ".Dist" to much, as it is a bit misleading imho: some people might think that file might contain "informations relevant for distribution of the package". I thought about a alternative, but all my mind came up with was "distribution-specific-notes" -- that has the same problem as noted above, but it's imho not that worse. But that filename is quite long :-/ Maybe somebody else comes up with something that is shorter and more accurate... CU knurd From paul at city-fan.org Sat Oct 25 15:31:38 2008 From: paul at city-fan.org (Paul Howarth) Date: Sat, 25 Oct 2008 16:31:38 +0100 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <490332F6.3040504@leemhuis.info> References: <20081025134755.GF2608@free.fr> <490332F6.3040504@leemhuis.info> Message-ID: <20081025163138.55ad7b09@metropolis.intra.city-fan.org> On Sat, 25 Oct 2008 16:53:42 +0200 Thorsten Leemhuis wrote: > On 25.10.2008 15:47, Patrice Dumas wrote: > > > > In > > http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description > > > > I suggest changing README.Fedora to README.Dist, see for an > > argumentation: > > http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_using_fedora_or_redhat > > I really appreciate the general idea, but I don't like the term > ".Dist" to much, as it is a bit misleading imho: some people might > think that file might contain "informations relevant for distribution > of the package". > > I thought about a alternative, but all my mind came up with was > "distribution-specific-notes" -- that has the same problem as noted > above, but it's imho not that worse. But that filename is quite > long :-/ > > Maybe somebody else comes up with something that is shorter and more > accurate... I tend to use "README.RPM" or some variant thereof (e.g. README-SELinux.RPM). Paul. From mtasaka at ioa.s.u-tokyo.ac.jp Sat Oct 25 15:54:54 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 26 Oct 2008 00:54:54 +0900 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025142514.GH2608@free.fr> References: <20081025134755.GF2608@free.fr> <49032913.2060201@ioa.s.u-tokyo.ac.jp> <20081025142514.GH2608@free.fr> Message-ID: <4903414E.8060702@ioa.s.u-tokyo.ac.jp> Patrice Dumas wrote, at 10/25/2008 11:25 PM +9:00: > On Sat, Oct 25, 2008 at 11:11:31PM +0900, Mamoru Tasaka wrote: >> But README.fedora may be _really_ Fedora specific issue >> (e.g. for better performance another files are needed but packaging >> them altogether cannot be done due to Fedora policy, as you and I wrote >> on xtide-common package) > > It may happen, to have something really fedora specific, and not specific > of a rpm distribution, I don't care about other distrubution than Fedora. Well, the file named "README.Fedora" I wrote is really what I meant for Fedora. I don't want to take any responsibility for other distrubution. The maintainers on other distribution may want to reuse what I wrote for Fedora, but in such case the maintainer (of other distrubution) must mention: ------------------------------------------------------- The notes Fedora maintainer writes are also applied to the package distributed on this distrubition, so I bollowed the notes. If you see something wrong on this notes please ask "me", not Fedora maintainer. ------------------------------------------------------- Well, I think generally the package maintainer on a distrubution must write the notes for the distrubution (if any) by his/her responsibility. From ville.skytta at iki.fi Sat Oct 25 19:02:25 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 25 Oct 2008 22:02:25 +0300 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025163138.55ad7b09@metropolis.intra.city-fan.org> References: <20081025134755.GF2608@free.fr> <490332F6.3040504@leemhuis.info> <20081025163138.55ad7b09@metropolis.intra.city-fan.org> Message-ID: <200810252202.25562.ville.skytta@iki.fi> On Saturday 25 October 2008, Paul Howarth wrote: > On Sat, 25 Oct 2008 16:53:42 +0200 > Thorsten Leemhuis wrote: > > > I really appreciate the general idea, but I don't like the term > > ".Dist" to much, as it is a bit misleading imho: some people might > > think that file might contain "informations relevant for distribution > > of the package". > > > > I thought about a alternative, but all my mind came up with was > > "distribution-specific-notes" -- that has the same problem as noted > > above, but it's imho not that worse. But that filename is quite > > long :-/ > > > > Maybe somebody else comes up with something that is shorter and more > > accurate... > > I tend to use "README.RPM" or some variant thereof (e.g. > README-SELinux.RPM). .RPM sounds a bit like it could be a rpm package whose name is README. I've usually used README.package myself. From rc040203 at freenet.de Sat Oct 25 19:31:34 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 25 Oct 2008 21:31:34 +0200 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025134755.GF2608@free.fr> References: <20081025134755.GF2608@free.fr> Message-ID: <1224963094.6682.80.camel@beck.corsepiu.local> On Sat, 2008-10-25 at 15:47 +0200, Patrice Dumas wrote: > Hello, > > In > http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description > > I suggest changing README.Fedora to README.Dist, see for an > argumentation: > http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_using_fedora_or_redhat -1 Leave such implementation details to the packager's discretion. Ralf From tibbs at math.uh.edu Sat Oct 25 20:21:22 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 25 Oct 2008 15:21:22 -0500 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025134755.GF2608@free.fr> References: <20081025134755.GF2608@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> I suggest changing README.Fedora to README.Dist I disagree. README.Fedora is a fine name, and is what I always recommend in review. - J< From pertusus at free.fr Sat Oct 25 22:17:58 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 26 Oct 2008 00:17:58 +0200 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <4903414E.8060702@ioa.s.u-tokyo.ac.jp> References: <20081025134755.GF2608@free.fr> <49032913.2060201@ioa.s.u-tokyo.ac.jp> <20081025142514.GH2608@free.fr> <4903414E.8060702@ioa.s.u-tokyo.ac.jp> Message-ID: <20081025221758.GB2685@free.fr> On Sun, Oct 26, 2008 at 12:54:54AM +0900, Mamoru Tasaka wrote: > > I don't care about other distrubution than Fedora. > Well, the file named "README.Fedora" I wrote is really what I meant > for Fedora. I don't want to take any responsibility for other distrubution. It is not about taking responsibility or not. It is about the change being fedora specific or not. If you look at the xtide package, what is in th eREADME.Fedora is not specific of fedora. It is specific of the package, sure, but not of fedora. > The maintainers on other distribution may want to reuse what I wrote > for Fedora, but in such case the maintainer (of other distrubution) > must mention: > ------------------------------------------------------- > The notes Fedora maintainer writes are also applied to the package > distributed on this distrubition, so I bollowed the notes. > > If you see something wrong on this notes please ask "me", not Fedora > maintainer. > ------------------------------------------------------- =Only if the license say so, and it currently doesn't. > Well, I think generally the package maintainer on a distrubution > must write the notes for the distrubution (if any) by his/her > responsibility. Right, but, in the xtide case, and it is true of all the case I have come accross, the notes have nothing fedora specific (apart from the bugzilla adress, and it is in any case not the right place to tell where fedora bugzilla is). They are linked with how the package is done, but have nothing fedora specific, really. -- Pat From pertusus at free.fr Sat Oct 25 22:20:39 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 26 Oct 2008 00:20:39 +0200 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <1224963094.6682.80.camel@beck.corsepiu.local> References: <20081025134755.GF2608@free.fr> <1224963094.6682.80.camel@beck.corsepiu.local> Message-ID: <20081025222039.GC2685@free.fr> On Sat, Oct 25, 2008 at 09:31:34PM +0200, Ralf Corsepius wrote: > On Sat, 2008-10-25 at 15:47 +0200, Patrice Dumas wrote: > > Hello, > > > > In > > http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description > > > > I suggest changing README.Fedora to README.Dist, see for an > > argumentation: > > http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_using_fedora_or_redhat > -1 > > Leave such implementation details to the packager's discretion. It is only a (controversial) recommendation and I never wanted to make it a guideline. But in most of the case the file is not fedora specific, it is p?ckage specific so I think it should be reflected in the name. -- Pat From rjones at redhat.com Sat Oct 25 22:22:04 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 25 Oct 2008 23:22:04 +0100 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025134755.GF2608@free.fr> References: <20081025134755.GF2608@free.fr> Message-ID: <20081025222204.GA19759@amd.home.annexia.org> On Sat, Oct 25, 2008 at 03:47:55PM +0200, Patrice Dumas wrote: > I suggest changing README.Fedora to README.Dist, see for an > argumentation: > http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_using_fedora_or_redhat Urgghh ... a lot of pointless make-work. What's the point? Debian ship 'README.Debian' files. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From pertusus at free.fr Sat Oct 25 22:24:05 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 26 Oct 2008 00:24:05 +0200 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: References: <20081025134755.GF2608@free.fr> Message-ID: <20081025222405.GD2685@free.fr> On Sat, Oct 25, 2008 at 03:21:22PM -0500, Jason L Tibbitts III wrote: > >>>>> "PD" == Patrice Dumas writes: > > PD> I suggest changing README.Fedora to README.Dist > > I disagree. README.Fedora is a fine name, and is what I always > recommend in review. Are these files really fedora specific, or package specific? In most cases they are package specific, so I think the file name should reflect that, and also it helps others (or EPEL) reuse spec files. -- Pat From pertusus at free.fr Sat Oct 25 22:25:51 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 26 Oct 2008 00:25:51 +0200 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025222204.GA19759@amd.home.annexia.org> References: <20081025134755.GF2608@free.fr> <20081025222204.GA19759@amd.home.annexia.org> Message-ID: <20081025222551.GE2685@free.fr> On Sat, Oct 25, 2008 at 11:22:04PM +0100, Richard W.M. Jones wrote: > On Sat, Oct 25, 2008 at 03:47:55PM +0200, Patrice Dumas wrote: > > I suggest changing README.Fedora to README.Dist, see for an > > argumentation: > > http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_using_fedora_or_redhat > > Urgghh ... a lot of pointless make-work. What's the point? Debian > ship 'README.Debian' files. It is not an obligation it is a recommendation. And it is in general both more accurate and help others reuse spec files. There are many packages using README.Fedora in fedora, and what debian does is not necessarily to be copied. -- Pat From dominik at greysector.net Sat Oct 25 22:38:21 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 26 Oct 2008 00:38:21 +0200 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025140722.GA3363@mokona.greysector.net> References: <20081025134755.GF2608@free.fr> <20081025140722.GA3363@mokona.greysector.net> Message-ID: <20081025223820.GD6333@mokona.greysector.net> On Saturday, 25 October 2008 at 16:07, Dominik 'Rathann' Mierzejewski wrote: > On Saturday, 25 October 2008 at 15:47, Patrice Dumas wrote: > > Hello, > > > > In > > http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description > > > > I suggest changing README.Fedora to README.Dist, see for an > > argumentation: > > http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_using_fedora_or_redhat > > +1 > I'm not sure if the new name is informative enough, but I don't > have any better alternatives right now. I have one now: README.package. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From pertusus at free.fr Sat Oct 25 22:41:05 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 26 Oct 2008 00:41:05 +0200 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025223820.GD6333@mokona.greysector.net> References: <20081025134755.GF2608@free.fr> <20081025140722.GA3363@mokona.greysector.net> <20081025223820.GD6333@mokona.greysector.net> Message-ID: <20081025224105.GG2685@free.fr> On Sun, Oct 26, 2008 at 12:38:21AM +0200, Dominik 'Rathann' Mierzejewski wrote: > > I have one now: README.package. Agreed, I also think that it is the best one. I have updated https://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_using_fedora_or_redhat_.28controversial.29 (and I have explicitely stated that it is controversial). -- Pat From rc040203 at freenet.de Sun Oct 26 04:06:05 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 26 Oct 2008 05:06:05 +0100 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025222039.GC2685@free.fr> References: <20081025134755.GF2608@free.fr> <1224963094.6682.80.camel@beck.corsepiu.local> <20081025222039.GC2685@free.fr> Message-ID: <1224993965.6682.108.camel@beck.corsepiu.local> On Sun, 2008-10-26 at 00:20 +0200, Patrice Dumas wrote: > On Sat, Oct 25, 2008 at 09:31:34PM +0200, Ralf Corsepius wrote: > > On Sat, 2008-10-25 at 15:47 +0200, Patrice Dumas wrote: > > > Hello, > > > > > > In > > > http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description > > > > > > I suggest changing README.Fedora to README.Dist, see for an > > > argumentation: > > > http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_using_fedora_or_redhat > > -1 > > > > Leave such implementation details to the packager's discretion. > > It is only a (controversial) recommendation and I never wanted to make > it a guideline. But in most of the case the file is not fedora specific, In many cases such READMEs are not distro-specific, either. > it is p?ckage specific so I think it should be reflected in the name. Well, I find README.Dist or README.rpm to be more confusing than helpful. I prefer README.fedora, README.Fedora or README.first. Ralf From rc040203 at freenet.de Sun Oct 26 04:12:12 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 26 Oct 2008 05:12:12 +0100 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025224105.GG2685@free.fr> References: <20081025134755.GF2608@free.fr> <20081025140722.GA3363@mokona.greysector.net> <20081025223820.GD6333@mokona.greysector.net> <20081025224105.GG2685@free.fr> Message-ID: <1224994333.6682.115.camel@beck.corsepiu.local> On Sun, 2008-10-26 at 00:41 +0200, Patrice Dumas wrote: > On Sun, Oct 26, 2008 at 12:38:21AM +0200, Dominik 'Rathann' Mierzejewski wrote: > > > > I have one now: README.package. > > Agreed, I also think that it is the best one. I have updated > https://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_using_fedora_or_redhat_.28controversial.29 > > (and I have explicitely stated that it is controversial). I don't think it's controversial. You (or whoever wrote this) made it controversial. Do you really think. users finding a README.Fedora are not able to bring such a README into the appropriate context e.g. on EPEL or on RHEL? Pedantic packagers could rename such a file (as part of their rpm.specs) for EPEL or when adopting a package into RHEL. I for one, don't see much reason to do so. Ralf From nicolas.mailhot at laposte.net Sun Oct 26 08:57:40 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 26 Oct 2008 09:57:40 +0100 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <1224993965.6682.108.camel@beck.corsepiu.local> References: <20081025134755.GF2608@free.fr> <1224963094.6682.80.camel@beck.corsepiu.local> <20081025222039.GC2685@free.fr> <1224993965.6682.108.camel@beck.corsepiu.local> Message-ID: <1225011460.28118.1.camel@arekh.okg> Le dimanche 26 octobre 2008 ? 05:06 +0100, Ralf Corsepius a ?crit : > > it is p?ckage specific so I think it should be reflected in the name. > Well, I find README.Dist or README.rpm to be more confusing than > helpful. > > I prefer README.fedora, README.Fedora or README.first. In the interest of helping users that just want to double-click on the thing to read it, I prefer whatever.txt. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pertusus at free.fr Sun Oct 26 12:17:00 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 26 Oct 2008 13:17:00 +0100 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025134755.GF2608@free.fr> References: <20081025134755.GF2608@free.fr> Message-ID: <20081026121700.GA2785@free.fr> On Sat, Oct 25, 2008 at 03:47:55PM +0200, Patrice Dumas wrote: > Hello, > > In > http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description > > I suggest changing README.Fedora to README.Dist, see for an > argumentation: > http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_using_fedora_or_redhat Let's forget about that idea, I thought it was less controversial than it turned out to be. -- Pat From tibbs at math.uh.edu Sun Oct 26 15:12:06 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Oct 2008 10:12:06 -0500 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025222405.GD2685@free.fr> References: <20081025134755.GF2608@free.fr> <20081025222405.GD2685@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> Are these files really fedora specific, or package specific? In the case of my packages, or packages where I have recommended the use of README.Fedora, they indicate specific information on how Fedora has provided default configurations and any Fedora-specific setup necessary (such as indicating that a web application has installed an apache config file restricting access to localhost until default passwords are changed). PD> In most cases they are package specific, so I think the file name PD> should reflect that, and also it helps others (or EPEL) reuse spec PD> files. EPEL is a Fedora product, is it not? If someone wants to lift a Fedora package and has concerns about such files appearing in it, they are welcome to rename them. That's not my business, though. If someone wants to propose a standard macro which expands to "Fedora", "EPEL" or whatever a hypothetical Fedora-consuming distro might wish, then I would happily use it. - J< From pertusus at free.fr Sun Oct 26 15:23:27 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 26 Oct 2008 16:23:27 +0100 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: References: <20081025134755.GF2608@free.fr> <20081025222405.GD2685@free.fr> Message-ID: <20081026152327.GB9567@free.fr> On Sun, Oct 26, 2008 at 10:12:06AM -0500, Jason L Tibbitts III wrote: > >>>>> "PD" == Patrice Dumas writes: > > PD> Are these files really fedora specific, or package specific? > > In the case of my packages, or packages where I have recommended the > use of README.Fedora, they indicate specific information on how Fedora > has provided default configurations and any Fedora-specific setup > necessary (such as indicating that a web application has installed an > apache config file restricting access to localhost until default > passwords are changed). But is it fedora specific, or specific to the setup of the package? In most case it is linked with how the package is done, but not to fedora, otherwise said doesn't use any of the fedora specificities. Your example doesn't seems to use anything fedora specific. -- Pat From tibbs at math.uh.edu Sun Oct 26 15:43:28 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Oct 2008 10:43:28 -0500 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081026152327.GB9567@free.fr> References: <20081025134755.GF2608@free.fr> <20081025222405.GD2685@free.fr> <20081026152327.GB9567@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> But is it fedora specific, or specific to the setup of the PD> package? Now you're just being obtuse. I wrote the package _for_ Fedora. It's a Fedora package. The information is specific to the default configuration of the package in Fedora. The apache configuration file in my example doesn't come from upstream; it is part of the Fedora package. README.Fedora is an entirely appropriate name for a file explaining that. - J< From pertusus at free.fr Sun Oct 26 16:44:18 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 26 Oct 2008 17:44:18 +0100 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: References: <20081025134755.GF2608@free.fr> <20081025222405.GD2685@free.fr> <20081026152327.GB9567@free.fr> Message-ID: <20081026164418.GA2651@free.fr> On Sun, Oct 26, 2008 at 10:43:28AM -0500, Jason L Tibbitts III wrote: > >>>>> "PD" == Patrice Dumas writes: > > PD> But is it fedora specific, or specific to the setup of the > PD> package? > > Now you're just being obtuse. I wrote the package _for_ Fedora. It's That's exactly my point. It is written for fedora, but is not specific of fedora. That's why I think it is better to avoid using fedora, but instead use a word, both more neutral and more appropriate, like package. > a Fedora package. The information is specific to the default > configuration of the package in Fedora. The apache configuration file > in my example doesn't come from upstream; it is part of the Fedora > package. README.Fedora is an entirely appropriate name for a file > explaining that. It is appropriate, but README.package seems more appropriate to me, since it is part of the package and it allows to reuse it in other contexts without having to rename anything (reuse in EPEL, in 3rd party repo, for local builds and local repository or 'private' repositories accessible on the web...). -- Pat From fedora at leemhuis.info Sun Oct 26 17:25:20 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Oct 2008 18:25:20 +0100 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081026164418.GA2651@free.fr> References: <20081025134755.GF2608@free.fr> <20081025222405.GD2685@free.fr> <20081026152327.GB9567@free.fr> <20081026164418.GA2651@free.fr> Message-ID: <4904A800.8010404@leemhuis.info> On 26.10.2008 17:44, Patrice Dumas wrote: > On Sun, Oct 26, 2008 at 10:43:28AM -0500, Jason L Tibbitts III wrote: >>>>>>> "PD" == Patrice Dumas writes: >> PD> But is it fedora specific, or specific to the setup of the >> PD> package? >> Now you're just being obtuse. I wrote the package _for_ Fedora. It's > That's exactly my point. It is written for fedora, but is not specific > of fedora. That's why I think it is better to avoid using fedora, but > instead use a word, both more neutral and more appropriate, like > package. +1 -- especially with the remixes on the horizon it will get confusing if you have "README.Fedora" on a dist called "Foobar" (which is a remix of Fedora; but the user might not know that) >> a Fedora package. The information is specific to the default >> configuration of the package in Fedora. The apache configuration file >> in my example doesn't come from upstream; it is part of the Fedora >> package. README.Fedora is an entirely appropriate name for a file >> explaining that. > It is appropriate, but README.package seems more appropriate to me, > since it is part of the package and it allows to reuse it in other > contexts without having to rename anything (reuse in EPEL, in 3rd party > repo, for local builds and local repository or 'private' repositories > accessible on the web...). +1 And Patrice, thanks again for your work driving this issue forward; I really appreciate it as I really think it makes a whole lot of sense to have a common name scheme. There are often compromises that need to be made during packaging that are ideally explained somewhere (like for example dropping support for mp3); if we use a common name scheme for files that explain these issues then we can just add something like "some package contain additional notes for Fedora specific qualities; those are explained in a file README.package that is shipped together with the docs of each package". Well, not exactly that text, but something like that -- you'll get the idea ;-) Cu knurd From pertusus at free.fr Sun Oct 26 21:49:45 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 26 Oct 2008 22:49:45 +0100 Subject: [Fedora-packaging] README.Dist is preferrable to README.Fedora In-Reply-To: <20081025134755.GF2608@free.fr> References: <20081025134755.GF2608@free.fr> Message-ID: <20081026214945.GA2601@free.fr> On Sat, Oct 25, 2008 at 03:47:55PM +0200, Patrice Dumas wrote: > Hello, I have read some (about 30) of the 93 files in fedora packages named *README*edora*. Some can be considered fedora specific (for example those that states that the documentation cannot be installed since it would conflict with another package), but many are not fedora specific, but mostly explaination of how the package is different from upstream or post-install informations. In some cases, the bugzilla address or the maintainer address is included in an otherwise not fedora specific package. I think that it is wrong, bugzilla and maintainer name should not be communicated in each package, but globally. -- Pat From mtasaka at ioa.s.u-tokyo.ac.jp Fri Oct 31 17:57:11 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 01 Nov 2008 02:57:11 +0900 Subject: [Fedora-packaging] rubygem with extension written in C Message-ID: <490B46F7.3070906@ioa.s.u-tokyo.ac.jp> Hello, all: During reviews (and also on my package) I met with some troubles when packaging Ruby Gems containing extension libraries written in C. Would you look at my proposition written in the following URL? https://fedoraproject.org/wiki/User:Mtasaka/PackagingDrafts/RubyGem_with_C_code Any comments will be appreciated. Thank you in advance. Note: I will leave from my computer soon and I will read and reply to comments once I get back from a rest. Regards, Mamoru