From nicolas.mailhot at laposte.net Mon Sep 1 07:24:08 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 01 Sep 2008 09:24:08 +0200 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B77AF9.7010008@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B77AF9.7010008@redhat.com> Message-ID: <1220253848.2047.6.camel@rousalka.okg> Le vendredi 29 ao?t 2008 ? 14:28 +1000, Jens Petersen a ?crit : > >> But how are packages supposed to get these macros? > >> Surely each package is not going to include all of > >> http://ynemoy.fedorapeople.org/haskell/macros.ghc ? > > > > That file is going to be packaged with ghc itself. I've submitted the > > following bug. > > https://bugzilla.redhat.com/show_bug.cgi?id=460304 > > Do any other packages (languages) in Fedora provide rpm macros? Java packages have been build for years on multiple distributions and distribution releases using the jpackage-utils rpm which is basically a set of rpm macros, default directories and utility scripts. The only problem it caused is when a distribution added a distro-specific script and didn't push it bach upstream. Before this package was introduced maintaining consistency within a large set of packages that all defined manually the same paths and scripts (in a slightly different way) was hell. It also makes it way easier to rebuild on distro releases with different rpm versions. If you merge your macros in rpm itself (not that it was possible until the rpm project was resurected) any macro change or addition will hit the huge inertia of rpm itself. -- 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 cra at WPI.EDU Thu Sep 4 21:06:26 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 4 Sep 2008 17:06:26 -0400 Subject: [Fedora-packaging] combining code from GPLv2 and Artistic (Perl) Message-ID: <20080904210626.GS19277@angus.ind.WPI.EDU> I'm working on packaging perl-RT-Client-REST, a Perl module from CPAN. It claims to be under the Perl license (GPL+ or Artistic) except for one class, RT::Client::REST, which it claims is under the GPL since the author copied those bits from RT, which is in fact under GPLv2 according to the web site: http://code.bestpractical.com/project/RT (Request Tracker) Should the License tag be: License: (GPL+ or Artistic) and GPLv2 or just: License: GPLv2 or perhaps: License: GPLv2 or Artistic ? The README says: ... Author: Dmitri Tikhonov RT::Client::REST is based on 'rt' command-line utility distributed with RT 3.x written by Abhijit Menon-Sen and donated to RT project. License: Original 'rt' utility is GPL, therefore so is RT::Client::REST. The rest of the modules are licensed under the usual artistic license. (I am not sure it makes sense to do this. Does GPL override artistic license? Someone let me know if you have a definite answer.) The source code mentions that RT::Client::REST is under GPL: ./lib/RT/Client/REST.pm:=head1 LICENSE ./lib/RT/Client/REST.pm:Since original rt is licensed under GPL, so is this module. ./lib/RT/Client/REST/Queue.pm:=head1 LICENSE ./lib/RT/Client/REST/Queue.pm:Perl license with the exception of L, which is GPLed. ./lib/RT/Client/REST/Attachment.pm:=head1 LICENSE ./lib/RT/Client/REST/Attachment.pm:Perl license with the exception of L, which is GPLed. ./lib/RT/Client/REST/Transaction.pm:=head1 LICENSE ./lib/RT/Client/REST/Transaction.pm:Perl license with the exception of L, which is GPLed. ./lib/RT/Client/REST/User.pm:=head1 LICENSE ./lib/RT/Client/REST/User.pm:Perl license with the exception of L, which is GPLed. ./lib/RT/Client/REST/Ticket.pm:=head1 LICENSE ./lib/RT/Client/REST/Ticket.pm:Perl license with the exception of L, which is GPLed. AFAICT these are where the RT::Client::REST class and derived classes are defined: ./lib/RT/Client/REST.pm:package RT::Client::REST; ./lib/RT/Client/REST/Queue.pm:package RT::Client::REST::Queue; ./lib/RT/Client/REST/HTTPClient.pm:package RT::Client::REST::HTTPClient; ./lib/RT/Client/REST/Forms.pm:package RT::Client::REST::Forms; ./lib/RT/Client/REST/SearchResult.pm:package RT::Client::REST::SearchResult; ./lib/RT/Client/REST/Object.pm:package RT::Client::REST::Object; ./lib/RT/Client/REST/Object.pm: package RT::Client::REST::MyType; ./lib/RT/Client/REST/Attachment.pm:package RT::Client::REST::Attachment; ./lib/RT/Client/REST/Transaction.pm:package RT::Client::REST::Transaction; ./lib/RT/Client/REST/User.pm:package RT::Client::REST::User; ./lib/RT/Client/REST/Ticket.pm:package RT::Client::REST::Ticket; ./lib/RT/Client/REST/Exception.pm:package RT::Client::REST::Exception; ./lib/RT/Client/REST/Object/Exception.pm:package RT::Client::REST::Object::Exception; Thanks. From tcallawa at redhat.com Thu Sep 4 21:32:40 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 04 Sep 2008 17:32:40 -0400 Subject: [Fedora-packaging] combining code from GPLv2 and Artistic (Perl) In-Reply-To: <20080904210626.GS19277@angus.ind.WPI.EDU> References: <20080904210626.GS19277@angus.ind.WPI.EDU> Message-ID: <1220563960.3730.88.camel@localhost.localdomain> On Thu, 2008-09-04 at 17:06 -0400, Chuck Anderson wrote: > I'm working on packaging perl-RT-Client-REST, a Perl module from CPAN. > It claims to be under the Perl license (GPL+ or Artistic) except for > one class, RT::Client::REST, which it claims is under the GPL since > the author copied those bits from RT, which is in fact under GPLv2 > according to the web site: http://code.bestpractical.com/project/RT (Request Tracker) > > Should the License tag be: > > License: (GPL+ or Artistic) and GPLv2 > > or just: > > License: GPLv2 IANAL, but I suspect that the combined work would be considered GPLv2, since Artistic 1.0 is non-free (and thus, GPL incompatible). ~spot From lists at timj.co.uk Sat Sep 6 17:24:07 2008 From: lists at timj.co.uk (Tim Jackson) Date: Sat, 06 Sep 2008 18:24:07 +0100 Subject: [Fedora-packaging] Group tag in spec files Message-ID: <48C2BCB7.9030103@timj.co.uk> Just a thought: perhaps the Packaging Guidelines should have a comment about formulating the "Group" tag in spec files? If nothing else they could tell you to go and read /usr/share/doc/rpm-*/GROUPS, but a bit of advice would probably be welcome there, especially for new contributors. Currently it only has one passing reference to the Group tag (in relation to documentation-only packages). Thanks Tim From tcallawa at redhat.com Sat Sep 6 18:03:25 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 06 Sep 2008 14:03:25 -0400 Subject: [Fedora-packaging] Group tag in spec files In-Reply-To: <48C2BCB7.9030103@timj.co.uk> References: <48C2BCB7.9030103@timj.co.uk> Message-ID: <1220724205.16460.1.camel@localhost.localdomain> On Sat, 2008-09-06 at 18:24 +0100, Tim Jackson wrote: > Just a thought: perhaps the Packaging Guidelines should have a comment > about formulating the "Group" tag in spec files? If nothing else they > could tell you to go and read /usr/share/doc/rpm-*/GROUPS, but a bit of > advice would probably be welcome there, especially for new contributors. Hmm, I know that we decided that we were not concerned with what went into the Group tag, but I don't see this reflected in the guidelines anywhere. ~spot From a.badger at gmail.com Sat Sep 6 18:11:13 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 06 Sep 2008 11:11:13 -0700 Subject: [Fedora-packaging] Group tag in spec files In-Reply-To: <48C2BCB7.9030103@timj.co.uk> References: <48C2BCB7.9030103@timj.co.uk> Message-ID: <48C2C7C1.2070605@gmail.com> Tim Jackson wrote: > Just a thought: perhaps the Packaging Guidelines should have a comment > about formulating the "Group" tag in spec files? If nothing else they > could tell you to go and read /usr/share/doc/rpm-*/GROUPS, but a bit of > advice would probably be welcome there, especially for new contributors. > > Currently it only has one passing reference to the Group tag (in > relation to documentation-only packages). > We actually have discussed the Group tag at length in the Packaging Committee. Previously there was a Guideline that said the group tag had to be from /usr/share/doc/rpm-*/GROUPS. Eventually it was decided to drop the tag since it makes more sense to keep group information separate from the rpm. Hence comps is where group information is decided and the group tag is not something we worry about. -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 Axel.Thimm at ATrpms.net Sun Sep 7 02:28:14 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 7 Sep 2008 05:28:14 +0300 Subject: [Fedora-packaging] Re: Group tag in spec files In-Reply-To: <1220724205.16460.1.camel@localhost.localdomain> References: <48C2BCB7.9030103@timj.co.uk> <1220724205.16460.1.camel@localhost.localdomain> Message-ID: <20080907022814.GA5377@victor.nirvana> On Sat, Sep 06, 2008 at 02:03:25PM -0400, Tom spot Callaway wrote: > On Sat, 2008-09-06 at 18:24 +0100, Tim Jackson wrote: > > Just a thought: perhaps the Packaging Guidelines should have a comment > > about formulating the "Group" tag in spec files? If nothing else they > > could tell you to go and read /usr/share/doc/rpm-*/GROUPS, but a bit of > > advice would probably be welcome there, especially for new contributors. > > Hmm, I know that we decided that we were not concerned with what went > into the Group tag, but I don't see this reflected in the guidelines > anywhere. We decided to ignore Grup tag --- literally :) How about just calling Group tag deprecated and to mention that upcoming rpm (>=F10) won't even require one. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ville.skytta at iki.fi Sun Sep 7 16:45:39 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 7 Sep 2008 19:45:39 +0300 Subject: [Fedora-packaging] Re: Group tag in spec files In-Reply-To: <20080907022814.GA5377@victor.nirvana> References: <48C2BCB7.9030103@timj.co.uk> <1220724205.16460.1.camel@localhost.localdomain> <20080907022814.GA5377@victor.nirvana> Message-ID: <200809071945.39547.ville.skytta@iki.fi> On Sunday 07 September 2008, Axel Thimm wrote: > On Sat, Sep 06, 2008 at 02:03:25PM -0400, Tom spot Callaway wrote: > > On Sat, 2008-09-06 at 18:24 +0100, Tim Jackson wrote: > > > Just a thought: perhaps the Packaging Guidelines should have a comment > > > about formulating the "Group" tag in spec files? If nothing else they > > > could tell you to go and read /usr/share/doc/rpm-*/GROUPS, but a bit of > > > advice would probably be welcome there, especially for new > > > contributors. > > > > Hmm, I know that we decided that we were not concerned with what went > > into the Group tag, but I don't see this reflected in the guidelines > > anywhere. > > We decided to ignore Grup tag --- literally :) > > How about just calling Group tag deprecated and to mention that > upcoming rpm (>=F10) won't even require one. My .02?: Even though it would be (is?) deprecated, it's not quite dead yet: it's still mandatory in specfiles in current GA distro versions, it's still displayed by "rpm -qi", prominently there in repoview and most likely there's a bunch of other apps that use it for more or less important features to them (e.g. the last time I checked: synaptic), and it is required by LSB. And it'll take a long long time until making it optional in F-10 will trickle down to other actively supported distro versions (think EL). So IMHO it would be good to have *some* guidelines for its usage that encourage consistency. I don't personally care exactly what that consistency means, be it a list of "valid" values or simply "Unspecified" as the only allowed value. rpmlint currently looks at /usr/share/doc/rpm-*/GROUPS and whines if the Group is not listed in it, some more info and thoughts at https://bugzilla.redhat.com/458460 From ville.skytta at iki.fi Sun Sep 7 21:04:29 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 8 Sep 2008 00:04:29 +0300 Subject: [Fedora-packaging] Using newish rpm features in Fedora buildsys Message-ID: <200809080004.30174.ville.skytta@iki.fi> Hi, I ran into a "make srpm" issue in the buildsys (again, seen them before every now and then) because I was using a feature in the specfile that is not supported by the version of rpmbuild that gets run with "make srpm" there. https://fedorahosted.org/fedora-infrastructure/ticket/817 I suppose there are a lot of contributors that are not aware of this, so it (along with some details exactly what to expect to (not?) work, maybe from someone from the infrastructure team who knows the details) could be a worthy addition to somewhere in the package maintainers documentation section in Wiki. Main packaging guidelines? From Axel.Thimm at ATrpms.net Sun Sep 7 21:31:12 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 8 Sep 2008 00:31:12 +0300 Subject: [Fedora-packaging] Re: Group tag in spec files In-Reply-To: <200809071945.39547.ville.skytta@iki.fi> References: <48C2BCB7.9030103@timj.co.uk> <1220724205.16460.1.camel@localhost.localdomain> <20080907022814.GA5377@victor.nirvana> <200809071945.39547.ville.skytta@iki.fi> Message-ID: <20080907213112.GA25734@victor.nirvana> On Sun, Sep 07, 2008 at 07:45:39PM +0300, Ville Skytt? wrote: > On Sunday 07 September 2008, Axel Thimm wrote: > > On Sat, Sep 06, 2008 at 02:03:25PM -0400, Tom spot Callaway wrote: > > > On Sat, 2008-09-06 at 18:24 +0100, Tim Jackson wrote: > > > > Just a thought: perhaps the Packaging Guidelines should have a comment > > > > about formulating the "Group" tag in spec files? If nothing else they > > > > could tell you to go and read /usr/share/doc/rpm-*/GROUPS, but a bit of > > > > advice would probably be welcome there, especially for new > > > > contributors. > > > > > > Hmm, I know that we decided that we were not concerned with what went > > > into the Group tag, but I don't see this reflected in the guidelines > > > anywhere. > > > > We decided to ignore Grup tag --- literally :) > > > > How about just calling Group tag deprecated and to mention that > > upcoming rpm (>=F10) won't even require one. > > My .02?: > > Even though it would be (is?) deprecated, it's not quite dead yet: it's still > mandatory in specfiles in current GA distro versions, it's still displayed > by "rpm -qi", prominently there in repoview and most likely there's a bunch > of other apps that use it for more or less important features to them (e.g. > the last time I checked: synaptic), and it is required by LSB. And it'll > take a long long time until making it optional in F-10 will trickle down to > other actively supported distro versions (think EL). > > So IMHO it would be good to have *some* guidelines for its usage that > encourage consistency. I don't personally care exactly what that consistency > means, be it a list of "valid" values or simply "Unspecified" as the only > allowed value. rpmlint currently looks at /usr/share/doc/rpm-*/GROUPS and > whines if the Group is not listed in it, some more info and thoughts at > https://bugzilla.redhat.com/458460 We certainly can't afford to lose LSB compliance (I didn't knew Groups: was referenced there), so indeed we need to step down a bit. Most probably we can now just make people aware that we consider the tag non-authoritative and while making best efforts to have its content sane we advise using other sources of information like the rpm metadata/comps stuff. And about adding new tags/modifying old ones: I think we should not. We should keep the current copy of GROUPS and try to fit the tags in there to nearest proximity. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ville.skytta at iki.fi Mon Sep 8 06:03:40 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 8 Sep 2008 09:03:40 +0300 Subject: [Fedora-packaging] Re: Group tag in spec files In-Reply-To: <20080907213112.GA25734@victor.nirvana> References: <48C2BCB7.9030103@timj.co.uk> <200809071945.39547.ville.skytta@iki.fi> <20080907213112.GA25734@victor.nirvana> Message-ID: <200809080903.41290.ville.skytta@iki.fi> On Monday 08 September 2008, Axel Thimm wrote: > We certainly can't afford to lose LSB compliance (I didn't knew > Groups: was referenced there), so indeed we need to step down a > bit. Regarding the LSB, I don't know whether the format of packages produced by rpm in current Fedora releases is LSB compliant even without any Group tag changes. If it is, I suppose making Group optional in specfiles does not necessarily mean losing LSB compliance, rpmbuild could just insert some fixed string as its value in the package headers it produces if the tag is not present in a specfile. From fedora at leemhuis.info Sun Sep 14 08:36:39 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 14 Sep 2008 10:36:39 +0200 Subject: [Fedora-packaging] Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8) In-Reply-To: <20080914065131.80F65208DA4@bastion.fedora.phx.redhat.com> References: <20080914065131.80F65208DA4@bastion.fedora.phx.redhat.com> Message-ID: <48CCCD17.1090001@leemhuis.info> Hi all! just noticed this: On 14.09.2008 08:51, updates at fedoraproject.org wrote: > -------------------------------------------------------------------------------- > Fedora Update Notification > FEDORA-2008-8052 > 2008-09-13 04:56:07 > -------------------------------------------------------------------------------- > > Name : enlightenment > Product : Fedora 8 > Version : 0.16.999.043 > Release : 3.fc8 > URL : http://enlightenment.org/p.php?p=about/e17&l=en > Summary : Enlightenment DR17 - a next generation desktop shell > Description : > Enlightenment 0.17 is the next generation of UNIX graphical environments. It is > not just a window manager, but it is also a desktop shell. A desktop shell > means, a window manager plus a file manager, plus configuration utilitys all in > one. They are not separated as usual. > > Enlightenment is fast. No, really. It's fast. It is known to run on very slow > machines (like 100 Mhz CPU, 64 MB of RAM) well. So you really don't need a > modern desktop to see some eye-candy and to use a modern graphical environment. > Even more ? you can control how fast you want it by using it's Performance > configuration panel to change the cache settings and more. > > The high performance does not mean that there is no eye candy. There is eye > candy that you have never seen before. Starting from the animated boot screen, > to continue with the all animations and effects that themes could provide, to > end up with fancy animated backgrounds. But not some huge .GIF files, but > really nice animations. Every virtual desktop (at the moment you can have 24) > can have it's own background (animated or not), so you can put different > wallpapers on the different virtual desktops. There are a number of effects > that can be shown when you switch from the different virtual desktops. The > menus, the borders and all other usual parts of a normal window manager are > animated as well as some of the widgets (the sliders, for example). Remember > that those effects are provided by the theme, so every theme makes E to look > different, with different effects, look and feel and animations. > > As we already mentioned, E17 provides a file manager as well. Of the time of > writing, it is not completed and is in active development (as E17 as a whole > itself), but after it is finished it will be a very nice, configurable and eye > candy. Even right now, you can do the basic things with it ? browse, copy, > move, delete files. It will provide thumbnails for your pictures and will be > able to open your files with the coresponding application of your choice. > > E17 is highly configurable. Currently it has a nice configuration panel with > dialogs for all kinds of things. You can change your wallpaper or your theme, > your fonts, your screen resolution, your screen's power settings, your keyboard > and mouse settings, the language that Enlightenment talks to you, and so on. > You can contol almost every apsect of what E is doing and how. It will do what > you want it to do. > > As you already know, Enlightenment 0.17 has lots of features, but one of the > most important is, that you can add and remove functionality by using modules. > Modules are small applications that extend E17. There can be modules tho show > you the weather outside, or calendar modules, or modules to control your volume > or whatever you may think. Developing a module is not that hard, so, if you > have programming skills, you are more than welcome to develop and maintain some > modules for the community. Wow, that's a really long description. (1) Is that really needed? Do we want that? I tend to say "no" -- a description with maybe 10, 15 or 20 lines with 80 chars per line should be enough, as everything else often takes way to much time to read for the user and thus it in the end might be more confusing and time-wasting than helpful. (2) Quoting some things from above description again: > Enlightenment 0.17 is the next generation of UNIX graphical environments. [...] > Enlightenment is fast. No, really. It's fast.[...] > [...]after it is finished it will be a very nice, configurable and eye > candy.[...] Yes, I know, enlightenment is designed for small machines and quite fast on them. But those things I quoted and other sections in the description sound more like advertising than a proper description. Up to a specific point that's okay IMHO, but here the packager IMHO shoot way over the top. Note: both things are not that important. But I found them odd and thought it might be a good idea to might bring them up here. CU knurd P.S.: Review bug for enlightenment: https://bugzilla.redhat.com/show_bug.cgi?id=448337 P.P.S.: Nice to finally see Enlightenment in Fedora :-) From tcallawa at redhat.com Sun Sep 14 13:35:06 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 14 Sep 2008 09:35:06 -0400 Subject: [Fedora-packaging] Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8) In-Reply-To: <48CCCD17.1090001@leemhuis.info> References: <20080914065131.80F65208DA4@bastion.fedora.phx.redhat.com> <48CCCD17.1090001@leemhuis.info> Message-ID: <1221399306.9991.23.camel@localhost.localdomain> On Sun, 2008-09-14 at 10:36 +0200, Thorsten Leemhuis wrote: > Yes, I know, enlightenment is designed for small machines and quite > fast > on them. But those things I quoted and other sections in the > description > sound more like advertising than a proper description. Up to a > specific > point that's okay IMHO, but here the packager IMHO shoot way over the > top. Wow. That is indeed too much information. :) I'm not sure how we should "guideline" that, other than something like: == Descriptions == Your package description should contain useful data about the package, and answer the question "what is this and what does it do?". In general, the description should not exceed 10 lines or so. Try not to put too much here, this isn't an epic novel, it's just a package description. Also, there is no real need to "advertise" the package here, so statements like "this is the best perl module that has ever been created by humans", while possibly accurate, are not terribly useful in answering the question "what is this and what does it do?". OT: Would an Enlightenment spin of Fedora be called "Eedora"? What about an eepc Enlightenment spin? Eeeedora? ;) ~spot From dominik at greysector.net Sun Sep 14 13:47:07 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 14 Sep 2008 15:47:07 +0200 Subject: [Fedora-packaging] Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8) In-Reply-To: <1221399306.9991.23.camel@localhost.localdomain> References: <20080914065131.80F65208DA4@bastion.fedora.phx.redhat.com> <48CCCD17.1090001@leemhuis.info> <1221399306.9991.23.camel@localhost.localdomain> Message-ID: <20080914134707.GH9241@mokona.greysector.net> On Sunday, 14 September 2008 at 15:35, Tom spot Callaway wrote: > On Sun, 2008-09-14 at 10:36 +0200, Thorsten Leemhuis wrote: > > Yes, I know, enlightenment is designed for small machines and quite > > fast > > on them. But those things I quoted and other sections in the > > description > > sound more like advertising than a proper description. Up to a > > specific > > point that's okay IMHO, but here the packager IMHO shoot way over the > > top. > > Wow. That is indeed too much information. :) I'm not sure how we should > "guideline" that, other than something like: > > == Descriptions == > Your package description should contain useful data about the package, > and answer the question "what is this and what does it do?". In general, > the description should not exceed 10 lines or so. Try not to put too > much here, this isn't an epic novel, it's just a package description. > Also, there is no real need to "advertise" the package here, so > statements like "this is the best perl module that has ever been created > by humans", while possibly accurate, are not terribly useful in > answering the question "what is this and what does it do?". +1 > OT: > Would an Enlightenment spin of Fedora be called "Eedora"? What about an > eepc Enlightenment spin? Eeeedora? ;) E^4dora? ;) Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From shishz at alum.rpi.edu Sun Sep 14 16:42:18 2008 From: shishz at alum.rpi.edu (zing) Date: Sun, 14 Sep 2008 16:42:18 +0000 (UTC) Subject: [Fedora-packaging] Re: Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8) References: <20080914065131.80F65208DA4@bastion.fedora.phx.redhat.com> <48CCCD17.1090001@leemhuis.info> <1221399306.9991.23.camel@localhost.localdomain> Message-ID: On Sun, 14 Sep 2008 09:35:06 -0400, Tom \"spot\" Callaway wrote: > On Sun, 2008-09-14 at 10:36 +0200, Thorsten Leemhuis wrote: >> Yes, I know, enlightenment is designed for small machines and quite >> fast >> on them. But those things I quoted and other sections in the >> description >> sound more like advertising than a proper description. Up to a specific >> point that's okay IMHO, but here the packager IMHO shoot way over the >> top. > > Wow. That is indeed too much information. :) I'm not sure how we should > "guideline" that, other than something like: > > == Descriptions == > Your package description should contain useful data about the package, > and answer the question "what is this and what does it do?". In general, > the description should not exceed 10 lines or so. Try not to put too > much here, this isn't an epic novel, it's just a package description. > Also, there is no real need to "advertise" the package here, so > statements like "this is the best perl module that has ever been created > by humans", while possibly accurate, are not terribly useful in > answering the question "what is this and what does it do?". I think these types of "advertising" and/or packager's notes are better put into /usr/share/doc/package/README.RPM or similar. Maybe just an additional sentence that packager's can stick extra additional info there. Packagers already do this. zing From fedora at leemhuis.info Mon Sep 15 11:53:55 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 15 Sep 2008 13:53:55 +0200 Subject: [Fedora-packaging] Re: Long and "advertising" descriptions In-Reply-To: <1221399306.9991.23.camel@localhost.localdomain> References: <20080914065131.80F65208DA4@bastion.fedora.phx.redhat.com> <48CCCD17.1090001@leemhuis.info> <1221399306.9991.23.camel@localhost.localdomain> Message-ID: <48CE4CD3.7020500@leemhuis.info> On 14.09.2008 15:35, Tom "spot" Callaway wrote: > On Sun, 2008-09-14 at 10:36 +0200, Thorsten Leemhuis wrote: >> Yes, I know, enlightenment is designed for small machines and quite >> fast >> on them. But those things I quoted and other sections in the >> description >> sound more like advertising than a proper description. Up to a >> specific >> point that's okay IMHO, but here the packager IMHO shoot way over the >> top. > Wow. That is indeed too much information. :) I'm not sure how we should > "guideline" that, other than something like: > > == Descriptions == > Your package description should contain useful data about the package, > and answer the question "what is this and what does it do?". In general, > the description should not exceed 10 lines or so. Try not to put too > much here, this isn't an epic novel, it's just a package description. > Also, there is no real need to "advertise" the package here, so > statements like "this is the best perl module that has ever been created > by humans", while possibly accurate, are not terribly useful in > answering the question "what is this and what does it do?". Sounds good. Not sure, but maybe it's possible to write it a bit shorter to work against the "guidelines grow and grow" trend (?). Maybe something like this is enough: """ The description should not be exceed round about ten lines of text and contain useful data about what the packaged software does. The description should be written from a distance point of view and not sound like advertising. """ I suppose a native English speaker is able to write it more clear in less words. CU knurd (?) -- heck, maybe this should not be in the guidelines at all; maybe a new "best practices" document might be a better place for this and similar things, as "description not to long, no advertising style" is obvious to round about 99 percent of our packagers... From rc040203 at freenet.de Mon Sep 15 13:18:05 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 15 Sep 2008 15:18:05 +0200 Subject: [Fedora-packaging] Re: Long and "advertising" descriptions In-Reply-To: <48CE4CD3.7020500@leemhuis.info> References: <20080914065131.80F65208DA4@bastion.fedora.phx.redhat.com> <48CCCD17.1090001@leemhuis.info> <1221399306.9991.23.camel@localhost.localdomain> <48CE4CD3.7020500@leemhuis.info> Message-ID: <1221484685.18327.592.camel@beck.corsepiu.local> On Mon, 2008-09-15 at 13:53 +0200, Thorsten Leemhuis wrote: > On 14.09.2008 15:35, Tom "spot" Callaway wrote: > > On Sun, 2008-09-14 at 10:36 +0200, Thorsten Leemhuis wrote: > >> Yes, I know, enlightenment is designed for small machines and quite > >> fast > >> on them. But those things I quoted and other sections in the > >> description > >> sound more like advertising than a proper description. Up to a > >> specific > >> point that's okay IMHO, but here the packager IMHO shoot way over the > >> top. > > Wow. That is indeed too much information. :) I'm not sure how we should > > "guideline" that, other than something like: > > > > == Descriptions == > > Your package description should contain useful data about the package, > > and answer the question "what is this and what does it do?". In general, > > the description should not exceed 10 lines or so. Try not to put too > > much here, this isn't an epic novel, it's just a package description. > > Also, there is no real need to "advertise" the package here, so > > statements like "this is the best perl module that has ever been created > > by humans", while possibly accurate, are not terribly useful in > > answering the question "what is this and what does it do?". +1 > Sounds good. Not sure, but maybe it's possible to write it a bit shorter Agreed. Shorter would be better. Futhermore, I'd like to see some words added aiming at use of non-self-explanatory acronyms/names and redundant wording. I am getting the creeps when reading descriptions similar to "Hawaii, the Moscow-daemon for Tokio, a free open-source implemention of PROZL/RKNR for GNIZL implemented by Dr. J.Doe at IRTX in Nutbush-City/TX." Everything in Fedora is supposed to be "open source" ... who implemented it and where is non-interesting ... Hawaii, Moscow, Tokio etc. don't tell much to anybody, who aren't already familiar with any of these. Ralf From dwheeler at dwheeler.com Mon Sep 15 14:39:34 2008 From: dwheeler at dwheeler.com (David A. Wheeler) Date: Mon, 15 Sep 2008 10:39:34 -0400 (EDT) Subject: [Fedora-packaging] Re: Long and "advertising" descriptions In-Reply-To: <20080914160028.232D9619EF8@hormel.redhat.com> References: <20080914160028.232D9619EF8@hormel.redhat.com> Message-ID: The existing description for enlightenment is clearly too long and advertizy, and saying something is the "best" is meaningless ad puff. But... if there's more than one package that does a function, I'd like _some_ way of distinguishing one from the other. E.G., does this package strive to fast? small? featureful? interoperate with everything in the known universe? A sentence or two about a package can help people avoid a lot of work to evaluate a package that really isn't appropriate to their purpose. So to this: > > == Descriptions == > > Your package description should contain useful data about the package, > > and answer the question "what is this and what does it do?". In general, > > the description should not exceed 10 lines or so. Try not to put too > > much here, this isn't an epic novel, it's just a package description. > > Also, there is no real need to "advertise" the package here, so > > statements like "this is the best perl module that has ever been created > > by humans", while possibly accurate, are not terribly useful in > > answering the question "what is this and what does it do?". I propose adding something like this: If the package has a particular advantage over similar packages, state that factually, clearly, and briefly, to help users decide if this package is right for them. Possible advantages include good performance, smallness, quantity of features, unique functions, configurability, and interoperability. Avoid meaningless terms like "very" or "best". The description should not look like an advertisement. --- David A. Wheeler From pertusus at free.fr Mon Sep 15 15:00:47 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 15 Sep 2008 17:00:47 +0200 Subject: [Fedora-packaging] Re: Long and "advertising" descriptions In-Reply-To: <48CE4CD3.7020500@leemhuis.info> References: <20080914065131.80F65208DA4@bastion.fedora.phx.redhat.com> <48CCCD17.1090001@leemhuis.info> <1221399306.9991.23.camel@localhost.localdomain> <48CE4CD3.7020500@leemhuis.info> Message-ID: <20080915150047.GC2849@free.fr> On Mon, Sep 15, 2008 at 01:53:55PM +0200, Thorsten Leemhuis wrote: > > Sounds good. Not sure, but maybe it's possible to write it a bit shorter > to work against the "guidelines grow and grow" trend (?). Maybe > something like this is enough: > > """ > The description should not be exceed round about ten lines of text and > contain useful data about what the packaged software does. The > description should be written from a distance point of view and not > sound like advertising. > """ I don't think advertising should be mentionned, nor removing the authors, in my opinion this should be left to the packager (and the reviewer). This allows to have a description that fits with what upstream would have wanted for the package description which is, in my opinion, a desirable option to leave, even though it means having some kind of advirtising. So in my opinion it should only be """ The description should not be exceed round about ten lines of text and contain useful data about what the packaged software does """ This should rule out the obscure acronyms, since they are need to be explained to have 'useful data about what the packaged software does', but leave to the packager room for optional items like advertisement and author names. -- Pat From rc040203 at freenet.de Mon Sep 15 16:33:47 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 15 Sep 2008 18:33:47 +0200 Subject: [Fedora-packaging] Re: Long and "advertising" descriptions In-Reply-To: <20080915150047.GC2849@free.fr> References: <20080914065131.80F65208DA4@bastion.fedora.phx.redhat.com> <48CCCD17.1090001@leemhuis.info> <1221399306.9991.23.camel@localhost.localdomain> <48CE4CD3.7020500@leemhuis.info> <20080915150047.GC2849@free.fr> Message-ID: <1221496427.18327.655.camel@beck.corsepiu.local> On Mon, 2008-09-15 at 17:00 +0200, Patrice Dumas wrote: > On Mon, Sep 15, 2008 at 01:53:55PM +0200, Thorsten Leemhuis wrote: > > > > Sounds good. Not sure, but maybe it's possible to write it a bit shorter > > to work against the "guidelines grow and grow" trend (?). Maybe > > something like this is enough: > > > > """ > > The description should not be exceed round about ten lines of text and > > contain useful data about what the packaged software does. The > > description should be written from a distance point of view and not > > sound like advertising. > > """ > > I don't think advertising should be mentionned, nor removing the authors, > in my opinion this should be left to the packager (and the reviewer). -1 > This allows to have a description that fits with what upstream would have > wanted for the package description which is, in my opinion, a desirable > option to leave, even though it means having some kind of advirtising. > So in my opinion it should only be > > """ > The description should not be exceed round about ten lines of text and > contain useful data about what the packaged software does > """ > > This should rule out the obscure acronyms, since they are need to be > explained to have 'useful data about what the packaged software does', > but leave to the packager room for optional items like advertisement > and author names. No. From mclasen at redhat.com Mon Sep 15 21:10:57 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 15 Sep 2008 17:10:57 -0400 Subject: [Fedora-packaging] Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8) In-Reply-To: <1221399306.9991.23.camel@localhost.localdomain> References: <20080914065131.80F65208DA4@bastion.fedora.phx.redhat.com> <48CCCD17.1090001@leemhuis.info> <1221399306.9991.23.camel@localhost.localdomain> Message-ID: <1221513057.6033.1.camel@localhost.localdomain> On Sun, 2008-09-14 at 09:35 -0400, Tom "spot" Callaway wrote: > Wow. That is indeed too much information. :) I'm not sure how we should > "guideline" that, other than something like: > > == Descriptions == > Your package description should contain useful data about the package, > and answer the question "what is this and what does it do?". In general, > the description should not exceed 10 lines or so. Try not to put too > much here, this isn't an epic novel, it's just a package description. > Also, there is no real need to "advertise" the package here, so > statements like "this is the best perl module that has ever been created > by humans", while possibly accurate, are not terribly useful in > answering the question "what is this and what does it do?". I think first and foremost, what is needed is to figure out what audience the description is targeted for. Everything else will fall in place once that is clear... From tcallawa at redhat.com Mon Sep 15 21:12:27 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 15 Sep 2008 17:12:27 -0400 Subject: [Fedora-packaging] Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8) In-Reply-To: <1221513057.6033.1.camel@localhost.localdomain> References: <20080914065131.80F65208DA4@bastion.fedora.phx.redhat.com> <48CCCD17.1090001@leemhuis.info> <1221399306.9991.23.camel@localhost.localdomain> <1221513057.6033.1.camel@localhost.localdomain> Message-ID: <1221513147.29052.114.camel@localhost.localdomain> On Mon, 2008-09-15 at 17:10 -0400, Matthias Clasen wrote: > On Sun, 2008-09-14 at 09:35 -0400, Tom "spot" Callaway wrote: > > > Wow. That is indeed too much information. :) I'm not sure how we should > > "guideline" that, other than something like: > > > > == Descriptions == > > Your package description should contain useful data about the package, > > and answer the question "what is this and what does it do?". In general, > > the description should not exceed 10 lines or so. Try not to put too > > much here, this isn't an epic novel, it's just a package description. > > Also, there is no real need to "advertise" the package here, so > > statements like "this is the best perl module that has ever been created > > by humans", while possibly accurate, are not terribly useful in > > answering the question "what is this and what does it do?". > > I think first and foremost, what is needed is to figure out what > audience the description is targeted for. Everything else will fall in > place once that is clear... I can think of a few off the top of my head: * Someone who is looking for a package that does $FOO * Someone who is trying to figure out what this package that yum just installed is for ~spot From skvidal at fedoraproject.org Mon Sep 15 21:16:12 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 15 Sep 2008 17:16:12 -0400 Subject: [Fedora-packaging] Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8) In-Reply-To: <1221513147.29052.114.camel@localhost.localdomain> References: <20080914065131.80F65208DA4@bastion.fedora.phx.redhat.com> <48CCCD17.1090001@leemhuis.info> <1221399306.9991.23.camel@localhost.localdomain> <1221513057.6033.1.camel@localhost.localdomain> <1221513147.29052.114.camel@localhost.localdomain> Message-ID: <1221513372.25056.60.camel@rosebud> On Mon, 2008-09-15 at 17:12 -0400, Tom "spot" Callaway wrote: > I can think of a few off the top of my head: > > * Someone who is looking for a package that does $FOO > * Someone who is trying to figure out what this package that yum just > installed is for > Some folks have asked about places to stick keywords they want for matching their packages in yum search. This is the only reasonable place to put them currently. -sv From paul at all-the-johnsons.co.uk Tue Sep 16 12:36:43 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 16 Sep 2008 13:36:43 +0100 Subject: [Fedora-packaging] Packaging mono - RFC Message-ID: <1221568603.26602.36.camel@PB3.Linux> Hi, Mono (and mono-packages) are currently packaged to %{_libdir} as per the published guidelines for packaging. There has been discussion, both recently and in the past, about moving mono to .noarch packages and placing them in /usr/share. The rational behind this is that .NET CIL is a non-architecture specific system which calls on a central repository of dlls held within GAC. It is a shared resource rather than a platform specific resource. It is also not a traditional library (.so). While there is no arguing that .so (and standard linux library files) should remain in %{_libdir}, non-native libs should not live there; it pollutes and causes problems elsewhere. Simple example, if you live on a 64 bit box and install a prebuilt 32 bit app, it will look for files from GAC in /usr/lib. There is no guarantee that GAC will be found. By placing files in /usr/share GAC can always be found. Obviously this is in discussion now (which is why I've invited Andrew Jorgensen from Novell to take part in the thread), but it would certainly make more sense to have them as .noarch packages and in /usr/share. 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 paul at city-fan.org Tue Sep 16 12:45:56 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 16 Sep 2008 13:45:56 +0100 Subject: [Fedora-packaging] Packaging mono - RFC In-Reply-To: <1221568603.26602.36.camel@PB3.Linux> References: <1221568603.26602.36.camel@PB3.Linux> Message-ID: <48CFAA84.40106@city-fan.org> Paul wrote: > Hi, > > Mono (and mono-packages) are currently packaged to %{_libdir} as per the > published guidelines for packaging. > > There has been discussion, both recently and in the past, about moving > mono to .noarch packages and placing them in /usr/share. The rational > behind this is that .NET CIL is a non-architecture specific system which > calls on a central repository of dlls held within GAC. It is a shared > resource rather than a platform specific resource. It is also not a > traditional library (.so). > > While there is no arguing that .so (and standard linux library files) > should remain in %{_libdir}, non-native libs should not live there; it > pollutes and causes problems elsewhere. Simple example, if you live on a > 64 bit box and install a prebuilt 32 bit app, it will look for files > from GAC in /usr/lib. There is no guarantee that GAC will be found. > > By placing files in /usr/share GAC can always be found. > > Obviously this is in discussion now (which is why I've invited Andrew > Jorgensen from Novell to take part in the thread), but it would > certainly make more sense to have them as .noarch packages and > in /usr/share. The Fedora Packaging Guidelines for Mono justify the use of arch-specific libraries on the basis that ahead-of-time (AOT) compiled assemblies are arch-specific and must, if used, live in the same directory as their DLL/EXE counterparts. Ergo the DLL/EXE versions must also live in arch-specific directories. https://fedoraproject.org/wiki/Packaging/Mono Paul. From fedora at leemhuis.info Tue Sep 16 14:16:50 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 16 Sep 2008 16:16:50 +0200 Subject: [Fedora-packaging] Re: Long and "advertising" descriptions In-Reply-To: <20080915150047.GC2849@free.fr> References: <20080914065131.80F65208DA4@bastion.fedora.phx.redhat.com> <48CCCD17.1090001@leemhuis.info> <1221399306.9991.23.camel@localhost.localdomain> <48CE4CD3.7020500@leemhuis.info> <20080915150047.GC2849@free.fr> Message-ID: <48CFBFD2.6020309@leemhuis.info> On 15.09.2008 17:00, Patrice Dumas wrote: > > I don't think advertising should be mentionned, nor removing the authors I totally disagree, as both advertising and authors can lead to really big problems ("can of worms"): - look at the enlightenment description -- it sounds a bit like "this is better then GNOME or KDE"; thus those people maintaining GNOME or KDE might start adding "no, our Desktop is in fact better than Enlightenment"; I'd say nobody want such a mess (even if it sounds unlikely that things really get that worse) - Open-Source is about working together; thus most of the packages we ship have multiple authors; which ones do you mention? the one that started the project? the most important one? If the first: what if he has left ages ago? If the second: who maintains that list and decides? And mentioning the author in one package could lead to other upstream authors to requests like "you guys mention the author in the description for package foo, but you don't mention *my name* in the description of bar, which contains software I wrote. That will get interesting when it comes to packages like the kernels, which has multiple thousand authors CU knurd From pertusus at free.fr Tue Sep 16 14:38:26 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 16 Sep 2008 16:38:26 +0200 Subject: [Fedora-packaging] Re: Long and "advertising" descriptions In-Reply-To: <48CFBFD2.6020309@leemhuis.info> References: <20080914065131.80F65208DA4@bastion.fedora.phx.redhat.com> <48CCCD17.1090001@leemhuis.info> <1221399306.9991.23.camel@localhost.localdomain> <48CE4CD3.7020500@leemhuis.info> <20080915150047.GC2849@free.fr> <48CFBFD2.6020309@leemhuis.info> Message-ID: <20080916143826.GA32189@free.fr> On Tue, Sep 16, 2008 at 04:16:50PM +0200, Thorsten Leemhuis wrote: > On 15.09.2008 17:00, Patrice Dumas wrote: >> >> I don't think advertising should be mentionned, nor removing the authors > > I totally disagree, as both advertising and authors can lead to really > big problems ("can of worms"): I am not saying that we should always add the authors. In general, when I do the description I copy paste something on the web page of th esoftware or in the README. I prefer to keep things as-is, including 'advertisement' and authors, since it seems to me to be how upstream wants the software to be described. That being said, trimming blatant and uninformative advertisement, and authors when they are too numerous is certainly a good practice, but I don't think this should be in the guidelines, the guideline should only have something about the length and the purpose of the %description, in my opinion. -- Pat From tcallawa at redhat.com Tue Sep 16 14:58:38 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 16 Sep 2008 10:58:38 -0400 Subject: [Fedora-packaging] Packaging mono - RFC In-Reply-To: <1221568603.26602.36.camel@PB3.Linux> References: <1221568603.26602.36.camel@PB3.Linux> Message-ID: <1221577118.29052.140.camel@localhost.localdomain> On Tue, 2008-09-16 at 13:36 +0100, Paul wrote: > he rational > behind this is that .NET CIL is a non-architecture specific system > which > calls on a central repository of dlls held within GAC. It is a shared > resource rather than a platform specific resource. It is also not a > traditional library (.so). Except that those files seem to be architecture specific...which is why we moved them to %{_libdir} in the first place. ~spot From stlwrt at gmail.com Tue Sep 16 16:42:19 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Tue, 16 Sep 2008 19:42:19 +0300 Subject: [Fedora-packaging] Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8) Message-ID: I am author of that spec. Gentlemen, start your flamethrowers. =) Text was taken from http://www.enlightenment.org/p.php?p=about/e17&l=en , which is description of product by its developers, published on official website of project. I will shorten description in CVS, but i don't think this cosmetical change is worth pushing another update. Comments are welcome, i joined this list now. -- http://scwlab.com From a.badger at gmail.com Tue Sep 16 16:41:59 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 16 Sep 2008 09:41:59 -0700 Subject: [Fedora-packaging] Packaging mono - RFC In-Reply-To: <1221577118.29052.140.camel@localhost.localdomain> References: <1221568603.26602.36.camel@PB3.Linux> <1221577118.29052.140.camel@localhost.localdomain> Message-ID: <48CFE1D7.8080801@gmail.com> Tom "spot" Callaway wrote: > On Tue, 2008-09-16 at 13:36 +0100, Paul wrote: >> he rational >> behind this is that .NET CIL is a non-architecture specific system >> which >> calls on a central repository of dlls held within GAC. It is a shared >> resource rather than a platform specific resource. It is also not a >> traditional library (.so). > > Except that those files seem to be architecture specific...which is why > we moved them to %{_libdir} in the first place. > When researching this for the Guidelines, I found a thread on the Debian lists in which they decided to move from /usr/share to /usr/lib because of input from Miguel. I can find that discussion in their archives if needed but the gist of it was: 1) DLLs can call architecture specific code using architecture specific types and there's no good way to detect that the code is doing this without analyzing the source code. We don't want to inflict that on packagers. If there is an easily automated method for finding these cases, that would help here. 2) DLLs can be AOT-compiled. Those AOT-compiled bits have to live next to the architecture independent DLLs. If the AOT loading code was rewritten to be able to find the DLLs in a different place from the AOT compiled code or if the AOT compiled bits could have all the information necessary and not need to find the DLLs at all, then that would make this go away. If someone's going to allocate resources to fixing these issues, make sure I dig up that Debian thread as there may be a third problem I'm not remembering at the moment. -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 Tue Sep 16 16:46:02 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 16 Sep 2008 11:46:02 -0500 Subject: [Fedora-packaging] Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8) In-Reply-To: References: Message-ID: <48CFE2CA.3040305@math.unl.edu> Pavel Shevchuk wrote: > I am author of that spec. Gentlemen, start your flamethrowers. =) > > Text was taken from > http://www.enlightenment.org/p.php?p=about/e17&l=en , which is > description of product by its developers, published on official > website of project. I will shorten description in CVS, but i don't > think this cosmetical change is worth pushing another update. Agreed, thanks. -- Rex From stlwrt at gmail.com Tue Sep 16 17:14:20 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Tue, 16 Sep 2008 20:14:20 +0300 Subject: [Fedora-packaging] Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8) In-Reply-To: References: Message-ID: New description: Enlightenment 0.17 is desktop shell based on Enlightenment Foundation Libraries. It's highly optimized and provides extensive theming capabilities. A Desktop shell means it's a window manager plus a file manager, plus configuration utilitys all in one. It works reasonably fast even on old and low range computers, providing eye-candy environment. On Tue, Sep 16, 2008 at 7:42 PM, Pavel Shevchuk wrote: > I am author of that spec. Gentlemen, start your flamethrowers. =) > > Text was taken from > http://www.enlightenment.org/p.php?p=about/e17&l=en , which is > description of product by its developers, published on official > website of project. I will shorten description in CVS, but i don't > think this cosmetical change is worth pushing another update. > > Comments are welcome, i joined this list now. > > -- > http://scwlab.com > -- http://scwlab.com From tcallawa at redhat.com Tue Sep 16 17:16:12 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 16 Sep 2008 13:16:12 -0400 Subject: [Fedora-packaging] Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8) In-Reply-To: References: Message-ID: <1221585372.29052.160.camel@localhost.localdomain> On Tue, 2008-09-16 at 20:14 +0300, Pavel Shevchuk wrote: > New description: > > Enlightenment 0.17 is desktop shell based on Enlightenment Foundation > Libraries. It's highly optimized and provides extensive theming capabilities. > A Desktop shell means it's a window manager plus a file manager, plus > configuration utilitys all in one. It works reasonably fast even on old and low > range computers, providing eye-candy environment. Looks good, thanks. ~spot From paul at city-fan.org Tue Sep 16 18:51:13 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 16 Sep 2008 19:51:13 +0100 Subject: [Fedora-packaging] Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8) In-Reply-To: <1221585372.29052.160.camel@localhost.localdomain> References: <1221585372.29052.160.camel@localhost.localdomain> Message-ID: <20080916195113.37ff5b37@metropolis.intra.city-fan.org> On Tue, 16 Sep 2008 13:16:12 -0400 "Tom \"spot\" Callaway" wrote: > On Tue, 2008-09-16 at 20:14 +0300, Pavel Shevchuk wrote: > > New description: > > > > Enlightenment 0.17 is desktop shell based on Enlightenment > > Foundation Libraries. It's highly optimized and provides extensive > > theming capabilities. A Desktop shell means it's a window manager > > plus a file manager, plus configuration utilitys all in one. It > > works reasonably fast even on old and low range computers, > > providing eye-candy environment. > > Looks good, thanks. Except you should s/utilitys/utilities/ Paul. From cra at WPI.EDU Tue Sep 16 19:44:46 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 16 Sep 2008 15:44:46 -0400 Subject: [Fedora-packaging] rpmlint non-standard-[ug]id, non-standard-dir-perm Message-ID: <20080916194446.GZ32741@angus.ind.WPI.EDU> I'm packaging cricket and rpmlint complains: cricket.noarch: W: non-standard-uid /etc/cricket/config/Defaults cricket cricket.noarch: W: non-standard-gid /etc/cricket/config/Defaults apache cricket.noarch: W: non-standard-uid /etc/cricket/config cricket cricket.noarch: W: non-standard-gid /etc/cricket/config apache cricket.noarch: E: non-standard-dir-perm /etc/cricket/config 0771 cricket.noarch: W: non-standard-uid /etc/cricket cricket cricket.noarch: W: non-standard-gid /etc/cricket apache cricket.noarch: E: non-standard-dir-perm /etc/cricket 0771 cricket.noarch: W: non-standard-uid /etc/cricket/cricket-conf.pl cricket cricket.noarch: W: non-standard-gid /etc/cricket/cricket-conf.pl apache cricket.noarch: W: non-standard-gid /var/log/cricket cricket cricket.noarch: E: non-standard-dir-perm /var/log/cricket 0775 cricket.noarch: W: non-standard-uid /etc/cricket/subtree-sets cricket cricket.noarch: W: non-standard-gid /etc/cricket/subtree-sets apache cricket.noarch: W: non-standard-uid /var/cache/cricket apache cricket.noarch: W: non-standard-gid /var/cache/cricket cricket cricket.noarch: W: non-standard-gid /var/lib/cricket cricket cricket.noarch: E: non-standard-dir-perm /var/lib/cricket 0775 What is the rationale for these warnings and errors, and why should the package avoid using them? From tcallawa at redhat.com Tue Sep 16 19:50:35 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 16 Sep 2008 15:50:35 -0400 Subject: [Fedora-packaging] rpmlint non-standard-[ug]id, non-standard-dir-perm In-Reply-To: <20080916194446.GZ32741@angus.ind.WPI.EDU> References: <20080916194446.GZ32741@angus.ind.WPI.EDU> Message-ID: <1221594635.29052.188.camel@localhost.localdomain> On Tue, 2008-09-16 at 15:44 -0400, Chuck Anderson wrote: > I'm packaging cricket and rpmlint complains: > > cricket.noarch: W: non-standard-uid /etc/cricket/config/Defaults cricket > cricket.noarch: W: non-standard-gid /etc/cricket/config/Defaults apache > cricket.noarch: W: non-standard-uid /etc/cricket/config cricket > cricket.noarch: W: non-standard-gid /etc/cricket/config apache > cricket.noarch: E: non-standard-dir-perm /etc/cricket/config 0771 > cricket.noarch: W: non-standard-uid /etc/cricket cricket > cricket.noarch: W: non-standard-gid /etc/cricket apache > cricket.noarch: E: non-standard-dir-perm /etc/cricket 0771 > cricket.noarch: W: non-standard-uid /etc/cricket/cricket-conf.pl cricket > cricket.noarch: W: non-standard-gid /etc/cricket/cricket-conf.pl apache > cricket.noarch: W: non-standard-gid /var/log/cricket cricket > cricket.noarch: E: non-standard-dir-perm /var/log/cricket 0775 > cricket.noarch: W: non-standard-uid /etc/cricket/subtree-sets cricket > cricket.noarch: W: non-standard-gid /etc/cricket/subtree-sets apache > cricket.noarch: W: non-standard-uid /var/cache/cricket apache > cricket.noarch: W: non-standard-gid /var/cache/cricket cricket > cricket.noarch: W: non-standard-gid /var/lib/cricket cricket > cricket.noarch: E: non-standard-dir-perm /var/lib/cricket 0775 > > What is the rationale for these warnings and errors, and why should > the package avoid using them? Basically, rpmlint is asking: Why are these files owned by users/groups I don't recognize? and Why do these directories have odd permissions (771 and 775 are a little unique)? If you have good answers for these questions, they're safe to ignore. ~spot From ville.skytta at iki.fi Wed Sep 17 20:09:31 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 17 Sep 2008 23:09:31 +0300 Subject: [Fedora-packaging] rpmlint non-standard-[ug]id, non-standard-dir-perm In-Reply-To: <20080916194446.GZ32741@angus.ind.WPI.EDU> References: <20080916194446.GZ32741@angus.ind.WPI.EDU> Message-ID: <200809172309.32152.ville.skytta@iki.fi> On Tuesday 16 September 2008, Chuck Anderson wrote: > What is the rationale for these warnings and errors, non-standard-[ug]id: useful for catching bad user/group ownership, most often encountered with missing %defattr/%attr when built as non-root with rpmbuild < 4.4. non-standard-dir-perm: useful for catching bad dir permissions, e.g. sgid bits leaked to packages in some build setups, or accidentally otherwise bad perms. Should probably be downgraded from error to warning though. > and why should the package avoid using them? If they're intentional and correct, it shouldn't. From pertusus at free.fr Thu Sep 18 10:11:04 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 18 Sep 2008 12:11:04 +0200 Subject: [Fedora-packaging] Are there *any* guidelines for what "Group:" an application should go in? In-Reply-To: <489C91BF.5010505@gmail.com> References: <489C91BF.5010505@gmail.com> Message-ID: <20080918101104.GA4157@free.fr> On Fri, Aug 08, 2008 at 11:34:39AM -0700, Toshio Kuratomi wrote: > Vasile Gaburici wrote: >> Furthermore, are there any guidelines for the creation of new groups? >> > Pretty much no. We've settled on using comps for grouping of packages > rather than the Group: tag. That said, it's probably best to use one of > the existing groups (listed in /usr/share/doc/rpm-%{version}/GROUPS I have added something along your words here: https://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Recommended_values_for_the_Group:_tag Please have a look to see if it is right. -- Pat From dev at nigelj.com Thu Sep 18 13:41:50 2008 From: dev at nigelj.com (Nigel Jones) Date: Fri, 19 Sep 2008 01:41:50 +1200 Subject: [Fedora-packaging] Use of Internal Libraries Message-ID: <1221745310.3446.13.camel@fantail.jnet.net.nz> Hey guys, So I know we have http://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_libraries which I think is pretty good, easy to understand and fairly simple. The problem I think is that some upstream's still want to ship internal, modified libraries. Prime examples are mono packages, I can think of Banshee, Cowbell and f-spot from personal experience. It's got to point where another upstream is giving me a little bit of hard time over it all, I even had a Debian developer agree with our guidelines (they have the same). Upstream says "it's a guideline not a rule". _MY_ question is, what can we (Fedora) do to make it clear that we have clear cut rules for why we don't want packages providing internal libraries? - NJ -- Nigel Jones From paul at all-the-johnsons.co.uk Thu Sep 18 14:01:01 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 18 Sep 2008 15:01:01 +0100 Subject: [Fedora-packaging] Use of Internal Libraries In-Reply-To: <1221745310.3446.13.camel@fantail.jnet.net.nz> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> Message-ID: <1221746461.19211.10.camel@PB3.Linux> Hi, > _MY_ question is, what can we (Fedora) do to make it clear that we have > clear cut rules for why we don't want packages providing internal > libraries? As long as it's explained to upstream why we have this guide, then we've really done all we can. Take Mono.Cecil. It's not in GAC as the API is not stable, so MonoDevelop and a few other packages all come with their own sources of Mono.Cecil which may or may not be the same as the ones we built Mono.Cecil with. As MD accesses it's own Mono.Cecil which it built (which is not in GAC), it is not likely to interfere with anything, however upstream will use that as a reason for including their own sources. Realistically, what can we do about it - nothing as if upstream want to do as they do then all we can do is remove the package or start submitting piles of bugs when things go wrong to try and force them around to our way of doing things. Some may, some may continue regardless. Bit of a bummer that... 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 a.badger at gmail.com Thu Sep 18 16:05:07 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 18 Sep 2008 09:05:07 -0700 Subject: [Fedora-packaging] Use of Internal Libraries In-Reply-To: <1221745310.3446.13.camel@fantail.jnet.net.nz> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> Message-ID: <48D27C33.3030806@gmail.com> Nigel Jones wrote: > Hey guys, > > So I know we have > http://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_libraries which I think is pretty good, easy to understand and fairly simple. > > The problem I think is that some upstream's still want to ship internal, > modified libraries. > > Prime examples are mono packages, I can think of Banshee, Cowbell and > f-spot from personal experience. > > It's got to point where another upstream is giving me a little bit of > hard time over it all, I even had a Debian developer agree with our > guidelines (they have the same). > > Upstream says "it's a guideline not a rule". > > _MY_ question is, what can we (Fedora) do to make it clear that we have > clear cut rules for why we don't want packages providing internal > libraries? > 1) We could rename the Guidelines to: Fedora Packaging Rules. I know that many people like to say that the Guidelines really are Guidelines and that they can be broken for good reason but I'd much rather have them be strictly followed -- but make the process of granting provisional exceptions easier. Having "MUST" rules that people can choose to disregard is silly. Remaining flexible about changing the rules when faced with areas that they don't live up to is the aspect that we want to retain, promote, and improve. 2) Better organization. Each rule should have a short form and link to a long form that explains the reasoning behind it. This is something we need to take up with the docs team so we can figure out a better way to organize the rules. CC'ing Karsten for this part. 3) I suspect that if your upstream is resorting to telling you, a Fedora Contributor, that the Fedora Guidelines are non-binding, then no matter what we do, he won't see reason. We can do a better job of explaining it and we can get other distributions (which generally understand the reasoning here) to help put pressure on but at the end of the day the upstream author will either see the light or they won't. One thing we could try in the distro-pressure regard is taking this up with the distributions group. ##distro on irc.freenode.net, http://distribution.freedesktop.org, and http://lists.freedesktop.org/mailman/listinfo/distributions Do people think that's a good way to go? I'll send an email off to them if so. -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 dev at nigelj.com Thu Sep 18 22:22:48 2008 From: dev at nigelj.com (Nigel Jones) Date: Fri, 19 Sep 2008 10:22:48 +1200 Subject: [Fedora-packaging] Use of Internal Libraries In-Reply-To: <48D27C33.3030806@gmail.com> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <48D27C33.3030806@gmail.com> Message-ID: <1221776568.3446.22.camel@fantail.jnet.net.nz> On Thu, 2008-09-18 at 09:05 -0700, Toshio Kuratomi wrote: > Nigel Jones wrote: > > Hey guys, > > > > So I know we have > > http://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_libraries which I think is pretty good, easy to understand and fairly simple. > > > > The problem I think is that some upstream's still want to ship internal, > > modified libraries. > > > > Prime examples are mono packages, I can think of Banshee, Cowbell and > > f-spot from personal experience. > > > > It's got to point where another upstream is giving me a little bit of > > hard time over it all, I even had a Debian developer agree with our > > guidelines (they have the same). > > > > Upstream says "it's a guideline not a rule". > > > > _MY_ question is, what can we (Fedora) do to make it clear that we have > > clear cut rules for why we don't want packages providing internal > > libraries? > > > > 1) We could rename the Guidelines to: Fedora Packaging Rules. > > I know that many people like to say that the Guidelines really are > Guidelines and that they can be broken for good reason but I'd much > rather have them be strictly followed -- but make the process of > granting provisional exceptions easier. Maybe have two sets? Fedora Packaging Principals - things that MUST NOT be broken (think - do no harm, ensure patches go upstream, don't replace system libraries in a package etc), and then the Fedora Packaging Guidelines (where there can be a little bit of change due to special circumstances (I can't remove rpath because the package just won't work without it). > > Having "MUST" rules that people can choose to disregard is silly. > Remaining flexible about changing the rules when faced with areas that > they don't live up to is the aspect that we want to retain, promote, and > improve. > > 2) Better organization. Each rule should have a short form and link to > a long form that explains the reasoning behind it. This is something we > need to take up with the docs team so we can figure out a better way to > organize the rules. CC'ing Karsten for this part. Agreed > > 3) I suspect that if your upstream is resorting to telling you, a Fedora > Contributor, that the Fedora Guidelines are non-binding, then no matter > what we do, he won't see reason. We can do a better job of explaining > it and we can get other distributions (which generally understand the > reasoning here) to help put pressure on but at the end of the day the > upstream author will either see the light or they won't. > > One thing we could try in the distro-pressure regard is taking this up > with the distributions group. ##distro on irc.freenode.net, > http://distribution.freedesktop.org, and > http://lists.freedesktop.org/mailman/listinfo/distributions > > Do people think that's a good way to go? I'll send an email off to them > if so. I didn't know about the list, I think it'd be a good way to go, I know Debian seem to agree with our policy, it'd be nice to create a united front (in a way) to say to projects that it's unacceptable. Really it all comes down to this: If upstreams have a really good reason to change another upstreams code, why haven't they submit it to their upstream? It gets even more silly when upstreams act as upstream for other minor libraries so that you get 5 or so copies floating about on your system because everyone has had to fork it, because they've explicitly said to maintainers to not package separately/as a subpackage. - NJ -- Nigel Jones From a.badger at gmail.com Fri Sep 19 03:29:51 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 18 Sep 2008 20:29:51 -0700 Subject: [Fedora-packaging] Use of Internal Libraries In-Reply-To: <1221776568.3446.22.camel@fantail.jnet.net.nz> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <48D27C33.3030806@gmail.com> <1221776568.3446.22.camel@fantail.jnet.net.nz> Message-ID: <48D31CAF.1050600@gmail.com> Nigel Jones wrote: > On Thu, 2008-09-18 at 09:05 -0700, Toshio Kuratomi wrote: >> Nigel Jones wrote: >>> Hey guys, >>> >>> So I know we have >>> http://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_libraries which I think is pretty good, easy to understand and fairly simple. >>> >>> The problem I think is that some upstream's still want to ship internal, >>> modified libraries. >>> >>> Prime examples are mono packages, I can think of Banshee, Cowbell and >>> f-spot from personal experience. >>> >>> It's got to point where another upstream is giving me a little bit of >>> hard time over it all, I even had a Debian developer agree with our >>> guidelines (they have the same). >>> >>> Upstream says "it's a guideline not a rule". >>> >>> _MY_ question is, what can we (Fedora) do to make it clear that we have >>> clear cut rules for why we don't want packages providing internal >>> libraries? >>> >> 1) We could rename the Guidelines to: Fedora Packaging Rules. >> >> I know that many people like to say that the Guidelines really are >> Guidelines and that they can be broken for good reason but I'd much >> rather have them be strictly followed -- but make the process of >> granting provisional exceptions easier. > Maybe have two sets? Fedora Packaging Principals - things that MUST NOT > be broken (think - do no harm, ensure patches go upstream, don't replace > system libraries in a package etc), and then the Fedora Packaging > Guidelines (where there can be a little bit of change due to special > circumstances (I can't remove rpath because the package just won't work > without it). >> Having "MUST" rules that people can choose to disregard is silly. >> Remaining flexible about changing the rules when faced with areas that >> they don't live up to is the aspect that we want to retain, promote, and >> improve. >> >> 2) Better organization. Each rule should have a short form and link to >> a long form that explains the reasoning behind it. This is something we >> need to take up with the docs team so we can figure out a better way to >> organize the rules. CC'ing Karsten for this part. > Agreed >> 3) I suspect that if your upstream is resorting to telling you, a Fedora >> Contributor, that the Fedora Guidelines are non-binding, then no matter >> what we do, he won't see reason. We can do a better job of explaining >> it and we can get other distributions (which generally understand the >> reasoning here) to help put pressure on but at the end of the day the >> upstream author will either see the light or they won't. >> >> One thing we could try in the distro-pressure regard is taking this up >> with the distributions group. ##distro on irc.freenode.net, >> http://distribution.freedesktop.org, and >> http://lists.freedesktop.org/mailman/listinfo/distributions >> >> Do people think that's a good way to go? I'll send an email off to them >> if so. > I didn't know about the list, I think it'd be a good way to go, I know > Debian seem to agree with our policy, it'd be nice to create a united > front (in a way) to say to projects that it's unacceptable. > Message sent: http://lists.freedesktop.org/archives/distributions/2008-September/000226.html Anyone interested, feel free to contribute to the thread that will likely result. if this is seen as a good thing, we'll probably want to start documenting our justifications for doing this on the distributions.freedesktop.org wiki. > Really it all comes down to this: > > If upstreams have a really good reason to change another upstreams code, > why haven't they submit it to their upstream? > > It gets even more silly when upstreams act as upstream for other minor > libraries so that you get 5 or so copies floating about on your system > because everyone has had to fork it, because they've explicitly said to > maintainers to not package separately/as a subpackage. > -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 pmatilai at laiskiainen.org Fri Sep 19 06:16:18 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 19 Sep 2008 09:16:18 +0300 (EEST) Subject: [Fedora-packaging] Re: Group tag in spec files In-Reply-To: <200809080903.41290.ville.skytta@iki.fi> References: <48C2BCB7.9030103@timj.co.uk> <200809071945.39547.ville.skytta@iki.fi> <20080907213112.GA25734@victor.nirvana> <200809080903.41290.ville.skytta@iki.fi> Message-ID: On Mon, 8 Sep 2008, Ville Skytt? wrote: > On Monday 08 September 2008, Axel Thimm wrote: > >> We certainly can't afford to lose LSB compliance (I didn't knew >> Groups: was referenced there), so indeed we need to step down a >> bit. > > Regarding the LSB, I don't know whether the format of packages produced by rpm > in current Fedora releases is LSB compliant even without any Group tag > changes. If it is, I suppose making Group optional in specfiles does not > necessarily mean losing LSB compliance, rpmbuild could just insert some fixed > string as its value in the package headers it produces if the tag is not > present in a specfile. Nod. Rpm will now slam in "Unspecified" into group tag if spec doesn't specify it (this isn't in Fedora yet, I'm waiting for the freeze to be over for the next rebase). As for LSB compliance generally, we're about as non-compliant as we've always been since rpm 4.0. - Panu - From Axel.Thimm at ATrpms.net Fri Sep 19 07:34:01 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 19 Sep 2008 10:34:01 +0300 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <1221745310.3446.13.camel@fantail.jnet.net.nz> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> Message-ID: <20080919073401.GA26302@victor.nirvana> On Fri, Sep 19, 2008 at 01:41:50AM +1200, Nigel Jones wrote: > So I know we have > http://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_libraries > which I think is pretty good, easy to understand and fairly simple. > > The problem I think is that some upstream's still want to ship > internal, modified libraries. > Upstream says "it's a guideline not a rule". > > _MY_ question is, what can we (Fedora) do to make it clear that we have > clear cut rules for why we don't want packages providing internal > libraries? I'd ask the question differently: If upstream saw itself forced to duplicate/fork a lib how can you help making the forked bits back into the original upstream. I'm not targeting convenience bundling of libs as some projects do/did (these should really be replaced by system libs!), but rather patched up copies of libs that either use specific patches suitable only for that project or the lib upstream generaly is accepting patches at a slow or non-existant rate. Just to quote one such example: ffmpeg is a fast moving target, and any project depending on the lib API is cutting a checkout, patching it a up and using it for its own purposes. Replacing these internal ffmpegs with a system ffmpeg is a nightmare or even impossible w/o rewriting the app interface to it. Given that ffmpeg and friends fall under the patent forbidden class we don't see that directly in Fedora, but this issue is still out there. Other examples that do live in Fedora are minilzo that was never designed to be a shared lib and the consumer apps never designed their build system for a shared minilzo resulting in packages being broken/stalled for months and years before entering Fedora (like libvcnserver and x11vnc). https://bugzilla.redhat.com/show_bug.cgi?id=439772#c21 https://bugzilla.redhat.com/show_bug.cgi?id=439979#c24 I'd recommend to soften this guideline to something as "the packager should try hard to use system libs, and try to communicate the benefits to upstream, but if there are reasons not to use system libs, then he should document this in the specfile". -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rc040203 at freenet.de Fri Sep 19 07:59:42 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 19 Sep 2008 09:59:42 +0200 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <20080919073401.GA26302@victor.nirvana> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <20080919073401.GA26302@victor.nirvana> Message-ID: <1221811182.18327.1145.camel@beck.corsepiu.local> On Fri, 2008-09-19 at 10:34 +0300, Axel Thimm wrote: > On Fri, Sep 19, 2008 at 01:41:50AM +1200, Nigel Jones wrote: > > So I know we have > > http://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_libraries > > which I think is pretty good, easy to understand and fairly simple. > > > > The problem I think is that some upstream's still want to ship > > internal, modified libraries. > > > Upstream says "it's a guideline not a rule". > > > > _MY_ question is, what can we (Fedora) do to make it clear that we have > > clear cut rules for why we don't want packages providing internal > > libraries? > > I'd ask the question differently: If upstream saw itself forced to > duplicate/fork a lib how can you help making the forked bits back into > the original upstream. Then let me answer with my "developer's hat" on: The reason why such "forks" exist, often is disagreement between "upstream" and "fork" devs, because they disagree on APIs/usage and the like. Upstreams often accuse "fork devs" to be abusing their libraries/APIs (e.g. using undocumented internals). Conversely, "fork devs" often accuse "upstreams" not to listen to "users' demands". I.e. in many cases such conflicts will hardly be resolvable. > Just to quote one such example: ffmpeg is a fast moving target, and > any project depending on the lib API is cutting a checkout, patching > it a up and using it for its own purposes. Replacing these internal > ffmpegs with a system ffmpeg is a nightmare or even impossible w/o > rewriting the app interface to it. Given that ffmpeg and friends fall > under the patent forbidden class we don't see that directly in Fedora, > but this issue is still out there. Well, ffmpeg is a special case wrt. many issues. If they were doing a proper job, they would release properly versioned packages with properly versioned APIs, which could be installed in parallel. > I'd recommend to soften this guideline to something as "the packager > should try hard to use system libs, and try to communicate the > benefits to upstream, but if there are reasons not to use system libs, > then he should document this in the specfile". I am not sure this is a good idea. I'd rather be stricter on this, because this would force devs to think about what they are doing and packagers think about the quality of what they are packaging. The unpleasant truth is: If a package bundles "modified libs/apps" from elsewhere, which can't be installed in parallel to the original libs/apps, this package's dev's are doing something wrong. Ralf From dominik at greysector.net Fri Sep 19 12:56:25 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 19 Sep 2008 14:56:25 +0200 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <20080919073401.GA26302@victor.nirvana> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <20080919073401.GA26302@victor.nirvana> Message-ID: <20080919125625.GE24607@mokona.greysector.net> On Friday, 19 September 2008 at 09:34, Axel Thimm wrote: > On Fri, Sep 19, 2008 at 01:41:50AM +1200, Nigel Jones wrote: > > So I know we have > > http://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_libraries > > which I think is pretty good, easy to understand and fairly simple. > > > > The problem I think is that some upstream's still want to ship > > internal, modified libraries. > > > Upstream says "it's a guideline not a rule". > > > > _MY_ question is, what can we (Fedora) do to make it clear that we have > > clear cut rules for why we don't want packages providing internal > > libraries? [...] > Just to quote one such example: ffmpeg is a fast moving target, and > any project depending on the lib API is cutting a checkout, patching > it a up and using it for its own purposes. Replacing these internal > ffmpegs with a system ffmpeg is a nightmare or even impossible w/o > rewriting the app interface to it. Given that ffmpeg and friends fall > under the patent forbidden class we don't see that directly in Fedora, > but this issue is still out there. I don't know if you've been following FFmpeg development lately, but they have improved over the last year or so to the point that no ABI breakage occurs without bumping the major version of the affected library. The pkg-config support is put properly in place, too, so if you haven't done that already, it's high time to begin convincing depdendent projects to start supporting shared FFmpeg. I've already begun working on fixing the main consumer of FFmpeg, MPlayer, to do that. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Fri Sep 19 12:59:22 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 19 Sep 2008 14:59:22 +0200 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <1221811182.18327.1145.camel@beck.corsepiu.local> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <20080919073401.GA26302@victor.nirvana> <1221811182.18327.1145.camel@beck.corsepiu.local> Message-ID: <20080919125922.GF24607@mokona.greysector.net> On Friday, 19 September 2008 at 09:59, Ralf Corsepius wrote: > On Fri, 2008-09-19 at 10:34 +0300, Axel Thimm wrote: [...] > > Just to quote one such example: ffmpeg is a fast moving target, and > > any project depending on the lib API is cutting a checkout, patching > > it a up and using it for its own purposes. Replacing these internal > > ffmpegs with a system ffmpeg is a nightmare or even impossible w/o > > rewriting the app interface to it. Given that ffmpeg and friends fall > > under the patent forbidden class we don't see that directly in Fedora, > > but this issue is still out there. > Well, ffmpeg is a special case wrt. many issues. If they were doing a > proper job, they would release properly versioned packages with properly > versioned APIs, which could be installed in parallel. They(we) don't have the manpower to do proper releases, but we do maintain properly versioned API/ABI. The position of a release manager for FFmpeg has been open for months. Many people complained, but nobody is willing to do the legwork. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From Axel.Thimm at ATrpms.net Fri Sep 19 16:58:26 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 19 Sep 2008 19:58:26 +0300 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <20080919125625.GE24607@mokona.greysector.net> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <20080919073401.GA26302@victor.nirvana> <20080919125625.GE24607@mokona.greysector.net> Message-ID: <20080919165826.GA13838@victor.nirvana> On Fri, Sep 19, 2008 at 02:56:25PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Friday, 19 September 2008 at 09:34, Axel Thimm wrote: > > On Fri, Sep 19, 2008 at 01:41:50AM +1200, Nigel Jones wrote: > > > So I know we have > > > http://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_libraries > > > which I think is pretty good, easy to understand and fairly simple. > > > > > > The problem I think is that some upstream's still want to ship > > > internal, modified libraries. > > > > > Upstream says "it's a guideline not a rule". > > > > > > _MY_ question is, what can we (Fedora) do to make it clear that we have > > > clear cut rules for why we don't want packages providing internal > > > libraries? > [...] > > Just to quote one such example: ffmpeg is a fast moving target, and > > any project depending on the lib API is cutting a checkout, patching > > it a up and using it for its own purposes. Replacing these internal > > ffmpegs with a system ffmpeg is a nightmare or even impossible w/o > > rewriting the app interface to it. Given that ffmpeg and friends fall > > under the patent forbidden class we don't see that directly in Fedora, > > but this issue is still out there. > > I don't know if you've been following FFmpeg development lately, but > they have improved over the last year or so to the point that no ABI > breakage occurs Note I mentioned the API, which is still changing on a regular basis. For ffmpeg it doesn't actually help that there are no releases ever either. > without bumping the major version of the affected library. The > pkg-config support is put properly in place, too, so if you haven't > done that already, it's high time to begin convincing depdendent > projects to start supporting shared FFmpeg. I've already begun > working on fixing the main consumer of FFmpeg, MPlayer, to do that. Unless ffmpeg actually releases anything again I doubt that too many projects will try to depend on an external shared lib whose API stability window is a few weeks. This is not a criticism against the very nice work of the ffmpeg people. They just need the freedom of a non stable API for being able to develop as fast and take into account that projects need to cut a snapshot (actually they enforce this explicitely). -- Axel.Thimm at ATrpms.net From Axel.Thimm at ATrpms.net Fri Sep 19 17:01:50 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 19 Sep 2008 20:01:50 +0300 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <20080919125922.GF24607@mokona.greysector.net> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <20080919073401.GA26302@victor.nirvana> <1221811182.18327.1145.camel@beck.corsepiu.local> <20080919125922.GF24607@mokona.greysector.net> Message-ID: <20080919170150.GB13838@victor.nirvana> On Fri, Sep 19, 2008 at 02:59:22PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Friday, 19 September 2008 at 09:59, Ralf Corsepius wrote: > > On Fri, 2008-09-19 at 10:34 +0300, Axel Thimm wrote: > [...] > > > Just to quote one such example: ffmpeg is a fast moving target, and > > > any project depending on the lib API is cutting a checkout, patching > > > it a up and using it for its own purposes. Replacing these internal > > > ffmpegs with a system ffmpeg is a nightmare or even impossible w/o > > > rewriting the app interface to it. Given that ffmpeg and friends fall > > > under the patent forbidden class we don't see that directly in Fedora, > > > but this issue is still out there. > > Well, ffmpeg is a special case wrt. many issues. If they were doing a > > proper job, they would release properly versioned packages with properly > > versioned APIs, which could be installed in parallel. > > They(we) don't have the manpower to do proper releases, but we do maintain > properly versioned API/ABI. The position of a release manager for FFmpeg > has been open for months. Many people complained, but nobody is willing > to do the legwork. Actually I did, you can read it up at the archives, but the ffmpeg devs didn't think this would be a good idea. The only positive comments were from other distribution packagers that would have even joined the release team taskforce, but w/o the developers' blessing (and at the very least a "do it now" assignment) there wasn't much we could do. -- Axel.Thimm at ATrpms.net From Axel.Thimm at ATrpms.net Fri Sep 19 17:09:33 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 19 Sep 2008 20:09:33 +0300 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <1221811182.18327.1145.camel@beck.corsepiu.local> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <20080919073401.GA26302@victor.nirvana> <1221811182.18327.1145.camel@beck.corsepiu.local> Message-ID: <20080919170933.GC13838@victor.nirvana> On Fri, Sep 19, 2008 at 09:59:42AM +0200, Ralf Corsepius wrote: > > I'd ask the question differently: If upstream saw itself forced to > > duplicate/fork a lib how can you help making the forked bits back into > > the original upstream. > Then let me answer with my "developer's hat" on: > > The reason why such "forks" exist, often is disagreement between > "upstream" and "fork" devs, because they disagree on APIs/usage and the > like. > > Upstreams often accuse "fork devs" to be abusing their libraries/APIs > (e.g. using undocumented internals). Conversely, "fork devs" often > accuse "upstreams" not to listen to "users' demands". > > I.e. in many cases such conflicts will hardly be resolvable. Yes, and sometimes as in the case of ffmpeg and minilzo upstream even wants you to take a snapshot, e.g. the "forking" is in their consent. > > Just to quote one such example: ffmpeg is a fast moving target, and > > any project depending on the lib API is cutting a checkout, patching > > it a up and using it for its own purposes. Replacing these internal > > ffmpegs with a system ffmpeg is a nightmare or even impossible w/o > > rewriting the app interface to it. Given that ffmpeg and friends fall > > under the patent forbidden class we don't see that directly in Fedora, > > but this issue is still out there. > Well, ffmpeg is a special case wrt. many issues. If they were doing a > proper job, they would release properly versioned packages with properly > versioned APIs, which could be installed in parallel. Even if so, would Fedora package 20 different versions of ffmpeg to satisfy the 20 different consumers? There wouldn't be any benefits to an internal lib either: If there is a security flaw fixed in ffmpeg 1004.0.1 the versions 900.x.y to 1003.x.y would be just as insecure as external packages. > > I'd recommend to soften this guideline to something as "the packager > > should try hard to use system libs, and try to communicate the > > benefits to upstream, but if there are reasons not to use system libs, > > then he should document this in the specfile". > I am not sure this is a good idea. I'd rather be stricter on this, > because this would force devs to think about what they are doing and > packagers think about the quality of what they are packaging. > > The unpleasant truth is: If a package bundles "modified libs/apps" from > elsewhere, which can't be installed in parallel to the original > libs/apps, this package's dev's are doing something wrong. The truth is that sometimes upstream makes some decisions, we can try to forward our position, but upstream may ignore us or maybe will have a good reason to counter our position (for ffmpeg and minilzo I believe upstream is correct and we should be the ones revising the guidelines). That's why I suggest that the packager tries hard to do it in the typical shared way, but if there are sane reasons to use internal libs to not let the package dry out forever in some review queue like for x11vnc. -- Axel.Thimm at ATrpms.net From dominik at greysector.net Fri Sep 19 17:55:38 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 19 Sep 2008 19:55:38 +0200 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <20080919165826.GA13838@victor.nirvana> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <20080919073401.GA26302@victor.nirvana> <20080919125625.GE24607@mokona.greysector.net> <20080919165826.GA13838@victor.nirvana> Message-ID: <20080919175537.GA27646@mokona.greysector.net> On Friday, 19 September 2008 at 18:58, Axel Thimm wrote: > On Fri, Sep 19, 2008 at 02:56:25PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > On Friday, 19 September 2008 at 09:34, Axel Thimm wrote: > > > On Fri, Sep 19, 2008 at 01:41:50AM +1200, Nigel Jones wrote: > > > > So I know we have > > > > http://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_libraries > > > > which I think is pretty good, easy to understand and fairly simple. > > > > > > > > The problem I think is that some upstream's still want to ship > > > > internal, modified libraries. > > > > > > > Upstream says "it's a guideline not a rule". > > > > > > > > _MY_ question is, what can we (Fedora) do to make it clear that we have > > > > clear cut rules for why we don't want packages providing internal > > > > libraries? > > [...] > > > Just to quote one such example: ffmpeg is a fast moving target, and > > > any project depending on the lib API is cutting a checkout, patching > > > it a up and using it for its own purposes. Replacing these internal > > > ffmpegs with a system ffmpeg is a nightmare or even impossible w/o > > > rewriting the app interface to it. Given that ffmpeg and friends fall > > > under the patent forbidden class we don't see that directly in Fedora, > > > but this issue is still out there. > > > > I don't know if you've been following FFmpeg development lately, but > > they have improved over the last year or so to the point that no ABI > > breakage occurs > > Note I mentioned the API, which is still changing on a regular > basis. For ffmpeg it doesn't actually help that there are no releases > ever either. API is not changing on a regular basis either. If there are incompatible changes, they are accompanied by a major version bump. > > without bumping the major version of the affected library. The > > pkg-config support is put properly in place, too, so if you haven't > > done that already, it's high time to begin convincing depdendent > > projects to start supporting shared FFmpeg. I've already begun > > working on fixing the main consumer of FFmpeg, MPlayer, to do that. > > Unless ffmpeg actually releases anything again I doubt that too many > projects will try to depend on an external shared lib whose API > stability window is a few weeks. Actually most of what we have in livna/rpmfusion does work with external shared libs. And the API stability window is rather closer to 3 years. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Fri Sep 19 18:09:15 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 19 Sep 2008 20:09:15 +0200 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <20080919170150.GB13838@victor.nirvana> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <20080919073401.GA26302@victor.nirvana> <1221811182.18327.1145.camel@beck.corsepiu.local> <20080919125922.GF24607@mokona.greysector.net> <20080919170150.GB13838@victor.nirvana> Message-ID: <20080919180915.GB27646@mokona.greysector.net> On Friday, 19 September 2008 at 19:01, Axel Thimm wrote: > On Fri, Sep 19, 2008 at 02:59:22PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > On Friday, 19 September 2008 at 09:59, Ralf Corsepius wrote: > > > On Fri, 2008-09-19 at 10:34 +0300, Axel Thimm wrote: > > [...] > > > > Just to quote one such example: ffmpeg is a fast moving target, and > > > > any project depending on the lib API is cutting a checkout, patching > > > > it a up and using it for its own purposes. Replacing these internal > > > > ffmpegs with a system ffmpeg is a nightmare or even impossible w/o > > > > rewriting the app interface to it. Given that ffmpeg and friends fall > > > > under the patent forbidden class we don't see that directly in Fedora, > > > > but this issue is still out there. > > > Well, ffmpeg is a special case wrt. many issues. If they were doing a > > > proper job, they would release properly versioned packages with properly > > > versioned APIs, which could be installed in parallel. > > > > They(we) don't have the manpower to do proper releases, but we do maintain > > properly versioned API/ABI. The position of a release manager for FFmpeg > > has been open for months. Many people complained, but nobody is willing > > to do the legwork. > > Actually I did, you can read it up at the archives, but the ffmpeg > devs didn't think this would be a good idea. The only positive > comments were from other distribution packagers that would have even > joined the release team taskforce, but w/o the developers' blessing > (and at the very least a "do it now" assignment) there wasn't much we > could do. I've just re-read that thread and AFAICT nobody said it wasn't a good idea. At least one developer offered to help. You even offered to prepare a release candidate but never did. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From a.badger at gmail.com Fri Sep 19 18:49:15 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 19 Sep 2008 11:49:15 -0700 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <20080919170933.GC13838@victor.nirvana> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <20080919073401.GA26302@victor.nirvana> <1221811182.18327.1145.camel@beck.corsepiu.local> <20080919170933.GC13838@victor.nirvana> Message-ID: <48D3F42B.6090002@gmail.com> Axel Thimm wrote: > On Fri, Sep 19, 2008 at 09:59:42AM +0200, Ralf Corsepius wrote: >>> I'd ask the question differently: If upstream saw itself forced to >>> duplicate/fork a lib how can you help making the forked bits back into >>> the original upstream. >> Then let me answer with my "developer's hat" on: >> >> The reason why such "forks" exist, often is disagreement between >> "upstream" and "fork" devs, because they disagree on APIs/usage and the >> like. >> >> Upstreams often accuse "fork devs" to be abusing their libraries/APIs >> (e.g. using undocumented internals). Conversely, "fork devs" often >> accuse "upstreams" not to listen to "users' demands". >> >> I.e. in many cases such conflicts will hardly be resolvable. > > Yes, and sometimes as in the case of ffmpeg and minilzo upstream even > wants you to take a snapshot, e.g. the "forking" is in their > consent. > Upstream is wrong. The consequences of their actions don't come back to haunt them, though, they come back to haunt us. If there's a security hole in their library snapshot, their answer can be "we fixed that two months ago. Why didn't you update?" Our answer would have to be: "We have an unfixed vulnerability in gnome-foo-player, toms-foo-player, and foo-plus-player. We are not able to fix these until we perform a port to an incompatible ffmpeg snapshot for the maintainers of the affected software." >>> Just to quote one such example: ffmpeg is a fast moving target, and >>> any project depending on the lib API is cutting a checkout, patching >>> it a up and using it for its own purposes. Replacing these internal >>> ffmpegs with a system ffmpeg is a nightmare or even impossible w/o >>> rewriting the app interface to it. Given that ffmpeg and friends fall >>> under the patent forbidden class we don't see that directly in Fedora, >>> but this issue is still out there. >> Well, ffmpeg is a special case wrt. many issues. If they were doing a >> proper job, they would release properly versioned packages with properly >> versioned APIs, which could be installed in parallel. > > Even if so, would Fedora package 20 different versions of ffmpeg to > satisfy the 20 different consumers? There wouldn't be any benefits to > an internal lib either: If there is a security flaw fixed in ffmpeg > 1004.0.1 the versions 900.x.y to 1003.x.y would be just as insecure as > external packages. > I think there is benefit: 1) If the library is statically linked in the application it's harder to find in a quick audit. 2) If the flaw affects a range of library versions (for instance, 899.x.y is unaffected), having them be packaged separately makes finding the affected versions and fixing them easier than finding out which versions of the private library each app has. Also, one of the goals of a distribution is to make programs and libraries work together. So the approach we'd likely want to take is choosing a few versions of the library that we could support (probably in conjunction with other distros) and then porting the apps to one of those library versions and getting upstreams to update their private libs to those versions since we were willing to do the port for them. >>> I'd recommend to soften this guideline to something as "the packager >>> should try hard to use system libs, and try to communicate the >>> benefits to upstream, but if there are reasons not to use system libs, >>> then he should document this in the specfile". >> I am not sure this is a good idea. I'd rather be stricter on this, >> because this would force devs to think about what they are doing and >> packagers think about the quality of what they are packaging. >> >> The unpleasant truth is: If a package bundles "modified libs/apps" from >> elsewhere, which can't be installed in parallel to the original >> libs/apps, this package's dev's are doing something wrong. > > The truth is that sometimes upstream makes some decisions, we can try > to forward our position, but upstream may ignore us or maybe will have > a good reason to counter our position (for ffmpeg and minilzo I believe > upstream is correct and we should be the ones revising the guidelines). > > That's why I suggest that the packager tries hard to do it in the > typical shared way, but if there are sane reasons to use internal libs > to not let the package dry out forever in some review queue like for > x11vnc. I am against this approach. But perhaps you'll have a useful counter to the points I raised. -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 Axel.Thimm at ATrpms.net Sat Sep 20 09:31:49 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 20 Sep 2008 12:31:49 +0300 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <20080919175537.GA27646@mokona.greysector.net> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <20080919073401.GA26302@victor.nirvana> <20080919125625.GE24607@mokona.greysector.net> <20080919165826.GA13838@victor.nirvana> <20080919175537.GA27646@mokona.greysector.net> Message-ID: <20080920093149.GA8806@victor.nirvana> On Fri, Sep 19, 2008 at 07:55:38PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > Note I mentioned the API, which is still changing on a regular > > basis. For ffmpeg it doesn't actually help that there are no releases > > ever either. > > API is not changing on a regular basis either. If there are incompatible > changes, they are accompanied by a major version bump. The soname changes are for the ABI changes, the API does change more than often. > > > without bumping the major version of the affected library. The > > > pkg-config support is put properly in place, too, so if you haven't > > > done that already, it's high time to begin convincing depdendent > > > projects to start supporting shared FFmpeg. I've already begun > > > working on fixing the main consumer of FFmpeg, MPlayer, to do that. > > > > Unless ffmpeg actually releases anything again I doubt that too many > > projects will try to depend on an external shared lib whose API > > stability window is a few weeks. > > Actually most of what we have in livna/rpmfusion does work with external > shared libs. And the API stability window is rather closer to 3 years. So the recent moving of the header files which is part of the API was three years ago and not that summer? Everything that requires an upstream's intervention to make a library link again is API breakage. If the consumer app FTBFS it's an API breakage. 3 years ago ffmpeg was a different project. Try building anything from livna against a one year old ffmpeg, you'll be surprised. :/ -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Sep 20 09:34:52 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 20 Sep 2008 12:34:52 +0300 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <20080919180915.GB27646@mokona.greysector.net> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <20080919073401.GA26302@victor.nirvana> <1221811182.18327.1145.camel@beck.corsepiu.local> <20080919125922.GF24607@mokona.greysector.net> <20080919170150.GB13838@victor.nirvana> <20080919180915.GB27646@mokona.greysector.net> Message-ID: <20080920093452.GB8806@victor.nirvana> On Fri, Sep 19, 2008 at 08:09:15PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Friday, 19 September 2008 at 19:01, Axel Thimm wrote: > > On Fri, Sep 19, 2008 at 02:59:22PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > > On Friday, 19 September 2008 at 09:59, Ralf Corsepius wrote: > > > > On Fri, 2008-09-19 at 10:34 +0300, Axel Thimm wrote: > > > [...] > > > > > Just to quote one such example: ffmpeg is a fast moving target, and > > > > > any project depending on the lib API is cutting a checkout, patching > > > > > it a up and using it for its own purposes. Replacing these internal > > > > > ffmpegs with a system ffmpeg is a nightmare or even impossible w/o > > > > > rewriting the app interface to it. Given that ffmpeg and friends fall > > > > > under the patent forbidden class we don't see that directly in Fedora, > > > > > but this issue is still out there. > > > > Well, ffmpeg is a special case wrt. many issues. If they were doing a > > > > proper job, they would release properly versioned packages with properly > > > > versioned APIs, which could be installed in parallel. > > > > > > They(we) don't have the manpower to do proper releases, but we do maintain > > > properly versioned API/ABI. The position of a release manager for FFmpeg > > > has been open for months. Many people complained, but nobody is willing > > > to do the legwork. > > > > Actually I did, you can read it up at the archives, but the ffmpeg > > devs didn't think this would be a good idea. The only positive > > comments were from other distribution packagers that would have even > > joined the release team taskforce, but w/o the developers' blessing > > (and at the very least a "do it now" assignment) there wasn't much we > > could do. > > I've just re-read that thread and AFAICT nobody said it wasn't a good idea. > At least one developer offered to help. You even offered to prepare a release > candidate but never did. Please check the "ranks" of the developers, some of them were even banned from ffmpeg, and how on earth could I prepare a release if the developers decide not to allow for scm access? No, the idea was silently dropped even though there were many downstreams ready to pick it up (not only me). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Sep 20 09:50:15 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 20 Sep 2008 12:50:15 +0300 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <48D3F42B.6090002@gmail.com> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <20080919073401.GA26302@victor.nirvana> <1221811182.18327.1145.camel@beck.corsepiu.local> <20080919170933.GC13838@victor.nirvana> <48D3F42B.6090002@gmail.com> Message-ID: <20080920095015.GC8806@victor.nirvana> On Fri, Sep 19, 2008 at 11:49:15AM -0700, Toshio Kuratomi wrote: > Axel Thimm wrote: > > On Fri, Sep 19, 2008 at 09:59:42AM +0200, Ralf Corsepius wrote: > >>> I'd ask the question differently: If upstream saw itself forced to > >>> duplicate/fork a lib how can you help making the forked bits back into > >>> the original upstream. > >> Then let me answer with my "developer's hat" on: > >> > >> The reason why such "forks" exist, often is disagreement between > >> "upstream" and "fork" devs, because they disagree on APIs/usage and the > >> like. > >> > >> Upstreams often accuse "fork devs" to be abusing their libraries/APIs > >> (e.g. using undocumented internals). Conversely, "fork devs" often > >> accuse "upstreams" not to listen to "users' demands". > >> > >> I.e. in many cases such conflicts will hardly be resolvable. > > > > Yes, and sometimes as in the case of ffmpeg and minilzo upstream even > > wants you to take a snapshot, e.g. the "forking" is in their > > consent. > > > Upstream is wrong. The consequences of their actions don't come back to > haunt them, though, they come back to haunt us. If there's a security > hole in their library snapshot, their answer can be "we fixed that two > months ago. Why didn't you update?" Our answer would have to be: "We > have an unfixed vulnerability in gnome-foo-player, toms-foo-player, and > foo-plus-player. We are not able to fix these until we perform a port > to an incompatible ffmpeg snapshot for the maintainers of the affected > software." Or backport to the versions needed. That's what RHEL does. And you now have the choice to o either not package it o package it as a shared external lib in its own package and have the same problem. Using "system libraries" just means blessing one version of the upstream project. Which if you want to follow security issues would need to be the latest and greatest. Which means that projects that have cut an older version of it will not run/build anymore. So at the end we just don't ship them, as we do for x11vnc. Is that the preferred outcome? > >>> Just to quote one such example: ffmpeg is a fast moving target, and > >>> any project depending on the lib API is cutting a checkout, patching > >>> it a up and using it for its own purposes. Replacing these internal > >>> ffmpegs with a system ffmpeg is a nightmare or even impossible w/o > >>> rewriting the app interface to it. Given that ffmpeg and friends fall > >>> under the patent forbidden class we don't see that directly in Fedora, > >>> but this issue is still out there. > >> Well, ffmpeg is a special case wrt. many issues. If they were doing a > >> proper job, they would release properly versioned packages with properly > >> versioned APIs, which could be installed in parallel. > > > > Even if so, would Fedora package 20 different versions of ffmpeg to > > satisfy the 20 different consumers? There wouldn't be any benefits to > > an internal lib either: If there is a security flaw fixed in ffmpeg > > 1004.0.1 the versions 900.x.y to 1003.x.y would be just as insecure as > > external packages. > > > > I think there is benefit: > 1) If the library is statically linked in the application it's harder to > find in a quick audit. > > 2) If the flaw affects a range of library versions (for instance, > 899.x.y is unaffected), having them be packaged separately makes finding > the affected versions and fixing them easier than finding out which > versions of the private library each app has. > > Also, one of the goals of a distribution is to make programs and > libraries work together. So the approach we'd likely want to take is > choosing a few versions of the library that we could support (probably > in conjunction with other distros) and then porting the apps to one of > those library versions and getting upstreams to update their private > libs to those versions since we were willing to do the port for them. Well, be my guest. Many have attempted to do so in some cases, but if upstream is *fast*, you will never catch up, and different distributions will chose different snapshots depending on the consumer apps they target, so coordinating will be more than difficult. But in principle I agree: If we could afford the manpower to keep all comsumers compatible to the latest stable release of a library that would be the ideal world. But we don't have that manpower, which is not just packaging, but true upstream work. A reality check shows that we even lack the definition of "latest stable upstream release" in some cases like ffmpeg. > >>> I'd recommend to soften this guideline to something as "the packager > >>> should try hard to use system libs, and try to communicate the > >>> benefits to upstream, but if there are reasons not to use system libs, > >>> then he should document this in the specfile". > >> I am not sure this is a good idea. I'd rather be stricter on this, > >> because this would force devs to think about what they are doing and > >> packagers think about the quality of what they are packaging. > >> > >> The unpleasant truth is: If a package bundles "modified libs/apps" from > >> elsewhere, which can't be installed in parallel to the original > >> libs/apps, this package's dev's are doing something wrong. > > > > The truth is that sometimes upstream makes some decisions, we can try > > to forward our position, but upstream may ignore us or maybe will have > > a good reason to counter our position (for ffmpeg and minilzo I believe > > upstream is correct and we should be the ones revising the guidelines). > > > > That's why I suggest that the packager tries hard to do it in the > > typical shared way, but if there are sane reasons to use internal libs > > to not let the package dry out forever in some review queue like for > > x11vnc. > > I am against this approach. But perhaps you'll have a useful counter to > the points I raised. The points you raised are nice in an ideal over manpowered world, but in reality we see packages stalling in review queues forever instead. Anyway, these were my 0.02. I'm not really seeing anyone from the FPC favouring this, even less willing to pick this up and driving this through, so I'll rather stick to agreeing to disagree. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dominik at greysector.net Sat Sep 20 10:09:18 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sat, 20 Sep 2008 12:09:18 +0200 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <20080920093149.GA8806@victor.nirvana> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <20080919073401.GA26302@victor.nirvana> <20080919125625.GE24607@mokona.greysector.net> <20080919165826.GA13838@victor.nirvana> <20080919175537.GA27646@mokona.greysector.net> <20080920093149.GA8806@victor.nirvana> Message-ID: <20080920100917.GB29021@mokona.greysector.net> On Saturday, 20 September 2008 at 11:31, Axel Thimm wrote: > On Fri, Sep 19, 2008 at 07:55:38PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > > Note I mentioned the API, which is still changing on a regular > > > basis. For ffmpeg it doesn't actually help that there are no releases > > > ever either. > > > > API is not changing on a regular basis either. If there are incompatible > > changes, they are accompanied by a major version bump. > > The soname changes are for the ABI changes, the API does change more > than often. > > > > > without bumping the major version of the affected library. The > > > > pkg-config support is put properly in place, too, so if you haven't > > > > done that already, it's high time to begin convincing depdendent > > > > projects to start supporting shared FFmpeg. I've already begun > > > > working on fixing the main consumer of FFmpeg, MPlayer, to do that. > > > > > > Unless ffmpeg actually releases anything again I doubt that too many > > > projects will try to depend on an external shared lib whose API > > > stability window is a few weeks. > > > > Actually most of what we have in livna/rpmfusion does work with external > > shared libs. And the API stability window is rather closer to 3 years. > > So the recent moving of the header files which is part of the API was > three years ago and not that summer? While I agree that moving headers around is an API change, it is far less problematic than changing function or structure names. It did bring a long needed consistency to header locations, after all. > Everything that requires an upstream's intervention to make a library > link again is API breakage. Linking was unaffected by that change. > If the consumer app FTBFS it's an API breakage. Well, it was trivial to fix. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Sat Sep 20 10:12:40 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sat, 20 Sep 2008 12:12:40 +0200 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <20080920093452.GB8806@victor.nirvana> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <20080919073401.GA26302@victor.nirvana> <1221811182.18327.1145.camel@beck.corsepiu.local> <20080919125922.GF24607@mokona.greysector.net> <20080919170150.GB13838@victor.nirvana> <20080919180915.GB27646@mokona.greysector.net> <20080920093452.GB8806@victor.nirvana> Message-ID: <20080920101240.GC29021@mokona.greysector.net> On Saturday, 20 September 2008 at 11:34, Axel Thimm wrote: > On Fri, Sep 19, 2008 at 08:09:15PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > On Friday, 19 September 2008 at 19:01, Axel Thimm wrote: > > > On Fri, Sep 19, 2008 at 02:59:22PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > > > On Friday, 19 September 2008 at 09:59, Ralf Corsepius wrote: > > > > > On Fri, 2008-09-19 at 10:34 +0300, Axel Thimm wrote: > > > > [...] > > > > > > Just to quote one such example: ffmpeg is a fast moving target, and > > > > > > any project depending on the lib API is cutting a checkout, patching > > > > > > it a up and using it for its own purposes. Replacing these internal > > > > > > ffmpegs with a system ffmpeg is a nightmare or even impossible w/o > > > > > > rewriting the app interface to it. Given that ffmpeg and friends fall > > > > > > under the patent forbidden class we don't see that directly in Fedora, > > > > > > but this issue is still out there. > > > > > Well, ffmpeg is a special case wrt. many issues. If they were doing a > > > > > proper job, they would release properly versioned packages with properly > > > > > versioned APIs, which could be installed in parallel. > > > > > > > > They(we) don't have the manpower to do proper releases, but we do maintain > > > > properly versioned API/ABI. The position of a release manager for FFmpeg > > > > has been open for months. Many people complained, but nobody is willing > > > > to do the legwork. > > > > > > Actually I did, you can read it up at the archives, but the ffmpeg > > > devs didn't think this would be a good idea. The only positive > > > comments were from other distribution packagers that would have even > > > joined the release team taskforce, but w/o the developers' blessing > > > (and at the very least a "do it now" assignment) there wasn't much we > > > could do. > > > > I've just re-read that thread and AFAICT nobody said it wasn't a good idea. > > At least one developer offered to help. You even offered to prepare a release > > candidate but never did. > > Please check the "ranks" of the developers, some of them were even > banned from ffmpeg, I have no idea what you're talking about. Who was banned, exactly? > and how on earth could I prepare a release if the > developers decide not to allow for scm access? I never saw you asking for that. Regards, R. PS. Feel free to continue off-list, this is getting off-topic. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From a.badger at gmail.com Sat Sep 20 19:26:53 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 20 Sep 2008 12:26:53 -0700 Subject: [Fedora-packaging] Re: Use of Internal Libraries In-Reply-To: <20080920095015.GC8806@victor.nirvana> References: <1221745310.3446.13.camel@fantail.jnet.net.nz> <20080919073401.GA26302@victor.nirvana> <1221811182.18327.1145.camel@beck.corsepiu.local> <20080919170933.GC13838@victor.nirvana> <48D3F42B.6090002@gmail.com> <20080920095015.GC8806@victor.nirvana> Message-ID: <48D54E7D.7070004@gmail.com> Axel Thimm wrote: > On Fri, Sep 19, 2008 at 11:49:15AM -0700, Toshio Kuratomi wrote: >> Axel Thimm wrote: >>> On Fri, Sep 19, 2008 at 09:59:42AM +0200, Ralf Corsepius wrote: >>>>> I'd ask the question differently: If upstream saw itself forced to >>>>> duplicate/fork a lib how can you help making the forked bits back into >>>>> the original upstream. >>>> Then let me answer with my "developer's hat" on: >>>> >>>> The reason why such "forks" exist, often is disagreement between >>>> "upstream" and "fork" devs, because they disagree on APIs/usage and the >>>> like. >>>> >>>> Upstreams often accuse "fork devs" to be abusing their libraries/APIs >>>> (e.g. using undocumented internals). Conversely, "fork devs" often >>>> accuse "upstreams" not to listen to "users' demands". >>>> >>>> I.e. in many cases such conflicts will hardly be resolvable. >>> Yes, and sometimes as in the case of ffmpeg and minilzo upstream even >>> wants you to take a snapshot, e.g. the "forking" is in their >>> consent. >>> >> Upstream is wrong. The consequences of their actions don't come back to >> haunt them, though, they come back to haunt us. If there's a security >> hole in their library snapshot, their answer can be "we fixed that two >> months ago. Why didn't you update?" Our answer would have to be: "We >> have an unfixed vulnerability in gnome-foo-player, toms-foo-player, and >> foo-plus-player. We are not able to fix these until we perform a port >> to an incompatible ffmpeg snapshot for the maintainers of the affected >> software." > > Or backport to the versions needed. That's what RHEL does. And you now > have the choice to > > o either not package it This one's not true. We've already released it. If we remove gnome-foo-player, toms-foo-player, and foo-plus-player from the repository, all we're doing is keeping future people from getting the software. We aren't helping the people who have already received the software. > o package it as a shared external lib in its own package and have the > same problem. > > Using "system libraries" just means blessing one version of the > upstream project. Which if you want to follow security issues would > need to be the latest and greatest. Which means that projects that > have cut an older version of it will not run/build anymore. > You didn't address the benefits that I outlined below: >> 1) If the library is statically linked in the application it's harder to >> find in a quick audit. >> >> 2) If the flaw affects a range of library versions (for instance, >> 899.x.y is unaffected), having them be packaged separately makes finding >> the affected versions and fixing them easier than finding out which >> versions of the private library each app has. > So at the end we just don't ship them, as we do for x11vnc. Is that > the preferred outcome? > It might be. If we don't have the manpower to keep things secure then we have no business inflicting them upon our users. >>>>> Just to quote one such example: ffmpeg is a fast moving target, and >>>>> any project depending on the lib API is cutting a checkout, patching >>>>> it a up and using it for its own purposes. Replacing these internal >>>>> ffmpegs with a system ffmpeg is a nightmare or even impossible w/o >>>>> rewriting the app interface to it. Given that ffmpeg and friends fall >>>>> under the patent forbidden class we don't see that directly in Fedora, >>>>> but this issue is still out there. >>>> Well, ffmpeg is a special case wrt. many issues. If they were doing a >>>> proper job, they would release properly versioned packages with properly >>>> versioned APIs, which could be installed in parallel. >>> Even if so, would Fedora package 20 different versions of ffmpeg to >>> satisfy the 20 different consumers? There wouldn't be any benefits to >>> an internal lib either: If there is a security flaw fixed in ffmpeg >>> 1004.0.1 the versions 900.x.y to 1003.x.y would be just as insecure as >>> external packages. >>> >> I think there is benefit: >> 1) If the library is statically linked in the application it's harder to >> find in a quick audit. >> >> 2) If the flaw affects a range of library versions (for instance, >> 899.x.y is unaffected), having them be packaged separately makes finding >> the affected versions and fixing them easier than finding out which >> versions of the private library each app has. >> >> Also, one of the goals of a distribution is to make programs and >> libraries work together. So the approach we'd likely want to take is >> choosing a few versions of the library that we could support (probably >> in conjunction with other distros) and then porting the apps to one of >> those library versions and getting upstreams to update their private >> libs to those versions since we were willing to do the port for them. > > Well, be my guest. Many have attempted to do so in some cases, but if > upstream is *fast*, you will never catch up, and different > distributions will chose different snapshots depending on the consumer > apps they target, so coordinating will be more than difficult. > > But in principle I agree: If we could afford the manpower to keep all > comsumers compatible to the latest stable release of a library that > would be the ideal world. But we don't have that manpower, which is > not just packaging, but true upstream work. > > A reality check shows that we even lack the definition of "latest > stable upstream release" in some cases like ffmpeg. > Re-read what I wrote. I'm saying "choosing a few versions of the library that we could support (probably in conjunction with other distros) and then porting the apps to one of those library versions". If there's a set of packages that we care enough about that use a library which can't commit to an API for more than a month then we and other distros have to care about the situation and fix it between ourselves. And yes, this is programming that I'm talking about, not just packaging. >>>>> I'd recommend to soften this guideline to something as "the packager >>>>> should try hard to use system libs, and try to communicate the >>>>> benefits to upstream, but if there are reasons not to use system libs, >>>>> then he should document this in the specfile". >>>> I am not sure this is a good idea. I'd rather be stricter on this, >>>> because this would force devs to think about what they are doing and >>>> packagers think about the quality of what they are packaging. >>>> >>>> The unpleasant truth is: If a package bundles "modified libs/apps" from >>>> elsewhere, which can't be installed in parallel to the original >>>> libs/apps, this package's dev's are doing something wrong. >>> The truth is that sometimes upstream makes some decisions, we can try >>> to forward our position, but upstream may ignore us or maybe will have >>> a good reason to counter our position (for ffmpeg and minilzo I believe >>> upstream is correct and we should be the ones revising the guidelines). >>> >>> That's why I suggest that the packager tries hard to do it in the >>> typical shared way, but if there are sane reasons to use internal libs >>> to not let the package dry out forever in some review queue like for >>> x11vnc. >> I am against this approach. But perhaps you'll have a useful counter to >> the points I raised. > > The points you raised are nice in an ideal over manpowered world, but > in reality we see packages stalling in review queues forever instead. > > Anyway, these were my 0.02. I'm not really seeing anyone from the FPC > favouring this, even less willing to pick this up and driving this > through, so I'll rather stick to agreeing to disagree. :) > heh. Okay. :-) -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 ksedgwic at bonsai.com Sun Sep 21 00:29:34 2008 From: ksedgwic at bonsai.com (Ken Sedgwick) Date: Sat, 20 Sep 2008 17:29:34 -0700 Subject: [Fedora-packaging] OpenSuse / Fedora Packaging Compatibility? Message-ID: <48D5956E.6090708@bonsai.com> Greetings, The ACE+TAO dev team currently has two different spec files for generating RPMs. One has been oriented towards Fedora/Redhat build environments and the other is used in the OpenSuse build environment. The temptation is to make them the same (they are pretty similar). Are there any unreconcilable differences between OpenSuse packaging and Fedora Packaging? More importantly, are there any examples of packages which currently use the same spec file (perhaps with platform conditional blocks) for both distributions? We'd sure love to use them as an example ... Many thanks in advance! Ken -- Ken Sedgwick Bonsai Software, Inc. http://www.bonsai.com/ken/ (510) 610-4162 ken+5a4 at bonsai.com Public Key: http://www.bonsai.com/ken/ken.asc GPG Fingerprint: 851E 3B07 E586 0843 9434 5CC7 4033 3B9B 3F3F 9640 From wolters.liste at gmx.net Sun Sep 21 02:59:25 2008 From: wolters.liste at gmx.net (Roland Wolters) Date: Sun, 21 Sep 2008 04:59:25 +0200 Subject: [Fedora-packaging] OpenSuse / Fedora Packaging Compatibility? In-Reply-To: <48D5956E.6090708@bonsai.com> References: <48D5956E.6090708@bonsai.com> Message-ID: <200809210459.31260.wolters.liste@gmx.net> Hi Ken, > More importantly, are there any examples of packages which currently use > the same spec file (perhaps with platform conditional blocks) for both > distributions? We'd sure love to use them as an example ... > The OpenSuse build service is full of specs which are used for building both packages. The main problems are due to different names for some packages I think, but these are handled by if-else statements which automatically check the target distribution. I think for independent software providers the best way is to simply set up a OpenSuse build service on your servers and build your packages there. It will produce packages and native repositories for several distributions with not too much overhead. Regards, Roland -- One must have chaos in one to give birth to a dancing star. -- Zarathustra/Nietzsche -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From Axel.Thimm at ATrpms.net Sun Sep 21 04:17:11 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 21 Sep 2008 07:17:11 +0300 Subject: [Fedora-packaging] Re: OpenSuse / Fedora Packaging Compatibility? In-Reply-To: <48D5956E.6090708@bonsai.com> References: <48D5956E.6090708@bonsai.com> Message-ID: <20080921041711.GC26812@victor.nirvana> On Sat, Sep 20, 2008 at 05:29:34PM -0700, Ken Sedgwick wrote: > Greetings, > > The ACE+TAO dev team currently has two different spec files for > generating RPMs. One has been oriented towards Fedora/Redhat build > environments and the other is used in the OpenSuse build environment. > > The temptation is to make them the same (they are pretty similar). > > Are there any unreconcilable differences between OpenSuse packaging and > Fedora Packaging? > > More importantly, are there any examples of packages which currently use > the same spec file (perhaps with platform conditional blocks) for both > distributions? We'd sure love to use them as an example ... Ideally the major rpm distros will one day try to create a common ground on this, mainly in the naming area. But it will be a Herculian task as at least one distro would have to rename its packages over the EOL times of its products. Even if all parties agree it will not happen tomorrow. For today you need to either conditionalize the specfile, maintain separate specfiles or create dummy wrapper packages for compatibility (say you need foo-devel or foo-dev, just depend on say the former and on suse create a wrapper foo-devel that just depends on foo-dev or the other way around if you prefer the suse style). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Sun Sep 21 07:54:33 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 21 Sep 2008 09:54:33 +0200 Subject: [Fedora-packaging] Re: OpenSuse / Fedora Packaging Compatibility? In-Reply-To: <20080921041711.GC26812@victor.nirvana> References: <48D5956E.6090708@bonsai.com> <20080921041711.GC26812@victor.nirvana> Message-ID: <1221983673.9766.7.camel@rousalka.okg> Le dimanche 21 septembre 2008 ? 07:17 +0300, Axel Thimm a ?crit : > For today you need to either conditionalize the specfile, maintain > separate specfiles or create dummy wrapper packages for compatibility > (say you need foo-devel or foo-dev, just depend on say the former and > on suse create a wrapper foo-devel that just depends on foo-dev or the > other way around if you prefer the suse style). It's usually fairly easy to workaround distro package naming differences without complex conditionnals by using file dependencies. (Some people will try to remove them just because some tools may be slower processing file deps. Well, duh, it's an old rpm feature, it works on every distro, it's simple ? conditionnals and other complex workarounds are just not worth it IMHO. KISS) -- 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 skvidal at fedoraproject.org Mon Sep 22 00:50:18 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Sun, 21 Sep 2008 20:50:18 -0400 Subject: [Fedora-packaging] Re: OpenSuse / Fedora Packaging Compatibility? In-Reply-To: <1221983673.9766.7.camel@rousalka.okg> References: <48D5956E.6090708@bonsai.com> <20080921041711.GC26812@victor.nirvana> <1221983673.9766.7.camel@rousalka.okg> Message-ID: <1222044618.12513.1.camel@rosebud> On Sun, 2008-09-21 at 09:54 +0200, Nicolas Mailhot wrote: > Le dimanche 21 septembre 2008 ? 07:17 +0300, Axel Thimm a ?crit : > > > For today you need to either conditionalize the specfile, maintain > > separate specfiles or create dummy wrapper packages for compatibility > > (say you need foo-devel or foo-dev, just depend on say the former and > > on suse create a wrapper foo-devel that just depends on foo-dev or the > > other way around if you prefer the suse style). > > It's usually fairly easy to workaround distro package naming differences > without complex conditionnals by using file dependencies. (Some people > will try to remove them just because some tools may be slower processing > file deps. Well, duh, it's an old rpm feature, it works on every distro, > it's simple ? conditionnals and other complex workarounds are just not > worth it IMHO. KISS) > If you have enough files EVERY tool is slower processing them. When we go from 1.5billion files to search through to 3.2billion files - it takes steadily longer. -sv From fkooman at tuxed.net Mon Sep 22 14:58:08 2008 From: fkooman at tuxed.net (=?ISO-8859-1?Q?Fran=E7ois_Kooman?=) Date: Mon, 22 Sep 2008 16:58:08 +0200 Subject: [Fedora-packaging] %doc and %attr problems Message-ID: <48D7B280.6040307@tuxed.net> Hi, I'm trying to package globalplatform and gpshell but have some problems now with packaging some of the example scripts included. They are chmodded 755 instead of the wanted 644 so I tried to use this in the spec file: %attr(0644,root,root)%doc README COPYING.LESSER *.txt But this will result in the /usr/share/doc/gpshell-1.4.2/ also being chmodded 644 which will make rpmlint (correctly) complain: gpshell.x86_64: E: non-standard-dir-perm /usr/share/doc/gpshell-1.4.2 0644 I tried using: %doc %attr(0644,root,root)%doc README LICENSE.LESSER *.txt but that doesn't seem to help much. I've already submitted this issue upstream and the maintainer said that he'll fix it for the next release in a few months... How can I deal with it best for now? Regards, Fran?ois From paul at city-fan.org Mon Sep 22 15:03:30 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 22 Sep 2008 16:03:30 +0100 Subject: [Fedora-packaging] %doc and %attr problems In-Reply-To: <48D7B280.6040307@tuxed.net> References: <48D7B280.6040307@tuxed.net> Message-ID: <48D7B3C2.3030200@city-fan.org> Fran?ois Kooman wrote: > Hi, > > I'm trying to package globalplatform and gpshell but have some problems > now with packaging some of the example scripts included. They are > chmodded 755 instead of the wanted 644 so I tried to use this in the > spec file: > > %attr(0644,root,root)%doc README COPYING.LESSER *.txt > > But this will result in the /usr/share/doc/gpshell-1.4.2/ also being > chmodded 644 which will make rpmlint (correctly) complain: > > gpshell.x86_64: E: non-standard-dir-perm /usr/share/doc/gpshell-1.4.2 0644 > > I tried using: > > %doc > %attr(0644,root,root)%doc README LICENSE.LESSER *.txt > > but that doesn't seem to help much. > > I've already submitted this issue upstream and the maintainer said that > he'll fix it for the next release in a few months... > > How can I deal with it best for now? chmod the files in %prep Paul. From dominik at greysector.net Mon Sep 22 15:18:12 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 22 Sep 2008 17:18:12 +0200 Subject: [Fedora-packaging] %doc and %attr problems In-Reply-To: <48D7B280.6040307@tuxed.net> References: <48D7B280.6040307@tuxed.net> Message-ID: <20080922151812.GA11060@mokona.greysector.net> On Monday, 22 September 2008 at 16:58, Fran?ois Kooman wrote: > Hi, > > I'm trying to package globalplatform and gpshell but have some problems > now with packaging some of the example scripts included. They are > chmodded 755 instead of the wanted 644 so I tried to use this in the > spec file: > > %attr(0644,root,root)%doc README COPYING.LESSER *.txt > > But this will result in the /usr/share/doc/gpshell-1.4.2/ also being > chmodded 644 which will make rpmlint (correctly) complain: > > gpshell.x86_64: E: non-standard-dir-perm /usr/share/doc/gpshell-1.4.2 0644 Try: %attr(644,root,root,755) %doc README ... Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From bruno at wolff.to Mon Sep 22 16:33:16 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 22 Sep 2008 11:33:16 -0500 Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib Message-ID: <20080922163316.GA27102@wolff.to> 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. From skvidal at fedoraproject.org Mon Sep 22 16:40:10 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 22 Sep 2008 12:40:10 -0400 Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: <20080922163316.GA27102@wolff.to> References: <20080922163316.GA27102@wolff.to> Message-ID: <1222101610.12513.73.camel@rosebud> 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. -sv From bruno at wolff.to Mon Sep 22 18:26:25 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 22 Sep 2008 13:26:25 -0500 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: <20080922182625.GA13884@wolff.to> On Mon, Sep 22, 2008 at 12:40:10 -0400, 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. It requires a specific lib file that is different between the i386 and x86_64 versions of zlib-devel. However the different files are not "provide"d by either zlib so you can't find the dependceny without using the file lists. There are over 700 -devel rpms in Fedora where the i386 version of the package doesn't "provide" anything not "provide"d by the x86_64 version. presumably most of these put their libs in different places and they get pulled in because yum (or whatever) ends up looking through the file lists. (There are also a lot (nearly 3000) of the i386 rpms in fedora that "provide" something not provided by any x86_64 packages, but are not included in the normal x86_64 rawhide repo. This seems odd, but not strictly an error. My supposition is that a lot of these packages have a gratiutious (x86-32) provides, but I really haven't look into it.) In a couple of cases I looked at things are even more broken. For example nspr-devel is needed by nss-devel and there do appear to be differences between the i386 and x86_64 libraries, yet the requires for nss-devel to not require anything that is not provided by the x86_64 version of nspr-devel. I am not 100% sure this is broken, but it looks wrong to me. [root at cerberus Packages]# rpm -q --provides -p nspr-devel-4.7.1-2.fc10.i386.rpm nspr-devel = 4.7.1-2.fc10 [root at cerberus Packages]# rpm -q --requires -p nss-devel-3.12.1.1-2.fc10.i386.rpm /bin/sh libfreebl3.so libnss3.so libnssckbi.so libnssdbm3.so libnsspem.so libnssutil3.so libsmime3.so libsoftokn3.so libssl3.so nspr-devel >= 4.7 nss = 3.12.1.1-2.fc10 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 [root at cerberus Packages]# rpm -qlp ../../x86_64/Packages/nspr-devel-4.7.1-2.fc10.x86_64.rpm /usr/bin/nspr-config /usr/include/nspr4 /usr/include/nspr4/nspr.h /usr/include/nspr4/obsolete /usr/include/nspr4/obsolete/pralarm.h /usr/include/nspr4/obsolete/probslet.h /usr/include/nspr4/obsolete/protypes.h /usr/include/nspr4/obsolete/prsem.h /usr/include/nspr4/plarena.h /usr/include/nspr4/plarenas.h /usr/include/nspr4/plbase64.h /usr/include/nspr4/plerror.h /usr/include/nspr4/plgetopt.h /usr/include/nspr4/plhash.h /usr/include/nspr4/plresolv.h /usr/include/nspr4/plstr.h /usr/include/nspr4/pratom.h /usr/include/nspr4/prbit.h /usr/include/nspr4/prclist.h /usr/include/nspr4/prcmon.h /usr/include/nspr4/prcountr.h /usr/include/nspr4/prcpucfg.h /usr/include/nspr4/prcvar.h /usr/include/nspr4/prdtoa.h /usr/include/nspr4/prenv.h /usr/include/nspr4/prerr.h /usr/include/nspr4/prerror.h /usr/include/nspr4/prinet.h /usr/include/nspr4/prinit.h /usr/include/nspr4/prinrval.h /usr/include/nspr4/prio.h /usr/include/nspr4/pripcsem.h /usr/include/nspr4/private /usr/include/nspr4/private/pprio.h /usr/include/nspr4/private/pprthred.h /usr/include/nspr4/private/prpriv.h /usr/include/nspr4/prlink.h /usr/include/nspr4/prlock.h /usr/include/nspr4/prlog.h /usr/include/nspr4/prlong.h /usr/include/nspr4/prmem.h /usr/include/nspr4/prmon.h /usr/include/nspr4/prmwait.h /usr/include/nspr4/prnetdb.h /usr/include/nspr4/prolock.h /usr/include/nspr4/prpdce.h /usr/include/nspr4/prprf.h /usr/include/nspr4/prproces.h /usr/include/nspr4/prrng.h /usr/include/nspr4/prrwlock.h /usr/include/nspr4/prshm.h /usr/include/nspr4/prshma.h /usr/include/nspr4/prsystem.h /usr/include/nspr4/prthread.h /usr/include/nspr4/prtime.h /usr/include/nspr4/prtpool.h /usr/include/nspr4/prtrace.h /usr/include/nspr4/prtypes.h /usr/include/nspr4/prvrsion.h /usr/include/nspr4/prwin16.h /usr/lib64/libnspr4.so /usr/lib64/libplc4.so /usr/lib64/libplds4.so /usr/lib64/pkgconfig/nspr.pc From skvidal at fedoraproject.org Mon Sep 22 18:29:05 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 22 Sep 2008 14:29:05 -0400 Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: <20080922182625.GA13884@wolff.to> References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> Message-ID: <1222108145.12513.78.camel@rosebud> On Mon, 2008-09-22 at 13:26 -0500, Bruno Wolff III wrote: > On Mon, Sep 22, 2008 at 12:40:10 -0400, > 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. > > It requires a specific lib file that is different between the i386 and x86_64 > versions of zlib-devel. However the different files are not "provide"d by > either zlib so you can't find the dependceny without using the file lists. > > There are over 700 -devel rpms in Fedora where the i386 version of the > package doesn't "provide" anything not "provide"d by the x86_64 version. > presumably most of these put their libs in different places and they > get pulled in because yum (or whatever) ends up looking through the file > lists. > Yes - that's a file dep - that's how they work. I'm not a big fan of them, either. If you'd like to lead a crusade to get rid of them I'll happily follow but seeing as I've tried it twice I'm not going to lead another one :) -sv From tcallawa at redhat.com Mon Sep 22 19:27:43 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 22 Sep 2008 15:27:43 -0400 Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: <1222108145.12513.78.camel@rosebud> References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> Message-ID: <1222111663.3555.78.camel@localhost.localdomain> On Mon, 2008-09-22 at 14:29 -0400, seth vidal wrote: > If you'd like to lead a crusade to get rid of them I'll happily follow > but seeing as I've tried it twice I'm not going to lead another one :) In this case, wouldn't it be something that we could use the new rpm isa-provides for? Requires: zlib-devel(x86-32) Of course, that doesn't seem to be working right now in rawhide... but I think all we'd need to do is rebuild zlib. ~spot From skvidal at fedoraproject.org Mon Sep 22 19:30:16 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 22 Sep 2008 15:30:16 -0400 Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: <1222111663.3555.78.camel@localhost.localdomain> References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> <1222111663.3555.78.camel@localhost.localdomain> Message-ID: <1222111816.12513.85.camel@rosebud> On Mon, 2008-09-22 at 15:27 -0400, Tom "spot" Callaway wrote: > On Mon, 2008-09-22 at 14:29 -0400, seth vidal wrote: > > > If you'd like to lead a crusade to get rid of them I'll happily follow > > but seeing as I've tried it twice I'm not going to lead another one :) > > In this case, wouldn't it be something that we could use the new rpm > isa-provides for? > > Requires: zlib-devel(x86-32) > > Of course, that doesn't seem to be working right now in rawhide... but I > think all we'd need to do is rebuild zlib. > indeed - except we'd have to make that work per-arch b/c zlib-devel (x86-32) isn't going to work so well on ppc64 -sv From skvidal at fedoraproject.org Mon Sep 22 19:47:51 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 22 Sep 2008 15:47:51 -0400 Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: <20080922194533.GA21219@wolff.to> References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> <20080922194533.GA21219@wolff.to> Message-ID: <1222112871.12513.89.camel@rosebud> On Mon, 2008-09-22 at 14:45 -0500, Bruno Wolff III wrote: > Right now I am cla only and not in a good position to lead packaging > initiatives. (I want to eventually be a packager, but the code I have a > particular interest in packaging is written in java which I not that > familiar with and needs to have have copyrighted images scrubbed and > will still need to be looked at further because it is based on a boardgame.) > > I don't think finding references to files and changing the providing packages > to explicitly provide them would be all that hard. Changing the pkgs AFTER the fact? -sv From bruno at wolff.to Mon Sep 22 19:45:33 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 22 Sep 2008 14:45:33 -0500 Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: <1222108145.12513.78.camel@rosebud> References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> Message-ID: <20080922194533.GA21219@wolff.to> On Mon, Sep 22, 2008 at 14:29:05 -0400, seth vidal wrote: > > Yes - that's a file dep - that's how they work. I'm not a big fan of > them, either. > > If you'd like to lead a crusade to get rid of them I'll happily follow > but seeing as I've tried it twice I'm not going to lead another one :) Right now I am cla only and not in a good position to lead packaging initiatives. (I want to eventually be a packager, but the code I have a particular interest in packaging is written in java which I not that familiar with and needs to have have copyrighted images scrubbed and will still need to be looked at further because it is based on a boardgame.) I don't think finding references to files and changing the providing packages to explicitly provide them would be all that hard. While this would speed up yum in some cases I am not sure this is really the right approach. Someone really needs to think about how provides/requires should be used and how multilib will interact with this. I suspect this wouldn't be a high priority initiative. The benefits would be faster yum and rpm (since filelist checks for requirements could be skipped) and perhaps a better way to figure out which i386 packages should be included in the x86_64 repo. From bruno at wolff.to Mon Sep 22 20:12:19 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 22 Sep 2008 15:12:19 -0500 Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: <1222112871.12513.89.camel@rosebud> References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> <20080922194533.GA21219@wolff.to> <1222112871.12513.89.camel@rosebud> Message-ID: <20080922201219.GA28441@wolff.to> On Mon, Sep 22, 2008 at 15:47:51 -0400, seth vidal wrote: > On Mon, 2008-09-22 at 14:45 -0500, Bruno Wolff III wrote: > > > Right now I am cla only and not in a good position to lead packaging > > initiatives. (I want to eventually be a packager, but the code I have a > > particular interest in packaging is written in java which I not that > > familiar with and needs to have have copyrighted images scrubbed and > > will still need to be looked at further because it is based on a boardgame.) > > > > I don't think finding references to files and changing the providing packages > > to explicitly provide them would be all that hard. > > > Changing the pkgs AFTER the fact? This would require new releases. Only the providing packages would need to be changed to explicitly provide the capability corresponding to the file. It's a LOT of grunt work, but not hard. This wouldn't break anything. It doesn't even all need to be done at the same time. It would increase the list of capabilities a couple of % (based on roughly 50000 capabilities in a repo and on the order of 1000 packages that likely implicitly provide files as capabilities). This wouldn't stop people from making new ones. To do that you'd need to change yum/rpm to not work if they did. That would be a big change that you'd want to do for a Fedora release. However, I suspect that putting in all of those provides is something that the project would want to undo later. (After thinking about about how it would really be best to do things something other than file names might end up being used.) So I doubt it is worth the work to do this. (At least not before long term goals are set.) If the (x86-32) stuff is relatively automatic it might be worth getting a list of packages which would take advantage of this and get them rebuilt. I don't know much about that feature, just waht Spot referred to and that I saw a lot of capabilities with the string '(x86-32)' in them. Cleaning up packages to make reference to the x86-32 capabilities might be harder. From pmatilai at laiskiainen.org Tue Sep 23 06:00:39 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 23 Sep 2008 09:00:39 +0300 (EEST) Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: <1222111816.12513.85.camel@rosebud> References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> <1222111663.3555.78.camel@localhost.localdomain> <1222111816.12513.85.camel@rosebud> Message-ID: On Mon, 22 Sep 2008, seth vidal wrote: > On Mon, 2008-09-22 at 15:27 -0400, Tom "spot" Callaway wrote: >> On Mon, 2008-09-22 at 14:29 -0400, seth vidal wrote: >> >>> If you'd like to lead a crusade to get rid of them I'll happily follow >>> but seeing as I've tried it twice I'm not going to lead another one :) >> >> In this case, wouldn't it be something that we could use the new rpm >> isa-provides for? >> >> Requires: zlib-devel(x86-32) >> >> Of course, that doesn't seem to be working right now in rawhide... but I >> think all we'd need to do is rebuild zlib. >> > > indeed - except we'd have to make that work per-arch b/c zlib-devel > (x86-32) isn't going to work so well on ppc64 Well obviously you don't want to use literal, hardcoded "Requires: zlib-devel(x86-32)" in the spec, but this instead: Requires: zlib-devel%{?_isa} That gets expanded at build time to the ISA name of the package being built. And it's backwards compatible in the sense that if built with older rpm, you get just "Requires: zlib-devel" like before. And yes this is one of the major cases for which the whole ISA-thingie was invented. What's missing is the mass-rebuild to make the ISA-provides globally available, and FPC guidelines on using them. - Panu - From pmatilai at laiskiainen.org Tue Sep 23 06:18:49 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 23 Sep 2008 09:18:49 +0300 (EEST) Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: <20080922201219.GA28441@wolff.to> References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> <20080922194533.GA21219@wolff.to> <1222112871.12513.89.camel@rosebud> <20080922201219.GA28441@wolff.to> Message-ID: On Mon, 22 Sep 2008, Bruno Wolff III wrote: > On Mon, Sep 22, 2008 at 15:47:51 -0400, > seth vidal wrote: >> On Mon, 2008-09-22 at 14:45 -0500, Bruno Wolff III wrote: >> >>> Right now I am cla only and not in a good position to lead packaging >>> initiatives. (I want to eventually be a packager, but the code I have a >>> particular interest in packaging is written in java which I not that >>> familiar with and needs to have have copyrighted images scrubbed and >>> will still need to be looked at further because it is based on a boardgame.) >>> >>> I don't think finding references to files and changing the providing packages >>> to explicitly provide them would be all that hard. >> >> >> Changing the pkgs AFTER the fact? > > This would require new releases. Only the providing packages would need to > be changed to explicitly provide the capability corresponding to the file. > It's a LOT of grunt work, but not hard. This wouldn't break anything. > It doesn't even all need to be done at the same time. It would increase the > list of capabilities a couple of % (based on roughly 50000 capabilities in a > repo and on the order of 1000 packages that likely implicitly provide files as > capabilities). This wouldn't stop people from making new ones. To do that > you'd need to change yum/rpm to not work if they did. That would be a big > change that you'd want to do for a Fedora release. > > However, I suspect that putting in all of those provides is something that > the project would want to undo later. (After thinking about about how > it would really be best to do things something other than file names might > end up being used.) So I doubt it is worth the work to do this. (At least > not before long term goals are set.) > > If the (x86-32) stuff is relatively automatic it might be worth getting > a list of packages which would take advantage of this and get them > rebuilt. I don't know much about that feature, just waht Spot referred > to and that I saw a lot of capabilities with the string '(x86-32)' in > them. Cleaning up packages to make reference to the x86-32 capabilities > might be harder. The new rpm in rawhide adds ISA provides (ie the (x86-32) stuff") automatically for all non-noarch packages (including subpackages), all that's needed is rebuild. So every package rebuilt since rpm 4.5.90.x landed in rawhide already has them. The main use-cases for this feature are: a) -devel package dependencies on other -devel packages b) BuildRequires c) manual dependencies for plugins and such Due to a) and b), almost everything in the distro could benefit from using them. For one, if all the relevant BuildRequires: are made to use ISA-provides instead of just the package name, we wouldn't need the monster exclude-lines in mock configs for multilib-capable systems to guarantee sane results. - Panu - From rc040203 at freenet.de Tue Sep 23 06:26:46 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 23 Sep 2008 08:26:46 +0200 Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> <20080922194533.GA21219@wolff.to> <1222112871.12513.89.camel@rosebud> <20080922201219.GA28441@wolff.to> Message-ID: <1222151206.3564.30.camel@beck.corsepiu.local> On Tue, 2008-09-23 at 09:18 +0300, Panu Matilainen wrote: > The new rpm in rawhide adds ISA provides (ie the (x86-32) stuff") > automatically for all non-noarch packages (including subpackages), all > that's needed is rebuild. So every package rebuilt since rpm 4.5.90.x > landed in rawhide already has them. > > The main use-cases for this feature are: > a) -devel package dependencies on other -devel packages > b) BuildRequires > c) manual dependencies for plugins and such Which kinds of problems does this solve? So far I don't see any. Conversely, AFAIU all this does, is to add more incompatibilities, more rpmdb entries, all for information which already is hidden somewhere else. Ralf From pmatilai at laiskiainen.org Tue Sep 23 06:49:22 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 23 Sep 2008 09:49:22 +0300 (EEST) Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: <1222151206.3564.30.camel@beck.corsepiu.local> References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> <20080922194533.GA21219@wolff.to> <1222112871.12513.89.camel@rosebud> <20080922201219.GA28441@wolff.to> <1222151206.3564.30.camel@beck.corsepiu.local> Message-ID: On Tue, 23 Sep 2008, Ralf Corsepius wrote: > On Tue, 2008-09-23 at 09:18 +0300, Panu Matilainen wrote: >> The new rpm in rawhide adds ISA provides (ie the (x86-32) stuff") >> automatically for all non-noarch packages (including subpackages), all >> that's needed is rebuild. So every package rebuilt since rpm 4.5.90.x >> landed in rawhide already has them. >> >> The main use-cases for this feature are: >> a) -devel package dependencies on other -devel packages >> b) BuildRequires >> c) manual dependencies for plugins and such > Which kinds of problems does this solve? If it wasn't obvious from the list above... a) foo-devel requires bar-devel. Currently bar-devel.i386 is sufficient to satisfy foo-devel.x86_64 which is obviously not correct. b) Similarly to a), BuildRequires: foo-devel. Currently, if you have foo-devel.i386 installed and try to build for x86_64, it's considered satisfied which is obviously not correct. c) A package depends on a dlopen()'ed plugin, say "foo-plugin". The plugin needs to be of compatible arch to work, quite obviously. The only way to express this correctly right now is to use file dependencies on %{_libdir}/something. > So far I don't see any. Conversely, AFAIU all this does, is to add more > incompatibilities, more rpmdb entries, all for information which already > is hidden somewhere else. So you'd rather change all -devel and build dependencies to %{_libdir}/libfoo.so file dependencies? And there's no incompatibility here, specs remain backwards compatible as long as you use the conditional %{?_isa} construct for this. - Panu - From rc040203 at freenet.de Tue Sep 23 08:19:54 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 23 Sep 2008 10:19:54 +0200 Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> <20080922194533.GA21219@wolff.to> <1222112871.12513.89.camel@rosebud> <20080922201219.GA28441@wolff.to> <1222151206.3564.30.camel@beck.corsepiu.local> Message-ID: <1222157994.3564.37.camel@beck.corsepiu.local> On Tue, 2008-09-23 at 09:49 +0300, Panu Matilainen wrote: > On Tue, 23 Sep 2008, Ralf Corsepius wrote: > > > On Tue, 2008-09-23 at 09:18 +0300, Panu Matilainen wrote: > >> The new rpm in rawhide adds ISA provides (ie the (x86-32) stuff") > >> automatically for all non-noarch packages (including subpackages), all > >> that's needed is rebuild. So every package rebuilt since rpm 4.5.90.x > >> landed in rawhide already has them. > >> > >> The main use-cases for this feature are: > >> a) -devel package dependencies on other -devel packages > >> b) BuildRequires > >> c) manual dependencies for plugins and such > > Which kinds of problems does this solve? > > If it wasn't obvious from the list above... > a) foo-devel requires bar-devel. Currently bar-devel.i386 is sufficient to > satisfy foo-devel.x86_64 which is obviously not correct. bug in rpm's version comparison => Your addition doesn't solve it. > b) Similarly to a), BuildRequires: foo-devel. Currently, if you have > foo-devel.i386 installed and try to build for x86_64, it's considered > satisfied which is obviously not correct. same as above. > c) A package depends on a dlopen()'ed plugin, say "foo-plugin". The plugin > needs to be of compatible arch to work, quite obviously. The only way to > express this correctly right now is to use file dependencies on > %{_libdir}/something. Correct. You don't solve anything that file-deps would not solve. > > So far I don't see any. Conversely, AFAIU all this does, is to add more > > incompatibilities, more rpmdb entries, all for information which already > > is hidden somewhere else. > > So you'd rather change all -devel and build dependencies to > %{_libdir}/libfoo.so file dependencies? Correct. I think, all what these rpm meta-tag do is to add pollution to the rpmdb, to solve a problem to which file-deps would be an already existing "natural solution", because they actually are file deps at run-time. > And there's no incompatibility > here, specs remain backwards compatible as long as you use the conditional > %{?_isa} construct for this. More pollution to rpmdb, more sources of errors and conflicts. Ralf From pmatilai at laiskiainen.org Tue Sep 23 09:54:58 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 23 Sep 2008 12:54:58 +0300 (EEST) Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: <1222157994.3564.37.camel@beck.corsepiu.local> References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> <20080922194533.GA21219@wolff.to> <1222112871.12513.89.camel@rosebud> <20080922201219.GA28441@wolff.to> <1222151206.3564.30.camel@beck.corsepiu.local> <1222157994.3564.37.camel@beck.corsepiu.local> Message-ID: On Tue, 23 Sep 2008, Ralf Corsepius wrote: > On Tue, 2008-09-23 at 09:49 +0300, Panu Matilainen wrote: >> On Tue, 23 Sep 2008, Ralf Corsepius wrote: >> >>> On Tue, 2008-09-23 at 09:18 +0300, Panu Matilainen wrote: >>>> The new rpm in rawhide adds ISA provides (ie the (x86-32) stuff") >>>> automatically for all non-noarch packages (including subpackages), all >>>> that's needed is rebuild. So every package rebuilt since rpm 4.5.90.x >>>> landed in rawhide already has them. >>>> >>>> The main use-cases for this feature are: >>>> a) -devel package dependencies on other -devel packages >>>> b) BuildRequires >>>> c) manual dependencies for plugins and such >>> Which kinds of problems does this solve? >> >> If it wasn't obvious from the list above... >> a) foo-devel requires bar-devel. Currently bar-devel.i386 is sufficient to >> satisfy foo-devel.x86_64 which is obviously not correct. > bug in rpm's version comparison => Your addition doesn't solve it. No. There hasn't been a way to specify dependency on certain architecture, rpm has no way of knowing if "foo" in "Requires: foo" is supposed to be same arch or not. Sure it would be possible to teach rpm to grok the name.arch syntax for (build)requires too, but it would require changing every depsolver to understand it too, and *that* would be incompatible change in spec syntax as well. Whereas the new provide introduces precisely zero incompatibilities. >> b) Similarly to a), BuildRequires: foo-devel. Currently, if you have >> foo-devel.i386 installed and try to build for x86_64, it's considered >> satisfied which is obviously not correct. > same as above. Same as above. > >> c) A package depends on a dlopen()'ed plugin, say "foo-plugin". The plugin >> needs to be of compatible arch to work, quite obviously. The only way to >> express this correctly right now is to use file dependencies on >> %{_libdir}/something. > Correct. You don't solve anything that file-deps would not solve. > >>> So far I don't see any. Conversely, AFAIU all this does, is to add more >>> incompatibilities, more rpmdb entries, all for information which already >>> is hidden somewhere else. >> >> So you'd rather change all -devel and build dependencies to >> %{_libdir}/libfoo.so file dependencies? > Correct. I think, all what these rpm meta-tag do is to add pollution to > the rpmdb, to solve a problem to which file-deps would be an already > existing "natural solution", because they actually are file deps at > run-time. Except there isn't always an "arch-specific" file you can depend on. Often there is, but not always. File-dependencies are more expensive to look up than regular provides. If file dependencies on things like /usr/lib64/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_64_3.3.2.v3349.jar are so wonderfully perfect solution to the problem at hand, I wonder why people aren't using them for everything then. - Panu - From nicolas.mailhot at laposte.net Tue Sep 23 10:52:55 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 23 Sep 2008 12:52:55 +0200 (CEST) Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> <20080922194533.GA21219@wolff.to> <1222112871.12513.89.camel@rosebud> <20080922201219.GA28441@wolff.to> <1222151206.3564.30.camel@beck.corsepiu.local> <1222157994.3564.37.camel@beck.corsepiu.local> Message-ID: <3f38d0aebf9509f300bb14a352ddcb01.squirrel@arekh.dyndns.org> Le Mar 23 septembre 2008 11:54, Panu Matilainen a ?crit : > Sure it would be possible to teach rpm to grok the name.arch syntax > for > (build)requires too, but it would require changing every depsolver to > understand it too, and *that* would be incompatible change in spec > syntax > as well. Whereas the new provide introduces precisely zero > incompatibilities. But that would fix the problem once and for all wouldn't it? Are the other solutions so fool-proof they won't need to be revised anyway? -- Nicolas Mailhot From rc040203 at freenet.de Tue Sep 23 11:25:08 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 23 Sep 2008 13:25:08 +0200 Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> <20080922194533.GA21219@wolff.to> <1222112871.12513.89.camel@rosebud> <20080922201219.GA28441@wolff.to> <1222151206.3564.30.camel@beck.corsepiu.local> <1222157994.3564.37.camel@beck.corsepiu.local> Message-ID: <1222169108.3564.58.camel@beck.corsepiu.local> On Tue, 2008-09-23 at 12:54 +0300, Panu Matilainen wrote: > On Tue, 23 Sep 2008, Ralf Corsepius wrote: > > > On Tue, 2008-09-23 at 09:49 +0300, Panu Matilainen wrote: > >> On Tue, 23 Sep 2008, Ralf Corsepius wrote: > >> > >>> On Tue, 2008-09-23 at 09:18 +0300, Panu Matilainen wrote: > >>>> The new rpm in rawhide adds ISA provides (ie the (x86-32) stuff") > >>>> automatically for all non-noarch packages (including subpackages), all > >>>> that's needed is rebuild. So every package rebuilt since rpm 4.5.90.x > >>>> landed in rawhide already has them. > >>>> > >>>> The main use-cases for this feature are: > >>>> a) -devel package dependencies on other -devel packages > >>>> b) BuildRequires > >>>> c) manual dependencies for plugins and such > >>> Which kinds of problems does this solve? > >> > >> If it wasn't obvious from the list above... > >> a) foo-devel requires bar-devel. Currently bar-devel.i386 is sufficient to > >> satisfy foo-devel.x86_64 which is obviously not correct. > > bug in rpm's version comparison => Your addition doesn't solve it. > > No. There hasn't been a way to specify dependency on certain architecture, Exactly: This is the BUG in *RPM*. > rpm has no way of knowing if "foo" in "Requires: foo" is supposed to be > same arch or not. Right, but it could (and should have done so for ages) The information is present. > Sure it would be possible to teach rpm to grok the name.arch syntax for > (build)requires too, but it would require changing every depsolver to > understand it too, Correct, that's another bug. The depsolver should be part of RPM. > >> c) A package depends on a dlopen()'ed plugin, say "foo-plugin". The plugin > >> needs to be of compatible arch to work, quite obviously. The only way to > >> express this correctly right now is to use file dependencies on > >> %{_libdir}/something. > > Correct. You don't solve anything that file-deps would not solve. > > > >>> So far I don't see any. Conversely, AFAIU all this does, is to add more > >>> incompatibilities, more rpmdb entries, all for information which already > >>> is hidden somewhere else. > >> > >> So you'd rather change all -devel and build dependencies to > >> %{_libdir}/libfoo.so file dependencies? > > Correct. I think, all what these rpm meta-tag do is to add pollution to > > the rpmdb, to solve a problem to which file-deps would be an already > > existing "natural solution", because they actually are file deps at > > run-time. > > Except there isn't always an "arch-specific" file you can depend on. And where is the problem? A "client" package which depends on some "provider" almost always depends on the provider to provide a file, no matter what this file actually is. I.e. you hardly ever need the "architecture", you almost always need the file and nothing else. > Often > there is, but not always. File-dependencies are more expensive to > look up than regular provides. Wrong. Inside of rpm everything is database lookups. Whether these are file-deps or artificial provides doesn't matter. Whether rpm/yum etc. handle them efficiently, is a different matter. > If file dependencies on things like > /usr/lib64/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_64_3.3.2.v3349.jar > are so wonderfully perfect solution to the problem at hand, I wonder why > people aren't using them for everything then. Lack of insight, people being subject to FUD/propaganda for years? People being confused by the very few corner cases (SONAMES)? Ralf From rjones at redhat.com Tue Sep 23 12:15:40 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 23 Sep 2008 13:15:40 +0100 Subject: [Fedora-packaging] Next FPC? Message-ID: <20080923121540.GA23484@amd.home.annexia.org> I notice that FPC hasn't met for a while. I bumped up the priority of the MinGW packaging draft on https://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo because I think it'd be good to now have a technical discussion about the draft guidelines which we substantially tidied up last weekend: https://fedoraproject.org/wiki/PackagingDrafts/MinGW Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From pmatilai at laiskiainen.org Tue Sep 23 12:51:54 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 23 Sep 2008 15:51:54 +0300 (EEST) Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: <3f38d0aebf9509f300bb14a352ddcb01.squirrel@arekh.dyndns.org> References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> <20080922194533.GA21219@wolff.to> <1222112871.12513.89.camel@rosebud> <20080922201219.GA28441@wolff.to> <1222151206.3564.30.camel@beck.corsepiu.local> <1222157994.3564.37.camel@beck.corsepiu.local> <3f38d0aebf9509f300bb14a352ddcb01.squirrel@arekh.dyndns.org> Message-ID: On Tue, 23 Sep 2008, Nicolas Mailhot wrote: > > Le Mar 23 septembre 2008 11:54, Panu Matilainen a ?crit : > >> Sure it would be possible to teach rpm to grok the name.arch syntax >> for >> (build)requires too, but it would require changing every depsolver to >> understand it too, and *that* would be incompatible change in spec >> syntax >> as well. Whereas the new provide introduces precisely zero >> incompatibilities. > > But that would fix the problem once and for all wouldn't it? Are the > other solutions so fool-proof they won't need to be revised anyway? Plain name.arch syntax in dependencies has it's own problems, see the sub-thread starting here: https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00056.html That's not to say support for it couldn't be added but using it would cause a huge incompatibilities all over the place for little gain. - Panu - From j.w.r.degoede at hhs.nl Tue Sep 23 13:34:49 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 23 Sep 2008 15:34:49 +0200 Subject: [Fedora-packaging] Next FPC? In-Reply-To: <20080923121540.GA23484@amd.home.annexia.org> References: <20080923121540.GA23484@amd.home.annexia.org> Message-ID: <48D8F079.4020002@hhs.nl> Richard W.M. Jones wrote: > I notice that FPC hasn't met for a while. > > I bumped up the priority of the MinGW packaging draft on > https://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo because I > think it'd be good to now have a technical discussion about the draft > guidelines which we substantially tidied up last weekend: > > https://fedoraproject.org/wiki/PackagingDrafts/MinGW > I don't know when the next FPC meeting is, but I've taken a quick look at the draft and it looks good. I think the mingw SIG has done an excellent job! Regards, Hans From bruno at wolff.to Tue Sep 23 13:44:43 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 23 Sep 2008 08:44:43 -0500 Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: <1222157994.3564.37.camel@beck.corsepiu.local> References: <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> <20080922194533.GA21219@wolff.to> <1222112871.12513.89.camel@rosebud> <20080922201219.GA28441@wolff.to> <1222151206.3564.30.camel@beck.corsepiu.local> <1222157994.3564.37.camel@beck.corsepiu.local> Message-ID: <20080923134443.GA9685@wolff.to> On Tue, Sep 23, 2008 at 10:19:54 +0200, Ralf Corsepius wrote: > On Tue, 2008-09-23 at 09:49 +0300, Panu Matilainen wrote: > > On Tue, 23 Sep 2008, Ralf Corsepius wrote: > > > > If it wasn't obvious from the list above... > > a) foo-devel requires bar-devel. Currently bar-devel.i386 is sufficient to > > satisfy foo-devel.x86_64 which is obviously not correct. > bug in rpm's version comparison => Your addition doesn't solve it. How are you going to automatically tell in which cases you need to match arch and which ones you don't? It looks like you are going to have to touch a bunch of requires or provides in any case. > > So you'd rather change all -devel and build dependencies to > > %{_libdir}/libfoo.so file dependencies? > Correct. I think, all what these rpm meta-tag do is to add pollution to > the rpmdb, to solve a problem to which file-deps would be an already > existing "natural solution", because they actually are file deps at > run-time. For libraries, shouldn't the dependency just be on the library name and arch, not the actual filename path? The library file could go into one of several directories and still be available. > More pollution to rpmdb, more sources of errors and conflicts. Don't you consider treating all of the filenames installed by a package as what amounts to provided capabilities, as pollution? I would think you wouldn't want packages requiring just any old file out of a package in order to express a dependency on it. From rdieter at math.unl.edu Tue Sep 23 13:51:00 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 23 Sep 2008 08:51:00 -0500 Subject: [Fedora-packaging] Question about how libgcj-devel requires zlib In-Reply-To: References: <20080922163316.GA27102@wolff.to> <1222101610.12513.73.camel@rosebud> <20080922182625.GA13884@wolff.to> <1222108145.12513.78.camel@rosebud> <1222111663.3555.78.camel@localhost.localdomain> <1222111816.12513.85.camel@rosebud> Message-ID: <48D8F444.9030007@math.unl.edu> Panu Matilainen wrote: > Well obviously you don't want to use literal, hardcoded "Requires: > zlib-devel(x86-32)" in the spec, but this instead: > > Requires: zlib-devel%{?_isa} ... > And yes this is one of the major cases for which the whole ISA-thingie > was invented. What's missing is the mass-rebuild to make the > ISA-provides globally available, and FPC guidelines on using them. Thanks Panu, this will certainly be a very welcome new rpm feature. -- Rex From debarshi.ray at gmail.com Fri Sep 26 05:27:56 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 26 Sep 2008 10:57:56 +0530 Subject: [Fedora-packaging] Broken URL in review process page Message-ID: <3170f42f0809252227q5223dcn26946a19c680459c@mail.gmail.com> The review process page on the Fedora wiki [1] provides this link to check if a person is already sponsored and part of the packager group: https://admin.fedoraproject.org/accounts/group/dump/?groupname=packager However it did not work for me today and I found this https://admin.fedoraproject.org/accounts/group/members/packager?search=* to work. Thanks, Debarshi [1] https://fedoraproject.org/wiki/Package_Review_Process From mpeters at mac.com Sun Sep 28 04:07:51 2008 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 27 Sep 2008 21:07:51 -0700 Subject: [Fedora-packaging] Please do not redefine %_bindir Message-ID: <48DF0317.80908@mac.com> Building the fedora 9 cpio package for a distribution that puts install-info into /usr/bin (where it probably belongs - the info dir is in /usr/share so /usr is going to be mounted when you run it, and users can make there own info dir so it probably shouldn't be a /sbin or /usr/sbin binary, but anyway ...) So - to port the rpm I needed to change the references to /sbin/install-info to %{_bindir}/install-info After building, it would not install because - yup, the fedora spec file redefines %_bindir at the top of the spec file to /bin Don't do that. There should be a packaging guideline against that. It impacts more than just the %configure macro and the %files section, which I assume is why it was done. It impacts anything else that uses %{_binder} just add --bindir=/bin to the end of the %configure line and specify /bin/ in %files and don't redefine the filesystem path macros. Thank you. From tcallawa at redhat.com Sun Sep 28 04:14:14 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 28 Sep 2008 00:14:14 -0400 Subject: [Fedora-packaging] Please do not redefine %_bindir In-Reply-To: <48DF0317.80908@mac.com> References: <48DF0317.80908@mac.com> Message-ID: <1222575254.5098.16.camel@localhost.localdomain> On Sat, 2008-09-27 at 21:07 -0700, Michael A. Peters wrote: > Building the fedora 9 cpio package for a distribution that puts > install-info into /usr/bin (where it probably belongs - the info dir is > in /usr/share so /usr is going to be mounted when you run it, and users > can make there own info dir so it probably shouldn't be a /sbin or > /usr/sbin binary, but anyway ...) > > So - to port the rpm I needed to change the references to > /sbin/install-info to %{_bindir}/install-info > > After building, it would not install because - yup, the fedora spec file > redefines %_bindir at the top of the spec file to /bin > > Don't do that. A lot of ancient Fedora packages that date back to the RHL era do things like this. We can add this to the guidelines (and perhaps we should), but in the majority of cases like this, it will do nothing to fix the actual packages which are brain-damaged like this. If you have not already done so, please file a bug against the Fedora cpio package. ~spot From rc040203 at freenet.de Sun Sep 28 10:27:12 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 28 Sep 2008 12:27:12 +0200 Subject: [Fedora-packaging] Please do not redefine %_bindir In-Reply-To: <48DF0317.80908@mac.com> References: <48DF0317.80908@mac.com> Message-ID: <1222597632.3564.299.camel@beck.corsepiu.local> On Sat, 2008-09-27 at 21:07 -0700, Michael A. Peters wrote: > Building the fedora 9 cpio package for a distribution that puts > install-info into /usr/bin (where it probably belongs - the info dir is > in /usr/share so /usr is going to be mounted when you run it, and users > can make there own info dir so it probably shouldn't be a /sbin or > /usr/sbin binary, but anyway ...) install-info belongs into /sbin or /usr/sbin, to keep it out of an ordinary user's $PATH. > So - to port the rpm I needed to change the references to > /sbin/install-info to %{_bindir}/install-info Don't do this. Your package MUST comply to the Fedora conventions. Ralf From paul at all-the-johnsons.co.uk Sun Sep 28 14:27:50 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 28 Sep 2008 15:27:50 +0100 Subject: [Fedora-packaging] Request : removal of gtk-sharp Message-ID: <1222612070.25980.1.camel@PB3.Linux> Hi, From what I've discovered, gtk-sharp has been fully depricated by gtk-sharp2 now and so as maintainer of this package for fedora, can I ask that it is retired from rawhide and f9? Thanks 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 a.badger at gmail.com Sun Sep 28 20:41:26 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 28 Sep 2008 13:41:26 -0700 Subject: [Fedora-packaging] Request : removal of gtk-sharp In-Reply-To: <1222612070.25980.1.camel@PB3.Linux> References: <1222612070.25980.1.camel@PB3.Linux> Message-ID: <48DFEBF6.80401@gmail.com> Paul wrote: > Hi, > > From what I've discovered, gtk-sharp has been fully depricated by > gtk-sharp2 now and so as maintainer of this package for fedora, can I > ask that it is retired from rawhide and f9? > yes. But you don't need to mention it here :-) mail fedora-devel about it in case someone else wants to pick it up for some package/need we don't know about. (IIRC, you already did). Then follow the instructions on this page: http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: