From opensource at till.name Sat Dec 2 01:38:52 2006 From: opensource at till.name (Till Maas) Date: Sat, 02 Dec 2006 02:38:52 +0100 Subject: [Fedora-packaging] debuginfo of python packages / programms Message-ID: <200612020239.26019.opensource@till.name> Hiyas, I am going to package offlineimap (http://software.complete.org/offlineimap/), which is a python programm. Rpmbuild only creates an empty debuginfo file, is this always the case for python programms / packages? Is it ok to disable the debuginfo package then with %define debug_package %{nil}? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mtasaka at ioa.s.u-tokyo.ac.jp Sat Dec 2 01:55:38 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 02 Dec 2006 10:55:38 +0900 Subject: [Fedora-packaging] debuginfo of python packages / programms In-Reply-To: <200612020239.26019.opensource@till.name> References: <200612020239.26019.opensource@till.name> Message-ID: <4570DD1A.7030908@ioa.s.u-tokyo.ac.jp> Till Maas wrote: > Hiyas, > > I am going to package offlineimap (http://software.complete.org/offlineimap/), > which is a python programm. Rpmbuild only creates an empty debuginfo file, is > this always the case for python programms / packages? Is it ok to disable the > debuginfo package then with %define debug_package %{nil}? > > Regards, > Till > It seems that this (offlineimap) is a arch-independent package, so if you want to package this as rpm style, it should be marked as 'noarch'. Then debuginfo rpm is not created. Mamoru Tasaka From panemade at gmail.com Sun Dec 3 13:48:26 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Sun, 3 Dec 2006 19:18:26 +0530 Subject: [Fedora-packaging] debuginfo of python packages / programms In-Reply-To: <200612020239.26019.opensource@till.name> References: <200612020239.26019.opensource@till.name> Message-ID: Hi, On 12/2/06, Till Maas wrote: > Hiyas, > > I am going to package offlineimap (http://software.complete.org/offlineimap/), > which is a python programm. Rpmbuild only creates an empty debuginfo file, is > this always the case for python programms / packages? Is it ok to disable the > debuginfo package then with %define debug_package %{nil}? I have seen some of python packages are of noarch type. So in that case no debuginfo package is created. But if its a arch specific binary RPM then it will be create debuginfo. What i feel its good practice to always enable debuginfo packages, so that in future or if build problem occurs that can be used as basis to check cause of problem. Regards, Parag. From ville.skytta at iki.fi Mon Dec 4 21:22:43 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 04 Dec 2006 23:22:43 +0200 Subject: [Fedora-packaging] Missing tomorrow's meeting Message-ID: <1165267363.25942.0.camel@viper.local> I'm not going to make it to tomorrow's packaging committee meeting. From rdieter at math.unl.edu Mon Dec 4 21:36:59 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 04 Dec 2006 15:36:59 -0600 Subject: [Fedora-packaging] iconcache scriptlets Message-ID: I posted this proposal awhile back: http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache Don't remember seeing much (any?) feedback, so everyone must agree with it. (: I'd like to get this discussed and ratified by the committee. -- Rex From Axel.Thimm at ATrpms.net Mon Dec 4 23:05:59 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Dec 2006 00:05:59 +0100 Subject: [Fedora-packaging] LSB/FSG's packaging summit on Wed, Dec 6th Message-ID: <20061204230559.GD26239@neu.nirvana> Hi, the Free Standards Group will have its first packaging summit on Wednesday: http://www.freestandards.org/en/LSB_face-to-face_(December_2006) Some people from RH/Fedora like Paul Nasrat and Seth Vidal will be attending and presenting/discussing rpm and yum. Since I live a couple of blocks away I'll try to sneak in, if possible ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Mon Dec 4 23:22:23 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 04 Dec 2006 18:22:23 -0500 Subject: [Fedora-packaging] LSB/FSG's packaging summit on Wed, Dec 6th In-Reply-To: <20061204230559.GD26239@neu.nirvana> References: <20061204230559.GD26239@neu.nirvana> Message-ID: <1165274543.17513.6.camel@cutter> On Tue, 2006-12-05 at 00:05 +0100, Axel Thimm wrote: > Hi, > > the Free Standards Group will have its first packaging summit on > Wednesday: > > http://www.freestandards.org/en/LSB_face-to-face_(December_2006) > > Some people from RH/Fedora like Paul Nasrat and Seth Vidal will be > attending and presenting/discussing rpm and yum. Since I live a couple > of blocks away I'll try to sneak in, if possible ;) You live a couple blocks away? If you'd like to meet up for a meal one night drop me an email. -sv From a.badger at gmail.com Tue Dec 5 04:41:01 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 04 Dec 2006 20:41:01 -0800 Subject: [Fedora-packaging] iconcache scriptlets In-Reply-To: References: Message-ID: <1165293661.29086.361.camel@localhost.localdomain> On Mon, 2006-12-04 at 15:36 -0600, Rex Dieter wrote: > I posted this proposal awhile back: > http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache > > Don't remember seeing much (any?) feedback, so everyone must agree with it. > (: > > I'd like to get this discussed and ratified by the committee. I wrote something but it was much after the fact and in a totally different thread. Here's my comments: ''' I'm sorry I missed the initial announcement of this. I think your revisions make sense after xdg-utils go into Core and the requirement tree for gtk2 is in place (hicolor-icon-theme should work fine for this). Changing the guidelines before that would break things that currently work. (Or we could place a hard Require:s on xdg-utils until it was fixed.) Is there an RFE open to get xdg-utils into Core and make the necessary changes? If the relevant maintainers think it's a good change we can mention that the suggested scriptlet is changing in FCX. '''[1]_ [1]_ https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00011.html -------------- 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 enrico.scholz at informatik.tu-chemnitz.de Tue Dec 5 08:20:46 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 05 Dec 2006 09:20:46 +0100 Subject: [Fedora-packaging] iconcache scriptlets In-Reply-To: (Rex Dieter's message of "Mon, 04 Dec 2006 15:36:59 -0600") References: Message-ID: <87ac22eotd.fsf@kosh.bigo.ensc.de> rdieter at math.unl.edu (Rex Dieter) writes: > I posted this proposal awhile back: > http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache > > Don't remember seeing much (any?) feedback, so everyone must agree with it. > (: > > I'd like to get this discussed and ratified by the committee. Why the 'touch' stuff? At least 'gtk-update-icon-cache' knows a '--force' option which should have the wanted effect but adds less clutter. Enrico From rc040203 at freenet.de Tue Dec 5 15:32:37 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 05 Dec 2006 16:32:37 +0100 Subject: [Fedora-packaging] Missing today's meeting Message-ID: <1165332757.23106.3.camel@mccallum.corsepiu.local> I'll probably not be able to attend today's meeting. Ralf From rdieter at math.unl.edu Tue Dec 5 16:01:41 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 05 Dec 2006 10:01:41 -0600 Subject: [Fedora-packaging] Re: iconcache scriptlets References: <87ac22eotd.fsf@kosh.bigo.ensc.de> Message-ID: Enrico Scholz wrote: > rdieter at math.unl.edu (Rex Dieter) writes: > >> I posted this proposal awhile back: >> http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache >> >> Don't remember seeing much (any?) feedback, so everyone must agree with >> it. (: >> >> I'd like to get this discussed and ratified by the committee. > > Why the 'touch' stuff? The fdo spec mandates the timestamp of the installed-to icon dir *must* be updated. > At least 'gtk-update-icon-cache' knows a '--force' > option which should have the wanted effect but adds less clutter. Dropping the 'touch' and using *only* gtk-update-icon-cache --force (or even xdg-icon-resource forceupdate) would require the tool to be present at install-time, and necessitate Requires(post,postun): foo which, imo, should be avoided, if at all possible. Further, one of the major motivations for the proposal was to avoid the use of of any toolkit-specific tool (ie, gtk-update-icon-cache). I (and many others) have long argued that it is inappropriate to shoe-horn a toolkit-specific gtk-update-icon-cache into *every* package installing icons. I would like to hope that updating the packaging guidelines thusly would "motivate" the gtk2 maintainer to do something about the long-standing: http://bugzilla.redhat.com/170335 -- Rex From rdieter at math.unl.edu Tue Dec 5 16:06:25 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 05 Dec 2006 10:06:25 -0600 Subject: [Fedora-packaging] Re: iconcache scriptlets References: <1165293661.29086.361.camel@localhost.localdomain> Message-ID: Toshio Kuratomi wrote: > On Mon, 2006-12-04 at 15:36 -0600, Rex Dieter wrote: >> I posted this proposal awhile back: >> http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache > I'm sorry I missed the initial announcement of this. I think your > revisions make sense after xdg-utils go into Core and the requirement > tree for gtk2 is in place (hicolor-icon-theme should work fine for > this). Changing the guidelines before that would break things that > currently work. (Or we could place a hard Require:s on xdg-utils until > it was fixed.) In any case, nothing would break. At worst, gtk apps would suffer a performance penalty, at least until gtk2 is fixed: http://bugzilla.redhat.com/170335 (a personal packaging pet-peave). > Is there an RFE open to get xdg-utils into Core and make the necessary > changes? IMO, it's a no-brainer, but likely not relavant, due to the proposed/likely merge of Core/Extras for FC-7 (see http://fedoraproject.org/wiki/FedoraSummit/OpeningCore) -- Rex From tcallawa at redhat.com Tue Dec 5 17:26:21 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 05 Dec 2006 11:26:21 -0600 Subject: [Fedora-packaging] Conflicts Draft Proposal Message-ID: <1165339581.20269.249.camel@localhost.localdomain> I drafted a proposal for when it is ok to use Conflicts: (almost never): http://fedoraproject.org/wiki/PackagingDrafts/Conflicts Keep in mind that while it is not stated in the Draft, the kernel is considered a special case, and I feel strongly that most (if not all) of its existing Conflicts: will be approved. Fedora Packaging Committee Members should vote via email on this issue, as we did not have quorum in the IRC meeting to vote. ~spot From notting at redhat.com Tue Dec 5 17:33:38 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 5 Dec 2006 12:33:38 -0500 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <1165339581.20269.249.camel@localhost.localdomain> References: <1165339581.20269.249.camel@localhost.localdomain> Message-ID: <20061205173338.GB14640@nostromo.devel.redhat.com> Tom 'spot' Callaway (tcallawa at redhat.com) said: > I drafted a proposal for when it is ok to use Conflicts: (almost never): > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > > Keep in mind that while it is not stated in the Draft, the kernel is > considered a special case, and I feel strongly that most (if not all) of > its existing Conflicts: will be approved. > > Fedora Packaging Committee Members should vote via email on this issue, > as we did not have quorum in the IRC meeting to vote. Example: My package, foo-game doesn't work when bar is older than 1.2.3. WRONG: Conflicts: bar < 1.2.3 RIGHT: Requires: bar >= 1.2.3 What about when foo-game doesn't actually require bar? To be more precise: $ rpm -q --conflicts initscripts mkinitrd < 4.0 kernel < 2.6.12 ypbind < 1.6-12 psacct < 6.3.2-12 kbd < 1.06-19 lokkit < 0.50-14 dhclient < 3.0.3-7 tcsh < 6.13-5 xorg-x11 glib2 < 2.11.1-2 Some of these can be flipped to requires (kernel, for example, glib2). However, making initscripts *require* things like ypbind, psacct, dhclient would be wrong. Bill From paul at city-fan.org Tue Dec 5 17:37:42 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 05 Dec 2006 17:37:42 +0000 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <20061205173338.GB14640@nostromo.devel.redhat.com> References: <1165339581.20269.249.camel@localhost.localdomain> <20061205173338.GB14640@nostromo.devel.redhat.com> Message-ID: <4575AE66.8050305@city-fan.org> Bill Nottingham wrote: > Tom 'spot' Callaway (tcallawa at redhat.com) said: >> I drafted a proposal for when it is ok to use Conflicts: (almost never): >> >> http://fedoraproject.org/wiki/PackagingDrafts/Conflicts >> >> Keep in mind that while it is not stated in the Draft, the kernel is >> considered a special case, and I feel strongly that most (if not all) of >> its existing Conflicts: will be approved. >> >> Fedora Packaging Committee Members should vote via email on this issue, >> as we did not have quorum in the IRC meeting to vote. > > Example: > My package, foo-game doesn't work when bar is older than 1.2.3. > WRONG: Conflicts: bar < 1.2.3 > RIGHT: Requires: bar >= 1.2.3 > > What about when foo-game doesn't actually require bar? > > To be more precise: > > $ rpm -q --conflicts initscripts > mkinitrd < 4.0 > kernel < 2.6.12 > ypbind < 1.6-12 > psacct < 6.3.2-12 > kbd < 1.06-19 > lokkit < 0.50-14 > dhclient < 3.0.3-7 > tcsh < 6.13-5 > xorg-x11 > glib2 < 2.11.1-2 > > Some of these can be flipped to requires (kernel, for example, glib2). However, > making initscripts *require* things like ypbind, psacct, dhclient would be > wrong. Already covered => When you must use Conflicts If you find yourself in a situation where ... this package cannot function when another package is installed ... you need to ... Paul. From tcallawa at redhat.com Tue Dec 5 17:40:59 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 05 Dec 2006 11:40:59 -0600 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <20061205173338.GB14640@nostromo.devel.redhat.com> References: <1165339581.20269.249.camel@localhost.localdomain> <20061205173338.GB14640@nostromo.devel.redhat.com> Message-ID: <1165340459.20269.252.camel@localhost.localdomain> > $ rpm -q --conflicts initscripts > mkinitrd < 4.0 > kernel < 2.6.12 > ypbind < 1.6-12 > psacct < 6.3.2-12 > kbd < 1.06-19 > lokkit < 0.50-14 > dhclient < 3.0.3-7 > tcsh < 6.13-5 > xorg-x11 > glib2 < 2.11.1-2 > > Some of these can be flipped to requires (kernel, for example, glib2). However, > making initscripts *require* things like ypbind, psacct, dhclient would be > wrong. And in those cases, you should use Conflicts, you just need to provide rationalization to the appropriate Fedora Committee and have a comment: e.g. # When ypbind is older than 1.6-12, the initscripts explode horribly. # ypbind is not required for initscripts to function. Conflicts: ypbind < 1.6-12 ~spot From pertusus at free.fr Tue Dec 5 17:40:05 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 5 Dec 2006 18:40:05 +0100 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <4575AE66.8050305@city-fan.org> References: <1165339581.20269.249.camel@localhost.localdomain> <20061205173338.GB14640@nostromo.devel.redhat.com> <4575AE66.8050305@city-fan.org> Message-ID: <20061205174005.GE2567@free.fr> On Tue, Dec 05, 2006 at 05:37:42PM +0000, Paul Howarth wrote: > > Already covered => > > When you must use Conflicts > > If you find yourself in a situation where ... this package cannot > function when another package is installed ... you need to ... Maybe an example could help make things clearer here? -- Pat From rdieter at math.unl.edu Tue Dec 5 17:43:59 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 05 Dec 2006 11:43:59 -0600 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <1165339581.20269.249.camel@localhost.localdomain> References: <1165339581.20269.249.camel@localhost.localdomain> Message-ID: <4575AFDF.7070403@math.unl.edu> Tom 'spot' Callaway wrote: > I drafted a proposal for when it is ok to use Conflicts: (almost never): > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts ... > Fedora Packaging Committee Members should vote via email on this issue, Looks sane, +1. -- Rex From Axel.Thimm at ATrpms.net Tue Dec 5 18:06:40 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Dec 2006 19:06:40 +0100 Subject: [Fedora-packaging] Re: Conflicts Draft Proposal In-Reply-To: <4575AFDF.7070403@math.unl.edu> References: <1165339581.20269.249.camel@localhost.localdomain> <4575AFDF.7070403@math.unl.edu> Message-ID: <20061205180640.GD18818@neu.nirvana> On Tue, Dec 05, 2006 at 11:43:59AM -0600, Rex Dieter wrote: > Tom 'spot' Callaway wrote: > >I drafted a proposal for when it is ok to use Conflicts: (almost never): > > > >http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > ... > >Fedora Packaging Committee Members should vote via email on this issue, > > Looks sane, +1. +1 -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Tue Dec 5 18:42:25 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 05 Dec 2006 19:42:25 +0100 Subject: [Fedora-packaging] Re: iconcache scriptlets In-Reply-To: (Rex Dieter's message of "Tue, 05 Dec 2006 10:01:41 -0600") References: <87ac22eotd.fsf@kosh.bigo.ensc.de> Message-ID: <87lklmrxpq.fsf@kosh.bigo.ensc.de> rdieter at math.unl.edu (Rex Dieter) writes: >>> http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache >> ... >> Why the 'touch' stuff? > > The fdo spec mandates the timestamp of the installed-to icon dir > *must* be updated. What is a 'fdo spec'? >> At least 'gtk-update-icon-cache' knows a '--force' >> option which should have the wanted effect but adds less clutter. > > Dropping the 'touch' and using *only* gtk-update-icon-cache --force > (or even xdg-icon-resource forceupdate) would require the tool to be > present at install-time, and necessitate Requires(post,postun): foo > which, imo, should be avoided, if at all possible. I do not see how | %{_bindir}/gtk-update-icon-cache --quiet --force %{_datadir}/icons/hicolor || : vs. | touch --no-create %{_datadir}/icons/hicolor || : | %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : would led to your conclusion. Enrico From enrico.scholz at informatik.tu-chemnitz.de Tue Dec 5 18:50:12 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 05 Dec 2006 19:50:12 +0100 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <1165339581.20269.249.camel@localhost.localdomain> (Tom Callaway's message of "Tue, 05 Dec 2006 11:26:21 -0600") References: <1165339581.20269.249.camel@localhost.localdomain> Message-ID: <87hcwarxcr.fsf@kosh.bigo.ensc.de> tcallawa at redhat.com ("Tom 'spot' Callaway") writes: > I drafted a proposal for when it is ok to use Conflicts: (almost never): > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts The statement | My package, foo-game doesn't work when bar is older than 1.2.3. | WRONG: Conflicts: bar < 1.2.3 | RIGHT: Requires: bar >= 1.2.3 is wrong and should be the opposite. There should not be added a Requires: when package 'foo' works without 'bar' but fails with 'bar < 1.2.3'. Popular example is the 'kernel' package. Lot of packages won't work with kernel 2.4 but it would be wrong to Require: the 'kernel' package. Enrico From rdieter at math.unl.edu Tue Dec 5 18:59:12 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 05 Dec 2006 12:59:12 -0600 Subject: [Fedora-packaging] Re: Re: iconcache scriptlets References: <87ac22eotd.fsf@kosh.bigo.ensc.de> <87lklmrxpq.fsf@kosh.bigo.ensc.de> Message-ID: Enrico Scholz wrote: > rdieter at math.unl.edu (Rex Dieter) writes: > >>>> http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache >>> ... >>> Why the 'touch' stuff? >> >> The fdo spec mandates the timestamp of the installed-to icon dir >> *must* be updated. > > What is a 'fdo spec'? http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#implementation_notes >>> At least 'gtk-update-icon-cache' knows a '--force' >>> option which should have the wanted effect but adds less clutter. >> >> Dropping the 'touch' and using *only* gtk-update-icon-cache --force >> (or even xdg-icon-resource forceupdate) would require the tool to be >> present at install-time, and necessitate Requires(post,postun): foo >> which, imo, should be avoided, if at all possible. > > I do not see how > > | gtk-update-icon-cache --quiet --force %{_datadir}/icons/hicolor || : > vs. > | touch --no-create %{_datadir}/icons/hicolor || : > | %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : > would led to your conclusion. Consider the case that gtk2 (and gtk-update-icon-cache) is not present at install-time (since we currently don't Requires(post,postun): gtk2), then the icondir timestamp will fail to be updated. -- Rex From tcallawa at redhat.com Tue Dec 5 19:22:00 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 05 Dec 2006 13:22:00 -0600 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <87hcwarxcr.fsf@kosh.bigo.ensc.de> References: <1165339581.20269.249.camel@localhost.localdomain> <87hcwarxcr.fsf@kosh.bigo.ensc.de> Message-ID: <1165346520.20269.301.camel@localhost.localdomain> On Tue, 2006-12-05 at 19:50 +0100, Enrico Scholz wrote: > tcallawa at redhat.com ("Tom 'spot' Callaway") writes: > > > I drafted a proposal for when it is ok to use Conflicts: (almost never): > > > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > > The statement > > | My package, foo-game doesn't work when bar is older than 1.2.3. > | WRONG: Conflicts: bar < 1.2.3 > | RIGHT: Requires: bar >= 1.2.3 > > is wrong and should be the opposite. There should not be added a Requires: > when package 'foo' works without 'bar' but fails with 'bar < 1.2.3'. The example is poor in that aspect. If you assume that foo-game needs bar, but will not work with older versions of bar (this is the normal case), then the example holds. I'll update the wording to reflect this. ~spot From a.badger at gmail.com Tue Dec 5 19:52:36 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 05 Dec 2006 11:52:36 -0800 Subject: [Fedora-packaging] Re: iconcache scriptlets In-Reply-To: References: <1165293661.29086.361.camel@localhost.localdomain> Message-ID: <1165348356.21163.52.camel@localhost.localdomain> On Tue, 2006-12-05 at 10:06 -0600, Rex Dieter wrote: > Toshio Kuratomi wrote: > > > On Mon, 2006-12-04 at 15:36 -0600, Rex Dieter wrote: > >> I posted this proposal awhile back: > >> http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache > > > I'm sorry I missed the initial announcement of this. I think your > > revisions make sense after xdg-utils go into Core and the requirement > > tree for gtk2 is in place (hicolor-icon-theme should work fine for > > this). Changing the guidelines before that would break things that > > currently work. (Or we could place a hard Require:s on xdg-utils until > > it was fixed.) > > In any case, nothing would break. At worst, gtk apps would suffer a > performance penalty, at least until gtk2 is fixed: > http://bugzilla.redhat.com/170335 > (a personal packaging pet-peave). > Yes. Which is a regression. I agree that 170335 should be fixed, though. There's three issues with gtk-update-icon-path in that bug: 1) It would be great if we didn't have to call gtk-update-icon-cache in every rpm that provides icons 2) gtk-update-icon-cache is inefficient as it may get called multiple times when several packages that install icons are installed in the same transaction (and it really only needs to be run once). 3) gtk2 needs to run gtk-update-icon-cache (or the xdg equivalent) in its %post so all the packages which defer updating the cache until gtk2 is installed have the cache updated when that happens. > > Is there an RFE open to get xdg-utils into Core and make the necessary > > changes? > > IMO, it's a no-brainer, but likely not relavant, due to the proposed/likely > merge of Core/Extras for FC-7 (see > http://fedoraproject.org/wiki/FedoraSummit/OpeningCore) > It's still relevant since we're going to spin some sort of distro (rather than say, "hey kids, here's a bunch of packages!") What needs to happen is that gtk2 needs to Require: xdg-utils (and use it in its % post ;-) In FC-6 this would require xdg-utils to move to Core. In Fedora 7, hopefully the "move to Core" part will be superfluous. But xdg-utils will need to be part of whatever platform gtk2 belongs to. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Tue Dec 5 19:55:40 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 05 Dec 2006 20:55:40 +0100 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <1165346520.20269.301.camel@localhost.localdomain> References: <1165339581.20269.249.camel@localhost.localdomain> <87hcwarxcr.fsf@kosh.bigo.ensc.de> <1165346520.20269.301.camel@localhost.localdomain> Message-ID: <1165348541.20474.63.camel@rousalka.dyndns.org> Le mardi 05 d?cembre 2006 ? 13:22 -0600, Tom 'spot' Callaway a ?crit : > The example is poor in that aspect. If you assume that foo-game needs > bar, but will not work with older versions of bar (this is the normal > case), then the example holds. I'll update the wording to reflect this. Please also make sure your proposal covers the case explained there : http://www.redhat.com/archives/fedora-packaging/2006-November/msg00026.html Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tcallawa at redhat.com Tue Dec 5 20:02:30 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 05 Dec 2006 14:02:30 -0600 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <1165348541.20474.63.camel@rousalka.dyndns.org> References: <1165339581.20269.249.camel@localhost.localdomain> <87hcwarxcr.fsf@kosh.bigo.ensc.de> <1165346520.20269.301.camel@localhost.localdomain> <1165348541.20474.63.camel@rousalka.dyndns.org> Message-ID: <1165348950.20269.325.camel@localhost.localdomain> On Tue, 2006-12-05 at 20:55 +0100, Nicolas Mailhot wrote: > Le mardi 05 d?cembre 2006 ? 13:22 -0600, Tom 'spot' Callaway a ?crit : > > > The example is poor in that aspect. If you assume that foo-game needs > > bar, but will not work with older versions of bar (this is the normal > > case), then the example holds. I'll update the wording to reflect this. > > Please also make sure your proposal covers the case explained there : > http://www.redhat.com/archives/fedora-packaging/2006-November/msg00026.html I think the rationale presented there for Conflicts use is OK. Again, the policy is "No use of Conflicts: without good reason". If you have a good reason, we'll approve it, you document it in the spec, and we all move on. :) ~spot From rdieter at math.unl.edu Tue Dec 5 20:05:24 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 05 Dec 2006 14:05:24 -0600 Subject: [Fedora-packaging] Re: iconcache scriptlets In-Reply-To: <1165348356.21163.52.camel@localhost.localdomain> References: <1165293661.29086.361.camel@localhost.localdomain> <1165348356.21163.52.camel@localhost.localdomain> Message-ID: <4575D104.30809@math.unl.edu> Toshio Kuratomi wrote: > On Tue, 2006-12-05 at 10:06 -0600, Rex Dieter wrote: >> Toshio Kuratomi wrote: >> >>> On Mon, 2006-12-04 at 15:36 -0600, Rex Dieter wrote: >>>> I posted this proposal awhile back: >>>> http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache >>> I'm sorry I missed the initial announcement of this. I think your >>> revisions make sense after xdg-utils go into Core and the requirement >>> tree for gtk2 is in place (hicolor-icon-theme should work fine for >>> this). Changing the guidelines before that would break things that >>> currently work. (Or we could place a hard Require:s on xdg-utils until >>> it was fixed.) >> In any case, nothing would break. At worst, gtk apps would suffer a >> performance penalty, at least until gtk2 is fixed: >> http://bugzilla.redhat.com/170335 >> (a personal packaging pet-peave). > Yes. Which is a regression. > I agree that 170335 should be fixed, though. Bingo. Bugs should be addressed in their proper domain, and I would argue strongly that the proper domain in the gtk2 (bug #170335) case is *gtk2*, not Packaging/Guidelines. -- Rex From nicolas.mailhot at laposte.net Tue Dec 5 20:09:39 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 05 Dec 2006 21:09:39 +0100 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <1165348950.20269.325.camel@localhost.localdomain> References: <1165339581.20269.249.camel@localhost.localdomain> <87hcwarxcr.fsf@kosh.bigo.ensc.de> <1165346520.20269.301.camel@localhost.localdomain> <1165348541.20474.63.camel@rousalka.dyndns.org> <1165348950.20269.325.camel@localhost.localdomain> Message-ID: <1165349379.20474.73.camel@rousalka.dyndns.org> Le mardi 05 d?cembre 2006 ? 14:02 -0600, Tom 'spot' Callaway a ?crit : > On Tue, 2006-12-05 at 20:55 +0100, Nicolas Mailhot wrote: > > Le mardi 05 d?cembre 2006 ? 13:22 -0600, Tom 'spot' Callaway a ?crit : > > > > > The example is poor in that aspect. If you assume that foo-game needs > > > bar, but will not work with older versions of bar (this is the normal > > > case), then the example holds. I'll update the wording to reflect this. > > > > Please also make sure your proposal covers the case explained there : > > http://www.redhat.com/archives/fedora-packaging/2006-November/msg00026.html > > I think the rationale presented there for Conflicts use is OK. > > Again, the policy is "No use of Conflicts: without good reason". If you > have a good reason, we'll approve it, you document it in the spec, and > we all move on. :) Operation "have spot document my conflict on his wiki page" failed Damn :) -- 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 a.badger at gmail.com Tue Dec 5 20:55:26 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 05 Dec 2006 12:55:26 -0800 Subject: [Fedora-packaging] Re: iconcache scriptlets In-Reply-To: <4575D104.30809@math.unl.edu> References: <1165293661.29086.361.camel@localhost.localdomain> <1165348356.21163.52.camel@localhost.localdomain> <4575D104.30809@math.unl.edu> Message-ID: <1165352126.21163.87.camel@localhost.localdomain> On Tue, 2006-12-05 at 14:05 -0600, Rex Dieter wrote: > Toshio Kuratomi wrote: > > On Tue, 2006-12-05 at 10:06 -0600, Rex Dieter wrote: > >> In any case, nothing would break. At worst, gtk apps would suffer a > >> performance penalty, at least until gtk2 is fixed: > >> http://bugzilla.redhat.com/170335 > >> (a personal packaging pet-peave). > > > Yes. Which is a regression. > > I agree that 170335 should be fixed, though. > > Bingo. Bugs should be addressed in their proper domain, and I would > argue strongly that the proper domain in the gtk2 (bug #170335) case is > *gtk2*, not Packaging/Guidelines. We have had and continue to have many pieces of guidelines which are held up by or written to account for bugs in support packages (rpm, scriptlets in Core packages, etc). I would argue that we want our packages to provide a bug free experience for our users. We can write what should happen in the Guidelines but if there's a problem due to bugs and there's a workaround, we should also endorse the workaround until the bug is resolved. In this case, I'd be okay with the changes to iconcache with 1) the addition of Requires(post): xdg-utils 2) note that the Requires(post) can go away after bug #NNNN is resolved where that bug asks for hicolor-icon-theme (gtk2 requires h-i-t) to do this: ''' Requires(post): xdg-utils [...] %post touch --no-create /usr/share/icons/hicolor %{_bindir}/xdg-icon-resource forceupdate --theme hicolor ''' -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Tue Dec 5 21:18:30 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 05 Dec 2006 13:18:30 -0800 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <1165340459.20269.252.camel@localhost.localdomain> References: <1165339581.20269.249.camel@localhost.localdomain> <20061205173338.GB14640@nostromo.devel.redhat.com> <1165340459.20269.252.camel@localhost.localdomain> Message-ID: <1165353510.21163.105.camel@localhost.localdomain> On Tue, 2006-12-05 at 11:40 -0600, Tom 'spot' Callaway wrote: > > $ rpm -q --conflicts initscripts > > mkinitrd < 4.0 > > kernel < 2.6.12 > > ypbind < 1.6-12 > > psacct < 6.3.2-12 > > kbd < 1.06-19 > > lokkit < 0.50-14 > > dhclient < 3.0.3-7 > > tcsh < 6.13-5 > > xorg-x11 > > glib2 < 2.11.1-2 > > > > Some of these can be flipped to requires (kernel, for example, glib2). However, > > making initscripts *require* things like ypbind, psacct, dhclient would be > > wrong. > > And in those cases, you should use Conflicts, you just need to provide > rationalization to the appropriate Fedora Committee and have a comment: > > e.g. > > # When ypbind is older than 1.6-12, the initscripts explode horribly. > # ypbind is not required for initscripts to function. > Conflicts: ypbind < 1.6-12 +1 to defining what's inappropriate for Conflicts and how to work around things. +1 for commenting anytime Conflicts is used. -1 to ask the Steering Committee to audit these on a case by case basis. Conflicts should be infrequently used, but it's not really something that I think needs to be evaluated like that. It's not political and it's not really an abuse of a tag when used correctly. It's a technical decision and should be worked out by a reviewer and packager. (And "after importation QA" if we had that.) Maybe making it clearer when it's okay to use Conflicts would be a good idea if we do that though: """ The only time Conflicts are allowed is when a package does not Require the other package but can make use of it as long as the other package is of the correct version. When this occurs you are allowed to use a versioned Conflicts to specify this and you must also include a comment which explains the reasoning: # When ypbind is older than 1.6-12, the initscripts explode horribly. # ypbind is not required for initscripts to function. Conflicts: ypbind < 1.6-12 If there is another instance where you think a Conflicts is required, please ask for input from the Packaging Committee so they can discuss it and decide if a change is needed to these Guidelines. """ -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Tue Dec 5 21:27:54 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 05 Dec 2006 15:27:54 -0600 Subject: [Fedora-packaging] Re: Re: iconcache scriptlets References: <1165293661.29086.361.camel@localhost.localdomain> <1165348356.21163.52.camel@localhost.localdomain> <4575D104.30809@math.unl.edu> <1165352126.21163.87.camel@localhost.localdomain> Message-ID: Toshio Kuratomi wrote: > On Tue, 2006-12-05 at 14:05 -0600, Rex Dieter wrote: >> Toshio Kuratomi wrote: >> > On Tue, 2006-12-05 at 10:06 -0600, Rex Dieter wrote: >> >> In any case, nothing would break. At worst, gtk apps would suffer a >> >> performance penalty, at least until gtk2 is fixed: >> >> http://bugzilla.redhat.com/170335 >> >> (a personal packaging pet-peave). >> >> > Yes. Which is a regression. >> > I agree that 170335 should be fixed, though. >> >> Bingo. Bugs should be addressed in their proper domain, and I would >> argue strongly that the proper domain in the gtk2 (bug #170335) case is >> *gtk2*, not Packaging/Guidelines. > > We have had and continue to have many pieces of guidelines which are > held up by or written to account for bugs in support packages (rpm, > scriptlets in Core packages, etc). ... > In this case, I'd be okay with the changes to iconcache with or I would have no problem with 0) hold publication of the new guideline pending one of: a) wait (indefinitely) until gtk2 bug is fixed b) give gtk2 maintainer reasonable time to fix (2-4 weeks?), then just do it. c) (I'm almost serious): make gtk2-fixbug170335-hack package, and use Requires(post,postun): gtk2-fixbug170335-hack (: If possible, I'd rather avoid complicating the guidelines (and packagers) lives with the, imo, unecessary extra baggage entailed with 1 or 2, by introducing a new Requires(post,postun): xdg-utils But, if the rest of the comittee is agreeable to the idea, I'll play along. > 1) the addition of Requires(post): xdg-utils > 2) note that the Requires(post) can go away after bug #NNNN is resolved > where that bug asks for hicolor-icon-theme (gtk2 requires h-i-t) to do > this: > > ''' > Requires(post): xdg-utils > [...] > %post > touch --no-create /usr/share/icons/hicolor > %{_bindir}/xdg-icon-resource forceupdate --theme hicolor > ''' From dlutter at redhat.com Tue Dec 5 22:01:44 2006 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 05 Dec 2006 22:01:44 +0000 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <4575AFDF.7070403@math.unl.edu> References: <1165339581.20269.249.camel@localhost.localdomain> <4575AFDF.7070403@math.unl.edu> Message-ID: <1165356104.30810.0.camel@localhost.localdomain> On Tue, 2006-12-05 at 11:43 -0600, Rex Dieter wrote: > Tom 'spot' Callaway wrote: > > I drafted a proposal for when it is ok to use Conflicts: (almost never): > > > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > ... > > Fedora Packaging Committee Members should vote via email on this issue, > > Looks sane, +1. Agreed, +1 David From dlutter at redhat.com Tue Dec 5 22:04:39 2006 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 05 Dec 2006 22:04:39 +0000 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <1165353510.21163.105.camel@localhost.localdomain> References: <1165339581.20269.249.camel@localhost.localdomain> <20061205173338.GB14640@nostromo.devel.redhat.com> <1165340459.20269.252.camel@localhost.localdomain> <1165353510.21163.105.camel@localhost.localdomain> Message-ID: <1165356279.30810.4.camel@localhost.localdomain> On Tue, 2006-12-05 at 13:18 -0800, Toshio Kuratomi wrote: > -1 to ask the Steering Committee to audit these on a case by case basis. > Conflicts should be infrequently used, but it's not really something > that I think needs to be evaluated like that. It's not political and > it's not really an abuse of a tag when used correctly. It's a technical > decision and should be worked out by a reviewer and packager. (And > "after importation QA" if we had that.) I had the same hesitation initially - if this is somethign that comes upa lot or slows down reviews, we/FESCo will need to come with a more lightweight way. Though I wouldn't just leave conflicts up to individual reviewers, since they can have bad implications on the useability of the distro as a whole; that's where conflicts deserve more attention than requires (too many requires bloat installs, but don't keep you from using things in parallel). David From pertusus at free.fr Tue Dec 5 22:18:02 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 5 Dec 2006 23:18:02 +0100 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <1165356279.30810.4.camel@localhost.localdomain> References: <1165339581.20269.249.camel@localhost.localdomain> <20061205173338.GB14640@nostromo.devel.redhat.com> <1165340459.20269.252.camel@localhost.localdomain> <1165353510.21163.105.camel@localhost.localdomain> <1165356279.30810.4.camel@localhost.localdomain> Message-ID: <20061205221802.GB2558@free.fr> On Tue, Dec 05, 2006 at 10:04:39PM +0000, David Lutterkort wrote: > On Tue, 2006-12-05 at 13:18 -0800, Toshio Kuratomi wrote: > > I had the same hesitation initially - if this is somethign that comes > upa lot or slows down reviews, we/FESCo will need to come with a more > lightweight way. Though I wouldn't just leave conflicts up to individual > reviewers, since they can have bad implications on the useability of the > distro as a whole; that's where conflicts deserve more attention than > requires (too many requires bloat installs, but don't keep you from > using things in parallel). Many other things can affect the distro as a whole (Provides, for example) but that doesn't mean that FESCO should look over the issue. I am not in the packaging commitee, but I think that conflicts are not unlike other packaging issues and I fail to see why FESCO should be asked for that issue. Having the conflict guidelines in the packaging guidelines (with an example of a case where conflicts is usefull) should be enough in my opinion. And in case of doubt, it seems to me that it is better to ask to the mailing list than too annoy FESCO. -- Pat From Matt_Domsch at dell.com Tue Dec 5 22:34:28 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 5 Dec 2006 16:34:28 -0600 Subject: [Fedora-packaging] sparse 0.2, headers and static lib Message-ID: <20061205223427.GA13345@lists.us.dell.com> sparse 0.2 is out now, and includes header files and a static libsparse.a, but doesn't include a libsparse.so. Jeff Garzik in particular requested the static lib and headers for a project he's working on. So, I added a -devel package and put in the header files and sparse.pc. I've also put libsparse.a in there, but see the proposal for a -static package. Questions: 1) need -devel have a Requires: %{name}-%{version}-${release} if that doesn't include a shared library? I wouldn't think so, but it's a "Must" in the guidelines. 2) need I create a -static package for the static library? 3) if yes, should -static have a Requires: %{name}-devel-%{version}-%{release}? Should this go in the recommendations for all -static packages? Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From tcallawa at redhat.com Tue Dec 5 22:39:33 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 05 Dec 2006 16:39:33 -0600 Subject: [Fedora-packaging] sparse 0.2, headers and static lib In-Reply-To: <20061205223427.GA13345@lists.us.dell.com> References: <20061205223427.GA13345@lists.us.dell.com> Message-ID: <1165358373.20269.343.camel@localhost.localdomain> On Tue, 2006-12-05 at 16:34 -0600, Matt Domsch wrote: > sparse 0.2 is out now, and includes header files and a static > libsparse.a, but doesn't include a libsparse.so. Jeff Garzik in > particular requested the static lib and headers for a project he's > working on. Can you patch sparse so that it builds a shared lib? This would be the ideal scenario. ~spot From Matt_Domsch at dell.com Tue Dec 5 23:14:30 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 5 Dec 2006 17:14:30 -0600 Subject: [Fedora-packaging] sparse 0.2, headers and static lib In-Reply-To: <1165358373.20269.343.camel@localhost.localdomain> References: <20061205223427.GA13345@lists.us.dell.com> <1165358373.20269.343.camel@localhost.localdomain> Message-ID: <20061205231430.GB2285@lists.us.dell.com> On Tue, Dec 05, 2006 at 04:39:33PM -0600, Tom 'spot' Callaway wrote: > On Tue, 2006-12-05 at 16:34 -0600, Matt Domsch wrote: > > sparse 0.2 is out now, and includes header files and a static > > libsparse.a, but doesn't include a libsparse.so. Jeff Garzik in > > particular requested the static lib and headers for a project he's > > working on. > > Can you patch sparse so that it builds a shared lib? This would be the > ideal scenario. Could, yes. This thread (ending here): http://marc.theaimsgroup.com/?l=linux-sparse&m=116330177006275&w=2 notes that sparse as a library isn't really stable at this point, and upstream isn't terribly interested in doing soname bumps all the time, starting compat packages, etc. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Axel.Thimm at ATrpms.net Tue Dec 5 23:32:51 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 6 Dec 2006 00:32:51 +0100 Subject: [Fedora-packaging] static subpackages (was: sparse 0.2, headers and static lib) In-Reply-To: <20061205223427.GA13345@lists.us.dell.com> References: <20061205223427.GA13345@lists.us.dell.com> Message-ID: <20061205233251.GE26443@neu.nirvana> On Tue, Dec 05, 2006 at 04:34:28PM -0600, Matt Domsch wrote: > 2) need I create a -static package for the static library? > > 3) if yes, should -static have a Requires: > %{name}-devel-%{version}-%{release}? Should this go in the > recommendations for all -static packages? static subpackages have been discussed a bit in the recent past, but not by the packaging group. IMHO they make sense if static libs are to be part of the build for whatever reason, but we don't have any rules about it, not even about the naming, e.g. whether it should be called foo-static, foo-devel-static, foo-static-devel and so on. At any rate the "static" subpackage would have to require the conventional devel package to get access to the headers, so 3) above goes w/o saying. But first we would need to decide on how to handle static content in general, e.g. first decide on subpackaging it and then how the packages are to be handled. Just to catch any such discussion beforehand: *Whether* something needs to be statically linked or not, is a policy that is not decided by the packaging committee - we just consider the *how*s and let the *why*s to fesco and core. ;) To cut a long story short: Matt, if you do need a static lib, do as you please for now - we need to sort it out first, and then we'll tell you that it needs to be done differently ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Tue Dec 5 23:32:16 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 05 Dec 2006 15:32:16 -0800 Subject: [Fedora-packaging] Re: Re: iconcache scriptlets In-Reply-To: References: <1165293661.29086.361.camel@localhost.localdomain> <1165348356.21163.52.camel@localhost.localdomain> <4575D104.30809@math.unl.edu> <1165352126.21163.87.camel@localhost.localdomain> Message-ID: <1165361536.21163.163.camel@localhost.localdomain> On Tue, 2006-12-05 at 15:27 -0600, Rex Dieter wrote: > Toshio Kuratomi wrote: > > > On Tue, 2006-12-05 at 14:05 -0600, Rex Dieter wrote: > >> Toshio Kuratomi wrote: > >> > On Tue, 2006-12-05 at 10:06 -0600, Rex Dieter wrote: > >> >> In any case, nothing would break. At worst, gtk apps would suffer a > >> >> performance penalty, at least until gtk2 is fixed: > >> >> http://bugzilla.redhat.com/170335 > >> >> (a personal packaging pet-peave). > >> > >> > Yes. Which is a regression. > >> > I agree that 170335 should be fixed, though. > >> > >> Bingo. Bugs should be addressed in their proper domain, and I would > >> argue strongly that the proper domain in the gtk2 (bug #170335) case is > >> *gtk2*, not Packaging/Guidelines. > > > > We have had and continue to have many pieces of guidelines which are > > held up by or written to account for bugs in support packages (rpm, > > scriptlets in Core packages, etc). > ... > > In this case, I'd be okay with the changes to iconcache with > > or I would have no problem with > 0) hold publication of the new guideline pending one of: > a) wait (indefinitely) until gtk2 bug is fixed > b) give gtk2 maintainer reasonable time to fix (2-4 weeks?), then just do > it. > c) (I'm almost serious): make gtk2-fixbug170335-hack package, and use > Requires(post,postun): gtk2-fixbug170335-hack > (: > I could live with holding the guidelines pending updates to the core packages as well. I'd add d) hicolor-iconcache utilitizes xdg-utils. > If possible, I'd rather avoid complicating the guidelines (and packagers) > lives with the, imo, unecessary extra baggage entailed with 1 or 2, by > introducing a new Requires(post,postun): xdg-utils > But, if the rest of the comittee is agreeable to the idea, I'll play along. > True but there's a good possibility the changes won't be implemented for all versions of FC anyhow. That means that we'll have to carry separate instructions for FCX and FCY no matter what. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Tue Dec 5 23:59:32 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 05 Dec 2006 15:59:32 -0800 Subject: [Fedora-packaging] static subpackages (was: sparse 0.2, headers and static lib) In-Reply-To: <20061205233251.GE26443@neu.nirvana> References: <20061205223427.GA13345@lists.us.dell.com> <20061205233251.GE26443@neu.nirvana> Message-ID: <1165363172.21163.182.camel@localhost.localdomain> On Wed, 2006-12-06 at 00:32 +0100, Axel Thimm wrote: > On Tue, Dec 05, 2006 at 04:34:28PM -0600, Matt Domsch wrote: >> 1) need -devel have a Requires: %{name}-%{version}-${release} if that >> doesn't include a shared library? I wouldn't think so, but it's a >> "Must" in the guidelines. What's in the %{name} package? > > 2) need I create a -static package for the static library? > > Yes. > > > 3) if yes, should -static have a Requires: > > %{name}-devel-%{version}-%{release}? Should this go in the > > recommendations for all -static packages? > I would think yes. Does anyone see a problem with doing that? You also need to writeup your reasons for having a static library in the first place and presenting it to FESCo. The fact that Jeff Garzik wants to use it is a two edged sword -- on the one hand it means there is a need for the library. OTOH, it means that the library is going to be used by multiple programs which is what leads to the security and other problems. The use of -static package names is supposed to help us deal with this but we know it's not a complete job. Jeff's comment that maybe the library is special and shouldn't be subjected to the same ABI tests as the majority of libraries has merit. But we don't have any guidelines in place for that... I don't think we even have guidelines that forbid having that kind of ABI unstable library in the first place. > static subpackages have been discussed a bit in the recent past, but > not by the packaging group. IMHO they make sense if static libs are to > be part of the build for whatever reason, but we don't have any rules > about it, not even about the naming, e.g. whether it should be called > foo-static, foo-devel-static, foo-static-devel and so on. At any rate > the "static" subpackage would have to require the conventional devel > package to get access to the headers, so 3) above goes w/o saying. > > But first we would need to decide on how to handle static content in > general, e.g. first decide on subpackaging it and then how the > packages are to be handled. > > Just to catch any such discussion beforehand: *Whether* something > needs to be statically linked or not, is a policy that is not decided > by the packaging committee - we just consider the *how*s and let the > *why*s to fesco and core. ;) > > To cut a long story short: Matt, if you do need a static lib, do as > you please for now - we need to sort it out first, and then we'll tell > you that it needs to be done differently ;) Actually, I think we voted on this: http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage My memory is backed up by the status on: http://fedoraproject.org/wiki/Packaging/GuidelinesTodo Ralf just needs to move the document into the Packaging tree and update the Guidelines in the proper places :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Wed Dec 6 00:10:21 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 6 Dec 2006 01:10:21 +0100 Subject: [Fedora-packaging] Re: static subpackages (was: sparse 0.2, headers and static lib) In-Reply-To: <1165363172.21163.182.camel@localhost.localdomain> References: <20061205223427.GA13345@lists.us.dell.com> <20061205233251.GE26443@neu.nirvana> <1165363172.21163.182.camel@localhost.localdomain> Message-ID: <20061206001021.GF26443@neu.nirvana> On Tue, Dec 05, 2006 at 03:59:32PM -0800, Toshio Kuratomi wrote: > On Wed, 2006-12-06 at 00:32 +0100, Axel Thimm wrote: > > static subpackages have been discussed a bit in the recent past, but > > not by the packaging group. > Actually, I think we voted on this: > http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage > > My memory is backed up by the status on: > http://fedoraproject.org/wiki/Packaging/GuidelinesTodo Oops, sorry I must have missed that meeting and I'm spreading lies now (I thought I had checked all available minutes when I couldn't make it to a meeting). But it only contains a proposal on the naming of the package, some parts like the intradependencies of subpackages should also be part of the guidelines. Maybe Ralf could extend this part? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Wed Dec 6 00:29:51 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 6 Dec 2006 01:29:51 +0100 Subject: [Fedora-packaging] static subpackages (was: sparse 0.2, headers and static lib) In-Reply-To: <1165363172.21163.182.camel@localhost.localdomain> References: <20061205223427.GA13345@lists.us.dell.com> <20061205233251.GE26443@neu.nirvana> <1165363172.21163.182.camel@localhost.localdomain> Message-ID: <20061206002951.GC2558@free.fr> On Tue, Dec 05, 2006 at 03:59:32PM -0800, Toshio Kuratomi wrote: > > You also need to writeup your reasons for having a static library in the > first place and presenting it to FESCo. The fact that Jeff Garzik wants I know this has allready been voted, but I still think that it is wrong, it is really a technical issue and not a political one as this thread once more shows. static libs are allready discouraged, I don't think it is relevant to ask fesco for inclusion of every lib, packagers should be responsible enough. > to use it is a two edged sword -- on the one hand it means there is a > need for the library. OTOH, it means that the library is going to be > used by multiple programs which is what leads to the security and other > problems. Is libsparse going to be involved in situations where security matters? I guess not? -- Pat From rc040203 at freenet.de Wed Dec 6 03:58:03 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Dec 2006 04:58:03 +0100 Subject: [Fedora-packaging] static subpackages (was: sparse 0.2, headers and static lib) In-Reply-To: <1165363172.21163.182.camel@localhost.localdomain> References: <20061205223427.GA13345@lists.us.dell.com> <20061205233251.GE26443@neu.nirvana> <1165363172.21163.182.camel@localhost.localdomain> Message-ID: <1165377484.23106.54.camel@mccallum.corsepiu.local> On Tue, 2006-12-05 at 15:59 -0800, Toshio Kuratomi wrote: > On Wed, 2006-12-06 at 00:32 +0100, Axel Thimm wrote: > > On Tue, Dec 05, 2006 at 04:34:28PM -0600, Matt Domsch wrote: > >> 1) need -devel have a Requires: %{name}-%{version}-${release} if that > >> doesn't include a shared library? I wouldn't think so, but it's a > >> "Must" in the guidelines. > > What's in the %{name} package? > > > > 2) need I create a -static package for the static library? > > > > Yes. > > > > > 3) if yes, should -static have a Requires: > > > %{name}-devel-%{version}-%{release}? Should this go in the > > > recommendations for all -static packages? > > > I would think yes. Does anyone see a problem with doing that? Basically no. The fundamental idea behind this proposal had been to * make dependencies on static libs visible. * Force packagers _really_ needing to link against static libs to "BR: *-static" in their specs. * Let packages "BR: *-devel" receive as few static libs as possible, to avoid accidentially picking up dependencies on static libs * Using and providing "*-devel" packages is supposed to be the nominal case. Using and providing "*-static" packages should be considered exceptions. Implementation-wise this means: * headers must be provided by "*-devel" packages * static libs must be provided by "*-static" packages * shared libs must be provides by "*-devel" packages => We need to consider at least 3 cases: 1. packages supplying shared libs only - headers in *-devel - shared libs in *-devel 2. packages supplying shared and static libs. - headers in *-devel - shared libs in *-devel - static libs in *-static - *-static must "Requires: *-devel = %{version}-%{release}" 3. packages supplying static libs only. Here I see approaches: 3.1 - headers in *-devel - libs in *-devel - *-devel "Provides: *-static = %{version}-%{release}" IMO, this should be the nominal case. 3.2 - headers in *-static - libs in *-static - *-static "Provides: *-devel = %{version}-%{release}" I would not recommend this variant. Additional complications can arise from "shared/common files" and from config files (E.g. some *.la's and *.pc's are not unlikely to become problematic). They need to be looked after on a case by case basis. > You also need to writeup your reasons for having a static library in the > first place and presenting it to FESCo. The fact that Jeff Garzik wants > to use it is a two edged sword -- on the one hand it means there is a > need for the library. OTOH, it means that the library is going to be > used by multiple programs which is what leads to the security and other > problems. > > The use of -static package names is supposed to help us deal with this > but we know it's not a complete job. > > Jeff's comment that maybe the library is special and shouldn't be > subjected to the same ABI tests as the majority of libraries has merit. > But we don't have any guidelines in place for that... I don't think we > even have guidelines that forbid having that kind of ABI unstable > library in the first place. To me, the only legitimate reasons for _using_ static libs in Fedora should be technical ones. Which ones to allow should be subject of FESCO's decision. So far, I can only imagine two: - Upstream doesn't provide them (Adding shared libs to a package upstream ships static libs only, is a different issue - Often it's more problematic than useful). - Correct function of an applications being used by Fedora requires it. Allowing people to _ship_ static libs in addition to shared libs is a yet another issue. Except that it voids the "reduce Fedora bloat" aspect of the rationale, it's not much of a technical problem for Fedora itself, but a political issue. > > static subpackages have been discussed a bit in the recent past, but > > not by the packaging group. IMHO they make sense if static libs are to > > be part of the build for whatever reason, but we don't have any rules > > about it, not even about the naming, e.g. whether it should be called > > foo-static, foo-devel-static, foo-static-devel and so on. At any rate > > the "static" subpackage would have to require the conventional devel > > package to get access to the headers, so 3) above goes w/o saying. > > > > But first we would need to decide on how to handle static content in > > general, e.g. first decide on subpackaging it and then how the > > packages are to be handled. > > > > Just to catch any such discussion beforehand: *Whether* something > > needs to be statically linked or not, is a policy that is not decided > > by the packaging committee - we just consider the *how*s and let the > > *why*s to fesco and core. ;) > > > > To cut a long story short: Matt, if you do need a static lib, do as > > you please for now - we need to sort it out first, and then we'll tell > > you that it needs to be done differently ;) > > Actually, I think we voted on this: > http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage Yes, FPC had voted unanimously (all attending members voted for it. Ca. 7 out of 9 members had been present), but I don't recall if Axel had been present. All this took place before Ulrich Drepper jumped onto the wagon and before the "Fedora Summit", so ... > My memory is backed up by the status on: > http://fedoraproject.org/wiki/Packaging/GuidelinesTodo > > Ralf just needs to move the document into the Packaging tree and update > the Guidelines in the proper places :-) Am I supposed to do so? I thought somebody was to supposed to present this to FESCO and then he would give me a ping to merge it or he would merge it. Anyway, no problem, I can merge it, when I can find a free time slot. Ralf From rc040203 at freenet.de Wed Dec 6 04:29:00 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Dec 2006 05:29:00 +0100 Subject: [Fedora-packaging] Re: static subpackages (was: sparse 0.2, headers and static lib) In-Reply-To: <20061206001021.GF26443@neu.nirvana> References: <20061205223427.GA13345@lists.us.dell.com> <20061205233251.GE26443@neu.nirvana> <1165363172.21163.182.camel@localhost.localdomain> <20061206001021.GF26443@neu.nirvana> Message-ID: <1165379340.23106.69.camel@mccallum.corsepiu.local> On Wed, 2006-12-06 at 01:10 +0100, Axel Thimm wrote: > On Tue, Dec 05, 2006 at 03:59:32PM -0800, Toshio Kuratomi wrote: > > On Wed, 2006-12-06 at 00:32 +0100, Axel Thimm wrote: > > > static subpackages have been discussed a bit in the recent past, but > > > not by the packaging group. > > > Actually, I think we voted on this: > > http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage > > > > My memory is backed up by the status on: > > http://fedoraproject.org/wiki/Packaging/GuidelinesTodo > > Oops, sorry I must have missed that meeting and I'm spreading lies now > (I thought I had checked all available minutes when I couldn't make it > to a meeting). > > But it only contains a proposal on the naming of the package, some > parts like the intradependencies of subpackages should also be part of > the guidelines. This was intentional - I wanted us to focus on "-devel" and "-static" and to prevent us from getting lost into discussions on details. > Maybe Ralf could extend this part? Could be done - C.f. my other mail. I could add this as a "recommendation section" to the proposal, if there should be consensus about this. However, I don't want to end up in threads discussing all glory details of sorting out "shared/commons" packages or to see people starting nit-picking on package names, packages might have inherited from their history, nor do I see much use in us trying to detail all implications this might have on packaging in practice in advance. If there should be problems, they'll pop up sooner or later and can be solved then. Ralf From rdieter at math.unl.edu Wed Dec 6 04:51:38 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 05 Dec 2006 22:51:38 -0600 Subject: [Fedora-packaging] Re: iconcache scriptlets In-Reply-To: <1165352126.21163.87.camel@localhost.localdomain> References: <1165293661.29086.361.camel@localhost.localdomain> <1165348356.21163.52.camel@localhost.localdomain> <4575D104.30809@math.unl.edu> <1165352126.21163.87.camel@localhost.localdomain> Message-ID: Toshio Kuratomi wrote: > On Tue, 2006-12-05 at 14:05 -0600, Rex Dieter wrote: > In this case, I'd be okay with the changes to iconcache with > 1) the addition of Requires(post): xdg-utils I forgot to mention, that this approach must be special-case, to only be for Extras packages, since xdg-utils isn't in Core (yet). My original proposal applies equally well to all Core/Extras packages, for any FC release. -- Rex From Matt_Domsch at dell.com Wed Dec 6 04:44:18 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 5 Dec 2006 22:44:18 -0600 Subject: [Fedora-packaging] static subpackages (was: sparse 0.2, headers and static lib) In-Reply-To: <1165363172.21163.182.camel@localhost.localdomain> References: <20061205223427.GA13345@lists.us.dell.com> <20061205233251.GE26443@neu.nirvana> <1165363172.21163.182.camel@localhost.localdomain> Message-ID: <20061206044418.GA2365@lists.us.dell.com> On Tue, Dec 05, 2006 at 03:59:32PM -0800, Toshio Kuratomi wrote: > On Wed, 2006-12-06 at 00:32 +0100, Axel Thimm wrote: > > On Tue, Dec 05, 2006 at 04:34:28PM -0600, Matt Domsch wrote: > >> 1) need -devel have a Requires: %{name}-%{version}-${release} if that > >> doesn't include a shared library? I wouldn't think so, but it's a > >> "Must" in the guidelines. > > What's in the %{name} package? $ rpm -qpl sparse-0.2-1.x86_64.rpm /usr/bin/cgcc /usr/bin/sparse /usr/share/doc/sparse-0.2 /usr/share/doc/sparse-0.2/FAQ /usr/share/doc/sparse-0.2/LICENSE /usr/share/doc/sparse-0.2/README i.e. no libsparse.so, and nothing that a -devel package needs. So I don't see the need for a dependency here. > > > 2) need I create a -static package for the static library? > > > > Yes. > > > > > 3) if yes, should -static have a Requires: > > > %{name}-devel-%{version}-%{release}? Should this go in the > > > recommendations for all -static packages? > > > I would think yes. Does anyone see a problem with doing that? So 3 is yes, no real problem there. Here's what -devel provides: $ rpm -qpl sparse-devel-0.2-1.x86_64.rpm /usr/include/sparse /usr/include/sparse/allocate.h /usr/include/sparse/bitmap.h /usr/include/sparse/compat.h /usr/include/sparse/dissect.h /usr/include/sparse/expression.h /usr/include/sparse/flow.h /usr/include/sparse/ident-list.h /usr/include/sparse/lib.h /usr/include/sparse/linearize.h /usr/include/sparse/parse.h /usr/include/sparse/ptrlist.h /usr/include/sparse/scope.h /usr/include/sparse/storage.h /usr/include/sparse/symbol.h /usr/include/sparse/target.h /usr/include/sparse/token.h /usr/lib64/libsparse.a /usr/lib64/pkgconfig/sparse.pc /usr/share/doc/sparse-devel-0.2 /usr/share/doc/sparse-devel-0.2/LICENSE but I'll move libsparse.a into its own -static package. > You also need to writeup your reasons for having a static library in the > first place and presenting it to FESCo. The fact that Jeff Garzik wants > to use it is a two edged sword -- on the one hand it means there is a > need for the library. OTOH, it means that the library is going to be > used by multiple programs which is what leads to the security and other > problems. as noted, it's not a big security concern for this development app usage. > The use of -static package names is supposed to help us deal with this > but we know it's not a complete job. > > Jeff's comment that maybe the library is special and shouldn't be > subjected to the same ABI tests as the majority of libraries has merit. > But we don't have any guidelines in place for that... I don't think we > even have guidelines that forbid having that kind of ABI unstable > library in the first place. It's the instability of the API/ABI that keeps the project from wanting to expose a versioned shared library. That's more work than it's ready to maintain; Jeff's fine with it being fluid and changing his own app accordingly. I hadn't packaged the shared lib in earlier versions because nothing else needed it; now that something does, that doesn't mean the API needs to be versioned, except that shared libs would require that overhead. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Wed Dec 6 04:53:41 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 5 Dec 2006 22:53:41 -0600 Subject: [Fedora-packaging] static subpackages (was: sparse 0.2, headers and static lib) In-Reply-To: <1165377484.23106.54.camel@mccallum.corsepiu.local> References: <20061205223427.GA13345@lists.us.dell.com> <20061205233251.GE26443@neu.nirvana> <1165363172.21163.182.camel@localhost.localdomain> <1165377484.23106.54.camel@mccallum.corsepiu.local> Message-ID: <20061206045341.GB2365@lists.us.dell.com> On Wed, Dec 06, 2006 at 04:58:03AM +0100, Ralf Corsepius wrote: > 3.1 > - headers in *-devel > - libs in *-devel > - *-devel "Provides: *-static = %{version}-%{release}" > IMO, this should be the nominal case. OK, I've done this instead now. > > 3.2 > - headers in *-static > - libs in *-static > - *-static "Provides: *-devel = %{version}-%{release}" > I would not recommend this variant. > > > Additional complications can arise from "shared/common files" and from > config files (E.g. some *.la's and *.pc's are not unlikely to become > problematic). They need to be looked after on a case by case basis. It's annoying that the .pc file includes a libdir=/usr/lib64, else a -devel (without the .a) could be noarch. :-( As it stands, we won't be able to install the -devel as multi-arch because all the .h files will conflict. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From jeff at ocjtech.us Wed Dec 6 04:56:21 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 05 Dec 2006 22:56:21 -0600 Subject: [Fedora-packaging] static subpackages (was: sparse 0.2, headers and static lib) In-Reply-To: <20061206044418.GA2365@lists.us.dell.com> References: <20061205223427.GA13345@lists.us.dell.com> <20061205233251.GE26443@neu.nirvana> <1165363172.21163.182.camel@localhost.localdomain> <20061206044418.GA2365@lists.us.dell.com> Message-ID: <1165380981.3291.6.camel@lt21223.campus.dmacc.edu> On Tue, 2006-12-05 at 22:44 -0600, Matt Domsch wrote: > > Here's what -devel provides: > > $ rpm -qpl sparse-devel-0.2-1.x86_64.rpm > ... > /usr/lib64/libsparse.a > /usr/lib64/pkgconfig/sparse.pc > ... > > but I'll move libsparse.a into its own -static package. What about the pkg-config file? Where should that go? Since there's no shared library, the -devel package is pretty useless without the -static package. Until there is a shared library maybe the -devel package should require the -static package (and vice-versa). Jeff -------------- 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 a.badger at gmail.com Wed Dec 6 05:06:32 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 05 Dec 2006 21:06:32 -0800 Subject: [Fedora-packaging] static subpackages (was: sparse 0.2, headers and static lib) In-Reply-To: <20061206045341.GB2365@lists.us.dell.com> References: <20061205223427.GA13345@lists.us.dell.com> <20061205233251.GE26443@neu.nirvana> <1165363172.21163.182.camel@localhost.localdomain> <1165377484.23106.54.camel@mccallum.corsepiu.local> <20061206045341.GB2365@lists.us.dell.com> Message-ID: <1165381592.21163.199.camel@localhost.localdomain> On Tue, 2006-12-05 at 22:53 -0600, Matt Domsch wrote: > On Wed, Dec 06, 2006 at 04:58:03AM +0100, Ralf Corsepius wrote: > > > > Additional complications can arise from "shared/common files" and from > > config files (E.g. some *.la's and *.pc's are not unlikely to become > > problematic). They need to be looked after on a case by case basis. > > It's annoying that the .pc file includes a libdir=/usr/lib64, else a > -devel (without the .a) could be noarch. :-( As it stands, we won't > be able to install the -devel as multi-arch because all the .h files > will conflict. > Even then it can't be noarch. rpm(build) doesn't allow different archs for different subpackages. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Matt_Domsch at dell.com Wed Dec 6 05:10:09 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 5 Dec 2006 23:10:09 -0600 Subject: [Fedora-packaging] static subpackages (was: sparse 0.2, headers and static lib) In-Reply-To: <20061206045341.GB2365@lists.us.dell.com> References: <20061205223427.GA13345@lists.us.dell.com> <20061205233251.GE26443@neu.nirvana> <1165363172.21163.182.camel@localhost.localdomain> <1165377484.23106.54.camel@mccallum.corsepiu.local> <20061206045341.GB2365@lists.us.dell.com> Message-ID: <20061206051009.GC2365@lists.us.dell.com> On Tue, Dec 05, 2006 at 10:53:41PM -0600, Matt Domsch wrote: > On Wed, Dec 06, 2006 at 04:58:03AM +0100, Ralf Corsepius wrote: > > 3.1 > > - headers in *-devel > > - libs in *-devel > > - *-devel "Provides: *-static = %{version}-%{release}" > > IMO, this should be the nominal case. > > OK, I've done this instead now. http://domsch.com/linux/fedora/extras/sparse/0.2/ now has the spec I'm planning to use and RPMs that are built from it. I'd appreciate a sanity check based on this conversation. What's the process to take this to FESCo for approval? Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From a.badger at gmail.com Wed Dec 6 05:11:39 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 05 Dec 2006 21:11:39 -0800 Subject: [Fedora-packaging] Re: iconcache scriptlets In-Reply-To: References: <1165293661.29086.361.camel@localhost.localdomain> <1165348356.21163.52.camel@localhost.localdomain> <4575D104.30809@math.unl.edu> <1165352126.21163.87.camel@localhost.localdomain> Message-ID: <1165381899.21163.203.camel@localhost.localdomain> On Tue, 2006-12-05 at 22:51 -0600, Rex Dieter wrote: > Toshio Kuratomi wrote: > > On Tue, 2006-12-05 at 14:05 -0600, Rex Dieter wrote: > > > In this case, I'd be okay with the changes to iconcache with > > 1) the addition of Requires(post): xdg-utils > > I forgot to mention, that this approach must be special-case, to only be > for Extras packages, since xdg-utils isn't in Core (yet). > > My original proposal applies equally well to all Core/Extras packages, > for any FC release. My feeling is it's broken on Core since xdg-utils isn't present there. My proposal forces the issue. If you have to Requires(post): xdg-utils, you have to have it in Core (or the Core equivalent). -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Wed Dec 6 06:31:59 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Dec 2006 07:31:59 +0100 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <1165339581.20269.249.camel@localhost.localdomain> References: <1165339581.20269.249.camel@localhost.localdomain> Message-ID: <1165386719.23106.78.camel@mccallum.corsepiu.local> On Tue, 2006-12-05 at 11:26 -0600, Tom 'spot' Callaway wrote: > I drafted a proposal for when it is ok to use Conflicts: (almost never): > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts +1, except one detail: > There are many types of files which can conflict between multiple > packages. Instead of using Conflicts:, try the following: > > * man page name conflicts: Rename the man pages to include a prefix of > the providing package (e.g. foo-check.1.gz vs check.1.gz) IMO, this example is bogus: Man-pages should always be named after what they are trying to document, i.e. section 1 mans must be named after the application. => Documenting /usr/bin/check in a man-page named foo-check.1 because it conflicts with /bin/check's man-page is a no-go. Better, change the man-pages suffix, or change the name of the application and the name of man-page at the same time. Ralf From enrico.scholz at informatik.tu-chemnitz.de Wed Dec 6 07:27:58 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 06 Dec 2006 08:27:58 +0100 Subject: [Fedora-packaging] sparse 0.2, headers and static lib In-Reply-To: <20061205223427.GA13345@lists.us.dell.com> (Matt Domsch's message of "Tue, 5 Dec 2006 16:34:28 -0600") References: <20061205223427.GA13345@lists.us.dell.com> Message-ID: <87ac21scu9.fsf@kosh.bigo.ensc.de> Matt_Domsch at dell.com (Matt Domsch) writes: > 1) need -devel have a Requires: %{name}-%{version}-${release} if that > doesn't include a shared library? I wouldn't think so, but it's a > "Must" in the guidelines. > ... > 3) if yes, should -static have a Requires: > %{name}-devel-%{version}-%{release}? Should this go in the > recommendations for all -static packages? -static (and -debuginfo) are good candidates for: | Conflicts: %name < %version-%release | Conflicts: %name > %version-%release This prevents version mix without adding unneeded Requires: Enrico From enrico.scholz at informatik.tu-chemnitz.de Wed Dec 6 07:39:26 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 06 Dec 2006 08:39:26 +0100 Subject: [Fedora-packaging] Re: Re: iconcache scriptlets In-Reply-To: (Rex Dieter's message of "Tue, 05 Dec 2006 12:59:12 -0600") References: <87ac22eotd.fsf@kosh.bigo.ensc.de> <87lklmrxpq.fsf@kosh.bigo.ensc.de> Message-ID: <8764cpscb5.fsf@kosh.bigo.ensc.de> rdieter at math.unl.edu (Rex Dieter) writes: >>>> Why the 'touch' stuff? >>> >>> The fdo spec mandates the timestamp of the installed-to icon dir >>> *must* be updated. >> >> What is a 'fdo spec'? > > http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#implementation_notes Oh, I see. The 'touch' makes a differences when user installed a 3rd party application with a 3rd party toolkit which is following freedesktop.org iconcache-recommendations. >> | gtk-update-icon-cache --quiet --force %{_datadir}/icons/hicolor || : >> vs. >> | touch --no-create %{_datadir}/icons/hicolor || : >> | %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : >> would led to your conclusion. > > Consider the case that gtk2 (and gtk-update-icon-cache) is not present at > install-time (since we currently don't Requires(post,postun): gtk2), Please don't write 'Requires(post,postun):'; dunno whether you meant it symbolically only. But it's wrong and sickly. > then the icondir timestamp will fail to be updated. This would not make a difference: in both cases ('touch' and '--force') the iconcache will be updated in the same manner during the installation of 'gtk-update-icon-cache'. Currently (with FC5 gtk2), icon-cache won't be updated because gtk2's scriptlets do not call 'gtk-update-icon-cache'. Enrico From bugs.michael at gmx.net Wed Dec 6 11:28:03 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Dec 2006 12:28:03 +0100 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <87hcwarxcr.fsf@kosh.bigo.ensc.de> References: <1165339581.20269.249.camel@localhost.localdomain> <87hcwarxcr.fsf@kosh.bigo.ensc.de> Message-ID: <20061206122803.52239d44.bugs.michael@gmx.net> On Tue, 05 Dec 2006 19:50:12 +0100, Enrico Scholz wrote: > "Tom 'spot' Callaway" writes: > > > I drafted a proposal for when it is ok to use Conflicts: (almost never): > > > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > > The statement > > | My package, foo-game doesn't work when bar is older than 1.2.3. > | WRONG: Conflicts: bar < 1.2.3 > | RIGHT: Requires: bar >= 1.2.3 > > is wrong and should be the opposite. There should not be added a Requires: > when package 'foo' works without 'bar' but fails with 'bar < 1.2.3'. > > > Popular example is the 'kernel' package. Lot of packages won't work with > kernel 2.4 but it would be wrong to Require: the 'kernel' package. What does Anaconda do during a dist upgrade in that case? From enrico.scholz at informatik.tu-chemnitz.de Wed Dec 6 12:08:21 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 06 Dec 2006 13:08:21 +0100 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <20061206122803.52239d44.bugs.michael@gmx.net> (Michael Schwendt's message of "Wed, 6 Dec 2006 12:28:03 +0100") References: <1165339581.20269.249.camel@localhost.localdomain> <87hcwarxcr.fsf@kosh.bigo.ensc.de> <20061206122803.52239d44.bugs.michael@gmx.net> Message-ID: <87hcw9tefe.fsf@fc5.bigo.ensc.de> bugs.michael at gmx.net (Michael Schwendt) writes: >> Popular example is the 'kernel' package. Lot of packages won't work with >> kernel 2.4 but it would be wrong to Require: the 'kernel' package. > > What does Anaconda do during a dist upgrade in that case? dunno; correct thing would be to abort the transaction or ask the user whether he wants to remove the old kernel during the transaction. Enrico From rdieter at math.unl.edu Wed Dec 6 13:10:41 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Dec 2006 07:10:41 -0600 Subject: [Fedora-packaging] Re: iconcache scriptlets In-Reply-To: <1165381899.21163.203.camel@localhost.localdomain> References: <1165293661.29086.361.camel@localhost.localdomain> <1165348356.21163.52.camel@localhost.localdomain> <4575D104.30809@math.unl.edu> <1165352126.21163.87.camel@localhost.localdomain> <1165381899.21163.203.camel@localhost.localdomain> Message-ID: <4576C151.4030001@math.unl.edu> Toshio Kuratomi wrote: > On Tue, 2006-12-05 at 22:51 -0600, Rex Dieter wrote: >> Toshio Kuratomi wrote: >>> On Tue, 2006-12-05 at 14:05 -0600, Rex Dieter wrote: >>> In this case, I'd be okay with the changes to iconcache with >>> 1) the addition of Requires(post): xdg-utils >> I forgot to mention, that this approach must be special-case, to only be >> for Extras packages, since xdg-utils isn't in Core (yet). >> >> My original proposal applies equally well to all Core/Extras packages, >> for any FC release. > > My feeling is it's broken on Core since xdg-utils isn't present there. If by "broken", you *really* mean: "regressing" causing gtk2 app performance degradation until gtk2 is fixed, then yes. > My proposal forces the issue. If you have to Requires(post): xdg-utils, > you have to have it in Core (or the Core equivalent). Force what? It is impossible to get xdg-utils into pre FC-7 Core. That's why I mentioned it would have to be an (imo overly complicated) special-case for FC-7+ only. -- Rex From rdieter at math.unl.edu Wed Dec 6 13:18:10 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Dec 2006 07:18:10 -0600 Subject: [Fedora-packaging] Re: Re: iconcache scriptlets In-Reply-To: <8764cpscb5.fsf@kosh.bigo.ensc.de> References: <87ac22eotd.fsf@kosh.bigo.ensc.de> <87lklmrxpq.fsf@kosh.bigo.ensc.de> <8764cpscb5.fsf@kosh.bigo.ensc.de> Message-ID: <4576C312.5010506@math.unl.edu> Enrico Scholz wrote: > rdieter at math.unl.edu (Rex Dieter) writes: > >>>>> Why the 'touch' stuff? >>>> The fdo spec mandates the timestamp of the installed-to icon dir >>>> *must* be updated. >>> What is a 'fdo spec'? >> http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#implementation_notes > > Oh, I see. The 'touch' makes a differences when user installed a 3rd party > application with a 3rd party toolkit which is following freedesktop.org > iconcache-recommendations. Take 3rd party of it. This includes *all* apps using *any* toolkit. >>> | gtk-update-icon-cache --quiet --force %{_datadir}/icons/hicolor || : >>> vs. >>> | touch --no-create %{_datadir}/icons/hicolor || : >>> | %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : >>> would led to your conclusion. >> Consider the case that gtk2 (and gtk-update-icon-cache) is not present at >> install-time (since we currently don't Requires(post,postun): gtk2), > > Please don't write 'Requires(post,postun):'; dunno whether you meant it > symbolically only. But it's wrong and sickly. It's simply shorter than writing (the more proper and working): Requires(post): gtk2 Requires(postun): gtk2 >> then the icondir timestamp will fail to be updated. > > This would not make a difference: in both cases ('touch' and '--force') > the iconcache will be updated in the same manner during the installation > of 'gtk-update-icon-cache'. OK, I'll say it one more time: Lacking Requires(post): gtk2 Requires(postun): gtk2 *gtk2 may not be present at install-time*. As such, gtk-update-icon-cache present in scriplets may not get run, thus, the icondir timestamp may not get updated. Am I missing something? > Currently (with FC5 gtk2), icon-cache won't be updated because gtk2's > scriptlets do not call 'gtk-update-icon-cache'. Neither does *any* gtk2 release, for that matter. That's related to the gtk2 bug, that our currently scriplets are covering up. I'm concerned that the bug will never get fixed or get the attention it deserves if the bandaid is never (threatened to be) removed. -- Rex From rdieter at math.unl.edu Wed Dec 6 13:32:10 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Dec 2006 07:32:10 -0600 Subject: [Fedora-packaging] Re: Re: iconcache scriptlets In-Reply-To: <4576C312.5010506@math.unl.edu> References: <87ac22eotd.fsf@kosh.bigo.ensc.de> <87lklmrxpq.fsf@kosh.bigo.ensc.de> <8764cpscb5.fsf@kosh.bigo.ensc.de> <4576C312.5010506@math.unl.edu> Message-ID: <4576C65A.8070302@math.unl.edu> Rex Dieter wrote: > Enrico Scholz wrote: >> rdieter at math.unl.edu (Rex Dieter) writes: >> >>>>>> Why the 'touch' stuff? >>>>> The fdo spec mandates the timestamp of the installed-to icon dir >>>>> *must* be updated. >>>> What is a 'fdo spec'? >>> http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#implementation_notes >>> >> >> Oh, I see. The 'touch' makes a differences when user installed a 3rd >> party >> application with a 3rd party toolkit which is following freedesktop.org >> iconcache-recommendations. > > Take 3rd party of it. This includes *all* apps using *any* toolkit. Sorry, meant to say: take 3rd party out of it. -- Rex From chris.stone at gmail.com Wed Dec 6 13:37:46 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 6 Dec 2006 05:37:46 -0800 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <1165386719.23106.78.camel@mccallum.corsepiu.local> References: <1165339581.20269.249.camel@localhost.localdomain> <1165386719.23106.78.camel@mccallum.corsepiu.local> Message-ID: On 12/5/06, Ralf Corsepius wrote: > On Tue, 2006-12-05 at 11:26 -0600, Tom 'spot' Callaway wrote: > > I drafted a proposal for when it is ok to use Conflicts: (almost never): > > > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > > +1, except one detail: > > > There are many types of files which can conflict between multiple > > packages. Instead of using Conflicts:, try the following: > > > > * man page name conflicts: Rename the man pages to include a prefix of > > the providing package (e.g. foo-check.1.gz vs check.1.gz) > > IMO, this example is bogus: Man-pages should always be named after what > they are trying to document, i.e. section 1 mans must be named after the > application. > > => Documenting /usr/bin/check in a man-page named foo-check.1 because it > conflicts with /bin/check's man-page is a no-go. > > > Better, change the man-pages suffix, or change the name of the > application and the name of man-page at the same time. Perhaps a better example would be a .3 man page such as: man3/foo.3.gz vs. man3/bar::foo.3.gz -Chris From ville.skytta at iki.fi Wed Dec 6 13:20:44 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 06 Dec 2006 15:20:44 +0200 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <1165339581.20269.249.camel@localhost.localdomain> References: <1165339581.20269.249.camel@localhost.localdomain> Message-ID: <1165411244.25942.27.camel@viper.local> On Tue, 2006-12-05 at 11:26 -0600, Tom 'spot' Callaway wrote: > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts "library name conflicts: Put the library in a subdirectory of /usr/lib or /lib and include a ld.so.conf file." The ld.so.conf part does not sound good to me. While it would avoid the low level conflict, doesn't adding the new subdir to ld.so.conf mean that we now have two different libs with the same name in the linker's default path - which one to load in which situations? I suppose instead of global ld.so.conf, RPATH in apps that require the subdir'd lib would be a better solution, but hopefully someone can point out an even better one? From rc040203 at freenet.de Wed Dec 6 14:17:22 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Dec 2006 15:17:22 +0100 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: References: <1165339581.20269.249.camel@localhost.localdomain> <1165386719.23106.78.camel@mccallum.corsepiu.local> Message-ID: <1165414642.23106.98.camel@mccallum.corsepiu.local> On Wed, 2006-12-06 at 05:37 -0800, Christopher Stone wrote: > On 12/5/06, Ralf Corsepius wrote: > > On Tue, 2006-12-05 at 11:26 -0600, Tom 'spot' Callaway wrote: > > > I drafted a proposal for when it is ok to use Conflicts: (almost never): > > > > > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > > > > +1, except one detail: > > > > > There are many types of files which can conflict between multiple > > > packages. Instead of using Conflicts:, try the following: > > > > > > * man page name conflicts: Rename the man pages to include a prefix of > > > the providing package (e.g. foo-check.1.gz vs check.1.gz) > > > > IMO, this example is bogus: Man-pages should always be named after what > > they are trying to document, i.e. section 1 mans must be named after the > > application. > > > > => Documenting /usr/bin/check in a man-page named foo-check.1 because it > > conflicts with /bin/check's man-page is a no-go. > > > > > > Better, change the man-pages suffix, or change the name of the > > application and the name of man-page at the same time. > > Perhaps a better example would be a .3 man page such as: > > man3/foo.3.gz vs. man3/bar::foo.3.gz Much easier, simply append something to the man suffix: man1/check.1foo.gz It's the traditional way many *nixes circumvented this problem. For a real world example in FE cf. Coin2 and Inventor (Both implement the same API and therefore naturally must conflict). Ralf From enrico.scholz at informatik.tu-chemnitz.de Wed Dec 6 14:57:53 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 06 Dec 2006 15:57:53 +0100 Subject: [Fedora-packaging] Re: Re: iconcache scriptlets In-Reply-To: <4576C312.5010506@math.unl.edu> (Rex Dieter's message of "Wed, 06 Dec 2006 07:18:10 -0600") References: <87ac22eotd.fsf@kosh.bigo.ensc.de> <87lklmrxpq.fsf@kosh.bigo.ensc.de> <8764cpscb5.fsf@kosh.bigo.ensc.de> <4576C312.5010506@math.unl.edu> Message-ID: <87d56xt6ku.fsf@fc5.bigo.ensc.de> rdieter at math.unl.edu (Rex Dieter) writes: >>>>>> Why the 'touch' stuff? >>>>> The fdo spec mandates the timestamp of the installed-to icon dir >>>>> *must* be updated. >>>> What is a 'fdo spec'? >>> http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#implementation_notes >> Oh, I see. The 'touch' makes a differences when user installed a >> 3rd party application with a 3rd party toolkit which is following >> freedesktop.org iconcache-recommendations. > > Take 3rd party of it. This includes *all* apps using *any* toolkit. Does gtk1, QT or wxWindows implement the freedesktop icon caching? >>> then the icondir timestamp will fail to be updated. >> This would not make a difference: in both cases ('touch' and '--force') >> the iconcache will be updated in the same manner during the installation >> of 'gtk-update-icon-cache'. > > OK, I'll say it one more time: Lacking > Requires(post): gtk2 > Requires(postun): gtk2 > *gtk2 may not be present at install-time*. As such, > gtk-update-icon-cache present in scriplets may not get run, thus, the > icondir timestamp may not get updated. > > Am I missing something? yes; the timestamp itself is important for gtk (and other toolkits following the freedesktop recommendations) only. Not touching the timestamp would cause only currently running 3rd party apps (using such a toolkit) not to recognize the new icons. Enrico From rdieter at math.unl.edu Wed Dec 6 15:07:27 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Dec 2006 09:07:27 -0600 Subject: [Fedora-packaging] Re: Re: Re: iconcache scriptlets References: <87ac22eotd.fsf@kosh.bigo.ensc.de> <87lklmrxpq.fsf@kosh.bigo.ensc.de> <8764cpscb5.fsf@kosh.bigo.ensc.de> <4576C312.5010506@math.unl.edu> <87d56xt6ku.fsf@fc5.bigo.ensc.de> Message-ID: Enrico Scholz wrote: > rdieter at math.unl.edu (Rex Dieter) writes: > >>>>>>> Why the 'touch' stuff? >>>>>> The fdo spec mandates the timestamp of the installed-to icon dir >>>>>> *must* be updated. >>>>> What is a 'fdo spec'? >>>> http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#implementation_notes >>> Oh, I see. The 'touch' makes a differences when user installed a >>> 3rd party application with a 3rd party toolkit which is following >>> freedesktop.org iconcache-recommendations. >> >> Take 3rd party of it. This includes *all* apps using *any* toolkit. > > Does gtk1, QT or wxWindows implement the freedesktop icon caching? kde does, the others, dunno, but imo, doesn't matter. Fact is, any toolkit *could* implement caching, and the standard mandates that in order for any caching implementation to work, the timestamp must be updated. I hope you're not suggesting that it be ok to purposely not follow the standard. >>>> then the icondir timestamp will fail to be updated. >>> This would not make a difference: in both cases ('touch' and '--force') >>> the iconcache will be updated in the same manner during the installation >>> of 'gtk-update-icon-cache'. >> >> OK, I'll say it one more time: Lacking >> Requires(post): gtk2 >> Requires(postun): gtk2 >> *gtk2 may not be present at install-time*. As such, >> gtk-update-icon-cache present in scriplets may not get run, thus, the >> icondir timestamp may not get updated. >> >> Am I missing something? > > yes; the timestamp itself is important for gtk (and other toolkits > following the freedesktop recommendations) only. Of course, that's a given. > Not touching the > timestamp would cause only currently running 3rd party apps (using > such a toolkit) not to recognize the new icons. Wrong, it would (ok, could, depending on imlementation) cause any app (currently running or not), using any toolkit (that supports the fdo) spec to not recognize the new icons. -- Rex From rdieter at math.unl.edu Wed Dec 6 19:33:34 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Dec 2006 13:33:34 -0600 Subject: [Fedora-packaging] Re: Re: Re: iconcache scriptlets In-Reply-To: References: <87ac22eotd.fsf@kosh.bigo.ensc.de> <87lklmrxpq.fsf@kosh.bigo.ensc.de> <8764cpscb5.fsf@kosh.bigo.ensc.de> <4576C312.5010506@math.unl.edu> <87d56xt6ku.fsf@fc5.bigo.ensc.de> Message-ID: <45771B0E.4060403@math.unl.edu> Rex Dieter wrote: > Enrico Scholz wrote: >> Not touching the >> timestamp would cause only currently running 3rd party apps (using >> such a toolkit) not to recognize the new icons. > > Wrong, it would (ok, could, depending on imlementation) cause any app > (currently running or not), using any toolkit (that supports the fdo) spec > to not recognize the new icons. After re-reading what you said, my only objections were your use of 'only currently running' and '3rd party'. Take those out, and we're pretty much on the same page. -- Rex From Axel.Thimm at ATrpms.net Thu Dec 7 11:58:24 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 7 Dec 2006 12:58:24 +0100 Subject: [Fedora-packaging] Re: LSB/FSG's packaging summit on Wed, Dec 6th In-Reply-To: <1165274543.17513.6.camel@cutter> References: <20061204230559.GD26239@neu.nirvana> <1165274543.17513.6.camel@cutter> Message-ID: <20061207115824.GC21989@neu.nirvana> Hi, On Mon, Dec 04, 2006 at 06:22:23PM -0500, seth vidal wrote: > On Tue, 2006-12-05 at 00:05 +0100, Axel Thimm wrote: > > the Free Standards Group will have its first packaging summit on > > Wednesday: > > > > http://www.freestandards.org/en/LSB_face-to-face_(December_2006) > > > > Some people from RH/Fedora like Paul Nasrat and Seth Vidal will be > > attending and presenting/discussing rpm and yum. Since I live a couple > > of blocks away I'll try to sneak in, if possible ;) > > You live a couple blocks away? If you'd like to meet up for a meal one > night drop me an email. I both met Seth & Paul, as well made it through SAP security blocks to the summit :=) The focus at the summit was on the interaction between ISVs and distributions. ISVs want to have installers to control the user experience while dumping their files on disk, but still want the files to appear as having been installed through a package. The net result was that a very bare-bone cross-distribution API should be created and blessed into the LSB that ISV installers can use to query the package databases and then register/unregister their own "packages". That seems to keep everyone happy as a first step: ISVs have a better way to communicate with the native layers, distros have a well-defined way of what an ISV packages may or may not do, and the user can use rpm/yum queries to check what ISV packages exist on his system. Other than Red Hat/Fedora there were distribution representatives from Novel, Debian, Ubuntu and Xemian. There were presentations from the distros on their package management methods and presentations from depsolver tools/package managers. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sat Dec 9 19:15:19 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 09 Dec 2006 20:15:19 +0100 Subject: [Fedora-packaging] scriptlets for user creation needed Message-ID: <457B0B47.5010407@leemhuis.info> Hi All! thias and I had a small discussion on how to create handle useradd in specfile scriptlets. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217902#c3 and for details and http://cvs.fedora.redhat.com/viewcvs/rpms/frozen-bubble/FC-6/frozen-bubble.spec?root=extras&rev=1.5&view=markup for the spec and the current solution. Is not really a serious issue, but we should IMHO solve it once and for all. Currently this two commands /usr/sbin/useradd -r -s /sbin/nologin -d / fbubble &>/dev/null || : /sbin/chkconfig --add fb-server are executed in frozen-bubble-server's %post each time -- e.g. not only on install but also on each update. That should do no harm, but looks a bit unclean IMHO. We should find a better scheme and put a template up somewhere that people can simply use -- otherwise we'll end with multiple slightly different solutions in our packages that trigger different bugs. I know there were (and probably still are) disagreements on how to install users in rpm files, but we should find a solution about as the current situation sucks. Could the PC at least work out an example on how to create users without ensc's stuff for now and put that up on http://www.fedoraproject.org/wiki/Packaging/ScriptletSnippets The we can search for the one and only proper solution later. Cu thl From philipp_subx at redfish-solutions.com Sun Dec 10 22:50:06 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Sun, 10 Dec 2006 15:50:06 -0700 Subject: [Fedora-packaging] Re: RPM weirdness [moved from fedora-list] In-Reply-To: <457C8A75.2050309@redfish-solutions.com> References: <457C7271.1040600@redfish-solutions.com> <20061210165525.1qynvbr084ocg0ck@horde.dpniner.net> <457C8A75.2050309@redfish-solutions.com> Message-ID: <457C8F1E.609@redfish-solutions.com> Philip Prindeville wrote: >> I'm a flailing at cluefulness here. Maybe someone can set me straight. >> >> I run "yum" nightly (as as service), but I see a lot of "*.rpmnew" files >> being left around. >> >> What's most bizarre is that the original RPM files haven't been changed, >> and often the two files have the same size, contents (and hence MD5 >> signature), permissions, ownership, etc. Even the same file modification >> date in most cases. >> >> So why do they get left behind? >> >> # cd /etc/security >> # ls -ltr chroot* >> -rw-r--r-- 1 root root 82 Aug 1 05:18 chroot.conf.rpmnew >> -rw-r--r-- 1 root root 82 Aug 1 05:18 chroot.conf >> # diff -c chroot.conf.rpmnew chroot.conf >> # mv chroot.conf.rpmnew chroot.conf >> # >> >> >> Thanks, >> >> -Philip Bingo: # ls -l /etc/security/chroot.conf* -rw-r--r-- 1 root root 82 Aug 1 05:18 /etc/security/chroot.conf -rw-r--r-- 1 root root 82 Aug 1 05:18 /etc/security/chroot.conf.rpmnew # perl -e 'print join(", ", stat("/etc/security/chroot.conf")), "\n"' 64768, 721510, 33188, 1, 0, 0, 0, 82, 1154431139, 1154431139, 1156023232, 4096, 8 # perl -e 'print join(", ", stat("/etc/security/chroot.conf.rpmnew")), "\n"' 64768, 719917, 33188, 1, 0, 0, 0, 82, 1154431128, 1154431128, 1156023323, 4096, 8 # perl -e 'print scalar localtime((stat("/etc/security/chroot.conf.rpmnew"))[9]), "\n"' Tue Aug 1 05:18:48 2006 # perl -e 'print scalar localtime((stat("/etc/security/chroot.conf"))[9]), "\n"' Tue Aug 1 05:18:59 2006 # And there you have it. Why are the packages being generated with a few seconds jitter? This seems to be generating a lot of .rpmnew files gratuitously. -Philip From Axel.Thimm at ATrpms.net Sun Dec 10 23:19:48 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 11 Dec 2006 00:19:48 +0100 Subject: [Fedora-packaging] Re: RPM weirdness [moved from fedora-list] In-Reply-To: <457C8F1E.609@redfish-solutions.com> References: <457C7271.1040600@redfish-solutions.com> <20061210165525.1qynvbr084ocg0ck@horde.dpniner.net> <457C8A75.2050309@redfish-solutions.com> <457C8F1E.609@redfish-solutions.com> Message-ID: <20061210231948.GA4009@neu.nirvana> On Sun, Dec 10, 2006 at 03:50:06PM -0700, Philip Prindeville wrote: > Philip Prindeville wrote: > > >> I'm a flailing at cluefulness here. Maybe someone can set me straight. > >> > >> I run "yum" nightly (as as service), but I see a lot of "*.rpmnew" files > >> being left around. > >> > >> What's most bizarre is that the original RPM files haven't been changed, > >> and often the two files have the same size, contents (and hence MD5 > >> signature), permissions, ownership, etc. Even the same file modification > >> date in most cases. > >> > >> So why do they get left behind? > >> > >> # cd /etc/security > >> # ls -ltr chroot* > >> -rw-r--r-- 1 root root 82 Aug 1 05:18 chroot.conf.rpmnew > >> -rw-r--r-- 1 root root 82 Aug 1 05:18 chroot.conf > >> # diff -c chroot.conf.rpmnew chroot.conf > >> # mv chroot.conf.rpmnew chroot.conf > >> # > >> > >> > >> Thanks, > >> > >> -Philip > > > > > Bingo: > > # ls -l /etc/security/chroot.conf* > -rw-r--r-- 1 root root 82 Aug 1 05:18 /etc/security/chroot.conf > -rw-r--r-- 1 root root 82 Aug 1 05:18 /etc/security/chroot.conf.rpmnew > # perl -e 'print join(", ", stat("/etc/security/chroot.conf")), "\n"' > 64768, 721510, 33188, 1, 0, 0, 0, 82, 1154431139, 1154431139, 1156023232, 4096, 8 > # perl -e 'print join(", ", stat("/etc/security/chroot.conf.rpmnew")), "\n"' > 64768, 719917, 33188, 1, 0, 0, 0, 82, 1154431128, 1154431128, 1156023323, 4096, 8 > # perl -e 'print scalar localtime((stat("/etc/security/chroot.conf.rpmnew"))[9]), "\n"' > Tue Aug 1 05:18:48 2006 > # perl -e 'print scalar localtime((stat("/etc/security/chroot.conf"))[9]), "\n"' > Tue Aug 1 05:18:59 2006 > # > > And there you have it. > > Why are the packages being generated with a few seconds jitter? > > This seems to be generating a lot of .rpmnew files gratuitously. Looks a bit like multilib. E.g. config files existing in two packages, an i386 and an x86_64 one. If it were a single package and rpm upgrades it it registers that the config files have not changed, so the new one can be put in place. But if you do that for two packages in a row that contain exactly the same config files, then the first update will have changed the config files properly, but the second update will think the user changed the config files manually and will go the rpmnew route. So the question is: Is that a x86_64 system? If yes, then we need to think about config files in multilib. If not, then forget about the above consiracy theory. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From philipp_subx at redfish-solutions.com Mon Dec 11 03:36:34 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Sun, 10 Dec 2006 20:36:34 -0700 Subject: [Fedora-packaging] Re: RPM weirdness [moved from fedora-list] In-Reply-To: <20061210231948.GA4009@neu.nirvana> References: <457C7271.1040600@redfish-solutions.com> <20061210165525.1qynvbr084ocg0ck@horde.dpniner.net> <457C8A75.2050309@redfish-solutions.com> <457C8F1E.609@redfish-solutions.com> <20061210231948.GA4009@neu.nirvana> Message-ID: <457CD242.3040403@redfish-solutions.com> Axel Thimm wrote: >On Sun, Dec 10, 2006 at 03:50:06PM -0700, Philip Prindeville wrote: > > >>Philip Prindeville wrote: >> >> >> >>>>I'm a flailing at cluefulness here. Maybe someone can set me straight. >>>> >>>>I run "yum" nightly (as as service), but I see a lot of "*.rpmnew" files >>>>being left around. >>>> >>>>What's most bizarre is that the original RPM files haven't been changed, >>>>and often the two files have the same size, contents (and hence MD5 >>>>signature), permissions, ownership, etc. Even the same file modification >>>>date in most cases. >>>> >>>>So why do they get left behind? >>>> >>>># cd /etc/security >>>># ls -ltr chroot* >>>>-rw-r--r-- 1 root root 82 Aug 1 05:18 chroot.conf.rpmnew >>>>-rw-r--r-- 1 root root 82 Aug 1 05:18 chroot.conf >>>># diff -c chroot.conf.rpmnew chroot.conf >>>># mv chroot.conf.rpmnew chroot.conf >>>># >>>> >>>> >>>>Thanks, >>>> >>>>-Philip >>>> >>>> >> >> >>Bingo: >> >># ls -l /etc/security/chroot.conf* >>-rw-r--r-- 1 root root 82 Aug 1 05:18 /etc/security/chroot.conf >>-rw-r--r-- 1 root root 82 Aug 1 05:18 /etc/security/chroot.conf.rpmnew >># perl -e 'print join(", ", stat("/etc/security/chroot.conf")), "\n"' >>64768, 721510, 33188, 1, 0, 0, 0, 82, 1154431139, 1154431139, 1156023232, 4096, 8 >># perl -e 'print join(", ", stat("/etc/security/chroot.conf.rpmnew")), "\n"' >>64768, 719917, 33188, 1, 0, 0, 0, 82, 1154431128, 1154431128, 1156023323, 4096, 8 >># perl -e 'print scalar localtime((stat("/etc/security/chroot.conf.rpmnew"))[9]), "\n"' >>Tue Aug 1 05:18:48 2006 >># perl -e 'print scalar localtime((stat("/etc/security/chroot.conf"))[9]), "\n"' >>Tue Aug 1 05:18:59 2006 >># >> >>And there you have it. >> >>Why are the packages being generated with a few seconds jitter? >> >>This seems to be generating a lot of .rpmnew files gratuitously. >> >> > >Looks a bit like multilib. E.g. config files existing in two packages, >an i386 and an x86_64 one. > >If it were a single package and rpm upgrades it it registers that the >config files have not changed, so the new one can be put in place. > >But if you do that for two packages in a row that contain exactly the >same config files, then the first update will have changed the config >files properly, but the second update will think the user changed the >config files manually and will go the rpmnew route. > >So the question is: Is that a x86_64 system? If yes, then we need to >think about config files in multilib. If not, then forget about the >above consiracy theory. ;) > > Well, in two cases that I looked at, that turned out to be true. Not sure if there were any exceptions. Maybe samba-common. I'll pay attention in the future when I see it happen next... I'm still not clear, though: if the file being installed is part of the sources that's being built (i.e. it's not a generated file), and the makefile that does the install invoked "cp --preserve=timestamps" then both the .i386 and the .x86_64 copies should have an identical timestamp. Right? -Philip -Philip From rdieter at math.unl.edu Mon Dec 11 04:17:41 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 10 Dec 2006 22:17:41 -0600 Subject: [Fedora-packaging] Re: RPM weirdness [moved from fedora-list] In-Reply-To: <457CD242.3040403@redfish-solutions.com> References: <457C7271.1040600@redfish-solutions.com> <20061210165525.1qynvbr084ocg0ck@horde.dpniner.net> <457C8A75.2050309@redfish-solutions.com> <457C8F1E.609@redfish-solutions.com> <20061210231948.GA4009@neu.nirvana> <457CD242.3040403@redfish-solutions.com> Message-ID: <457CDBE5.9000409@math.unl.edu> Philip Prindeville wrote: > I'm still not clear, though: if the file being installed is part of the > sources that's being built (i.e. it's not a generated file), and the > makefile that does the install invoked "cp --preserve=timestamps" > then both the .i386 and the .x86_64 copies should have an identical > timestamp. Right? Consider the case where the installed file(s) are build-time generated. These are *very* unlikely to have identical timestamps (having been built separately on different archs/buildhosts). -- Rex From Axel.Thimm at ATrpms.net Mon Dec 11 09:55:15 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 11 Dec 2006 10:55:15 +0100 Subject: [Fedora-packaging] config files in multilibed packages (was: RPM weirdness) In-Reply-To: <457CDBE5.9000409@math.unl.edu> References: <457C7271.1040600@redfish-solutions.com> <20061210165525.1qynvbr084ocg0ck@horde.dpniner.net> <457C8A75.2050309@redfish-solutions.com> <457C8F1E.609@redfish-solutions.com> <20061210231948.GA4009@neu.nirvana> <457CD242.3040403@redfish-solutions.com> <457CDBE5.9000409@math.unl.edu> Message-ID: <20061211095515.GA20448@neu.nirvana> On Sun, Dec 10, 2006 at 10:17:41PM -0600, Rex Dieter wrote: > Philip Prindeville wrote: > > > I'm still not clear, though: if the file being installed is part of the > > sources that's being built (i.e. it's not a generated file), and the > > makefile that does the install invoked "cp --preserve=timestamps" > > then both the .i386 and the .x86_64 copies should have an identical > > timestamp. Right? > > Consider the case where the installed file(s) are build-time generated. > These are *very* unlikely to have identical timestamps (having been > built separately on different archs/buildhosts). I think that's it. Going back to Philip's example on /etc/security/chroot.conf (he didn't mention which distro, but the one matching his timestamps is FC5): On FC5/x86_64 one gets: # rpm -qf /etc/security/chroot.conf pam-0.99.5.0-5.fc5 pam-0.99.5.0-5.fc5 # TZ=C ls -ld --full-time /etc/security/chroot.conf -rw-r--r-- 1 root root 82 2006-08-01 11:18:48.000000000 +0000 /etc/security/chroot.conf # rpm -V pam.i386| grep chroot # rpm -V pam.x86_64| grep chroot .......T c /etc/security/chroot.conf So the i386 package thinks all is fine, while the x86_64 package thinks the config file has been altered manually. So the x86_64 package will not touch that file on upgrading and generate an rpmnew file. BTW I wonder why multilib allowed i386 to win over x86_64 on my system. Looks like a different issue, but perhaps the above only triggers in such cases. There are several points to learn here: a) always use install -p or similar, e.g. preserve the time stamps while packaging. This is a general rule of reason and we see here that it can trigger other bugs b) avoid packaging config files in multilibed packages. E.g. pam should split off a libpam subpackage and we should only multilib that. c) investigate what happens on multilib upgrades and config files. Something is obvioulsy broken there. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Dec 11 10:00:36 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 11 Dec 2006 11:00:36 +0100 Subject: [Fedora-packaging] config files in multilibed packages (was: RPM weirdness) In-Reply-To: <457CD242.3040403@redfish-solutions.com> References: <457C7271.1040600@redfish-solutions.com> <20061210165525.1qynvbr084ocg0ck@horde.dpniner.net> <457C8A75.2050309@redfish-solutions.com> <457C8F1E.609@redfish-solutions.com> <20061210231948.GA4009@neu.nirvana> <457CD242.3040403@redfish-solutions.com> Message-ID: <20061211100036.GB20448@neu.nirvana> On Sun, Dec 10, 2006 at 08:36:34PM -0700, Philip Prindeville wrote: > Axel Thimm wrote: > >Looks a bit like multilib. E.g. config files existing in two packages, > >an i386 and an x86_64 one. > Well, in two cases that I looked at, that turned out to be true. > > Not sure if there were any exceptions. Maybe samba-common. > I'll pay attention in the future when I see it happen next... Well, samba-common has the same fate: # rpm -qf --qf '%{name}-%{version}-%{release}@%{arch}\n' /etc/samba/lmhosts /etc/samba/smb.conf | sort -u samba-common-3.0.23c-2 at i386 samba-common-3.0.23c-2 at x86_64 # TZ=C ls -l --full-time /etc/samba/lmhosts /etc/samba/smb.conf -rw-r--r-- 1 root root 20 2006-09-02 02:59:06.000000000 +0000 /etc/samba/lmhosts -rw-r--r-- 1 root root 9765 2006-09-02 02:59:06.000000000 +0000 /etc/samba/smb.conf # rpm -V samba-common.x86_64 | grep /etc/samba .......T c /etc/samba/lmhosts .......T c /etc/samba/smb.conf # rpm -V samba-common.i386 | grep /etc/samba So, again the timestamps of the config files in the two coinstalled packages differ and an upgrade will make one of them think the config file was changed. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From philipp_subx at redfish-solutions.com Mon Dec 11 19:26:53 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Mon, 11 Dec 2006 12:26:53 -0700 Subject: [Fedora-packaging] Re: RPM weirdness [moved from fedora-list] In-Reply-To: <457CDBE5.9000409@math.unl.edu> References: <457C7271.1040600@redfish-solutions.com> <20061210165525.1qynvbr084ocg0ck@horde.dpniner.net> <457C8A75.2050309@redfish-solutions.com> <457C8F1E.609@redfish-solutions.com> <20061210231948.GA4009@neu.nirvana> <457CD242.3040403@redfish-solutions.com> <457CDBE5.9000409@math.unl.edu> Message-ID: <457DB0FD.5040001@redfish-solutions.com> Rex Dieter wrote: >Philip Prindeville wrote: > > > >>I'm still not clear, though: if the file being installed is part of the >>sources that's being built (i.e. it's not a generated file), and the >>makefile that does the install invoked "cp --preserve=timestamps" >>then both the .i386 and the .x86_64 copies should have an identical >>timestamp. Right? >> >> > >Consider the case where the installed file(s) are build-time generated. > These are *very* unlikely to have identical timestamps (having been >built separately on different archs/buildhosts). > >-- Rex > > I would have thought that to be much less common. Also, sometimes the jitter between the .x86_64 and the .i386 files are only a few seconds (often less than 30). It shouldn't be too hard to cache the timestamp on one of those files, and if the MD5 checksum and size are identical, then substitute in the previous timestamp... Say always using the .i386 timestamp, for instance. The downside to that is that if you find a bug that only affects .x86_64 architecture (not that unlikely), then you have to kick out both binary RPM's with new version numbers. It also means that when building, you'd always have to build the "reference" architecture first. -Philip From philipp_subx at redfish-solutions.com Mon Dec 11 20:12:51 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Mon, 11 Dec 2006 13:12:51 -0700 Subject: [Fedora-packaging] Re: [Mimedefang] More on mimedefang and x86_64 In-Reply-To: <4560FCA6.3020704@redfish-solutions.com> References: <4560FCA6.3020704@redfish-solutions.com> Message-ID: <457DBBC3.5050102@redfish-solutions.com> Moving to fedora-packaging... Seeking assistance from .x86_64 packaging gurudom. Issues we're trying to solve here are: * The package should be buildable without having all of the run-time requirements met (there are things that are called out as both BuildRequires: and Requires: that are really only the latter. * When building on an x86_64 architecture, we should look for the libmilter stuff in /usr/lib64 and /lib64 also. (Wasn't sure if this goes in the configure.in file, or should be an additional conditional argument passed into %configure instead...) * It's not building any symbol-table exports for the debuginfo package, and I don't know why. Can someone walk me through these issues? David will post patches if we can get official blessings. Thanks, -Philip P.s. Can the list admin please take .eml off the prohibited attachment suffix list? Philip Prindeville wrote: >Hmmm... > >I run sendmail/cyrus-imapd/spamassassin/mimedefang on an >x86_64 machine (FC5 on an Athalon64 2800+) and it works fine. > >To keep the mail server simple, however, I wanted to build >mimedefang-2.58 on a different machine, so I went ahead and >grabbed all of the dependencies. > >I have to say, I was a bit configured. It seems that the build-time >dependencies have been muddled with the run-time dependencies. > >You don't need: > >BuildRequires: perl-Digest-SHA1 perl-MIME-tools perl-IO-stringy perl-MailTools > > >in the .spec file, do you? Can we yank this? I just pulled it out >and things built fine (oh, after adding "--disable-check-perl-modules" >to the ./configure line). > >Further, if you install sendmail-devel but don't actually >have sendmail installed on the machine (since your building, >but not actually running)... then you might run afoul of the >following scenario. sendmail-devel installs (on an x86_64 >architecture) /usr/lib64/libmilter.a only. > >So, from configure.in: > >AC_PATH_PROG(LIBMILTER, libmilter.a, no, $MILTERLIB:$SMPATH:/usr/local/lib:/lib:/usr/lib:/usr/lib/libmilter) >SMPATH=`echo ../sendmail-*/obj.*/libsm` >AC_PATH_PROG(LIBSM, libsm.a, no, $SMPATH:/usr/local/lib:/lib:/usr/lib:/usr/lib/libmilter) > >dnl find libmilter.so in case we have shared libraries >AC_PATH_PROG(LIBMILTERSO, libmilter.so, no, $MILTERLIB:$SMPATH:/usr/local/lib:/lib:/usr/lib:/usr/lib/libmilter) > > >should we add /lib64 and /usr/lib64 before /lib and /usr/lib, >respectively? > >I changed the .spec file to include: > > ./configure ... --with-libmilter=/usr/lib64 ... > >and it seems to build... but it might make more sense to >fix this in the configure.in file instead, as above. > >Opinions? > >Oh, and do we need the symbol file for /usr/bin/mimedefang >to put into mimedefang-debuginfo-2.58? > >-Philip > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mimedefang-diffs URL: From a.badger at gmail.com Tue Dec 12 00:24:41 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 11 Dec 2006 16:24:41 -0800 Subject: [Fedora-packaging] Missing the meeting Message-ID: <1165883081.31520.85.camel@localhost.localdomain> Hey guys, I'll be traveling during the time the packaging meeting is taking place tomorrow. I can catch up with the meeting logs after and would be glad to use email for anything that comes up for a vote. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Tue Dec 12 00:37:55 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 11 Dec 2006 18:37:55 -0600 Subject: [Fedora-packaging] Missing the meeting In-Reply-To: <1165883081.31520.85.camel@localhost.localdomain> References: <1165883081.31520.85.camel@localhost.localdomain> Message-ID: <1165883875.3583.505.camel@localhost.localdomain> On Mon, 2006-12-11 at 16:24 -0800, Toshio Kuratomi wrote: > Hey guys, > > I'll be traveling during the time the packaging meeting is taking place > tomorrow. I can catch up with the meeting logs after and would be glad > to use email for anything that comes up for a vote. I will also miss the meeting, since I'll be with a customer all day tomorrow and not able to get to the Interweb. ~spot From fedora at leemhuis.info Wed Dec 13 17:00:38 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Dec 2006 18:00:38 +0100 Subject: [Fedora-packaging] File deps outside "/etc {/usr,}/{s,}bin/" Message-ID: <458031B6.6050605@leemhuis.info> %pre: fedora-packaging at redhat.com CCed, reply-to set to fedora-extras-list at redhat.com -- I suspects mailman will eat it; please simply reply to fedora-extras-list manually to avoid further crossposting and slitted discussions; tia! Hi, skvidal mentioned in #fedora-extras we should consider going through all packages and look out for unnecessary file deps outside of "/etc /usr/sbin/ /usr/bin/ /sbin/ /bin/". Those are covered by the primary dataset yum loads normally. Yum has do load a second, (often big) file to depsolve the others; that often slows down depsolving packages a lot -- most of us were probably bitten by this already in the past and know what I'm talking about. So, should we try to get rid of such deps as much as possible? And maybe even put a short note into the packaging guidelines that file based deps outside of "/etc {/usr,}/{s,}bin/" slow down yum and therefore should be avoided if possible? Options? BTW, I did a quick lookup on a x86-64 FC-6 machine with repoquery; we seems to have 32 file based deps outside of "/etc {/usr,}/{s,}bin/" in Extras: /usr/lib64/ctapi /usr/lib64/libpcsclite.so.1 /usr/lib64/pgsql /usr/share/pgsql /usr/include/linux /usr/lib64/util-vserver /usr/share/fonts/bitstream-vera/Vera.ttf /usr/share/themes /var/www/cgi-bin /var/www/html /usr/lib64/pkgconfig /usr/share/X11/app-defaults /usr/lib64/php/modules /usr/share/icons/hicolor/scalable /usr/lib64/mozilla/plugins /usr/share/xml /usr/lib/python2.4/site-packages /usr/include/sysfs/libsysfs.h /usr/lib64/mozilla/plugins /usr/lib64/util-vserver /usr/share/sgml/html/4.01 /usr/share/sgml/xhtml1/xhtml1-20020801/DTD /usr/share/X11/rgb.txt /usr/share/aclocal /usr/lib64/pkgconfig /usr/share/desktop-menu-patches/redhat-audio-player.desktop /usr/lib64/ctapi /usr/share/emacs/site-lisp /usr/share/fonts /usr/lib64/util-vserver /usr/lib64/util-vserver/sigexec /usr/share/basemap At least some of them look suspicious: /usr/lib/python2.4/site-packages -> simply python /usr/lib64/util-vserver -> simply util-vserver-core /usr/lib64/ctapi -> simply ctapi-common /usr/lib64/pkgconfig -> simply pkgconfig ... /usr/lib64/mozilla/plugins and some other dirs are probaly okay. CU thl P.S.:Core has some more: /usr/lib64/python2.4 /usr/lib/news/lib/innshellvars.pl /usr/lib64/python2.4 /usr/lib/libgcj.so.7rh /usr/lib/libz.so /usr/lib64/python2.4 /usr/lib64/libstdc++.so.6 /usr/share/openldap/migration/migrate_common.ph /usr/lib/libstdc++.so.6 /usr/lib/lsb/install_initd /usr/lib/lsb/remove_initd /usr/lib64/libgcj.so.7rh /usr/lib64/libz.so /usr/share/magic.mime /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib64/python2.4 /lib64/security/pam_loginuid.so /usr/lib64/python2.4/site-packages /usr/share/gnome-screensaver/lock-dialog-system.glade /usr/share/desktop-menu-patches/gnome-gdmsetup.desktop /lib64/security/pam_loginuid.so From Axel.Thimm at ATrpms.net Wed Dec 13 17:24:44 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 13 Dec 2006 18:24:44 +0100 Subject: [Fedora-packaging] Re: File deps outside "/etc {/usr,}/{s,}bin/" In-Reply-To: <458031B6.6050605@leemhuis.info> References: <458031B6.6050605@leemhuis.info> Message-ID: <20061213172444.GA21921@neu.nirvana> On Wed, Dec 13, 2006 at 06:00:38PM +0100, Thorsten Leemhuis wrote: > %pre: fedora-packaging at redhat.com CCed, reply-to set to > fedora-extras-list at redhat.com -- I suspects mailman will eat it; please > simply reply to fedora-extras-list manually to avoid further > crossposting and slitted discussions; tia! mailman seems to do fine ;) > skvidal mentioned in #fedora-extras we should consider going through all > packages and look out for unnecessary file deps outside of "/etc > /usr/sbin/ /usr/bin/ /sbin/ /bin/". Those are covered by the primary > dataset yum loads normally. Yum has do load a second, (often big) file > to depsolve the others; that often slows down depsolving packages a lot > -- most of us were probably bitten by this already in the past and know > what I'm talking about. > > So, should we try to get rid of such deps as much as possible? And maybe > even put a short note into the packaging guidelines that file based deps > outside of "/etc {/usr,}/{s,}bin/" slow down yum and therefore should be > avoided if possible? > > Options? In the packaging guidelines I'd rather argue that *manual* file based dependencies should only be used if there is really a reason to, including bin/sysconfigdirs. Possible reasons can be: o portability between releases (package renames/splits) o poor man's arch dependencies, e.g. depending on /usr/lib/python2.4 will make sure python.i386 will be pulled in on x86_64. o are there any others? Sometimes the first item is abused "in advance", e.g. for initscripts or kernel-utils which contain(ed) stuff that developers felt they may get split into another package, even if they didn't at that time. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Dec 13 19:33:22 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 13 Dec 2006 13:33:22 -0600 Subject: [Fedora-packaging] iconcache proposal, v2 Message-ID: <45805582.2030706@math.unl.edu> I've updated the iconcache proposal: http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache per the suggestions made at the recent fedora-packaging meeting. In short, simplify to use xdg-utils, and add (when needed): Requires(post): xdg-utils Requires(postun): xdg-utils We could likely optimize %postun to include if [ $1 -eq 0 ]; then ... fi but I'm not sure if it's worth it. -- Rex From ceplm at seznam.cz Wed Dec 13 15:40:57 2006 From: ceplm at seznam.cz (Matej Cepl) Date: Wed, 13 Dec 2006 15:40:57 +0000 (UTC) Subject: [Fedora-packaging] Re: Revived License: tag proposal References: Message-ID: On Tue, 28 Nov 2006 01:11:11 -0600, Jason L Tibbitts III scripst: > I have revived the License: tag proposal, simplified to a basic > standardization of the tags used for some common licenses. I have not > attempted to pick a list of those common licenses, although I have > provided some data on what License: tags are in use. > > http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > > Again, I wish to remind folks that this is just a proposal. Certainly I am missing in the list my preferred (and very common) MIT/X license. Mat?j -- http://www.ceplovi.cz/matej/blog/, Jabber: ceplmajabber.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC There is no reason to suppose that most human beings are engaged in maximizing anything unless it be unhappiness, and even this with incomplete success. -- Ronald Coase Introduction to ``The Firm, the Market, and the Law'' From a.badger at gmail.com Thu Dec 14 17:37:54 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 14 Dec 2006 09:37:54 -0800 Subject: [Fedora-packaging] iconcache proposal, v2 In-Reply-To: <45805582.2030706@math.unl.edu> References: <45805582.2030706@math.unl.edu> Message-ID: <1166117874.5819.8.camel@localhost.localdomain> On Wed, 2006-12-13 at 13:33 -0600, Rex Dieter wrote: > I've updated the iconcache proposal: > http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache > per the suggestions made at the recent fedora-packaging meeting. > > In short, simplify to use xdg-utils, and add (when needed): > Requires(post): xdg-utils > Requires(postun): xdg-utils > > We could likely optimize %postun to include > if [ $1 -eq 0 ]; then > ... > fi > but I'm not sure if it's worth it. Hey Rex, Looks like your edit got lost somewhere. The last edit I see to the page was 2006-12-04. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Thu Dec 14 17:49:16 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Dec 2006 11:49:16 -0600 Subject: [Fedora-packaging] Re: Revived License: tag proposal In-Reply-To: References: Message-ID: >>>>> "MC" == Matej Cepl writes: MC> On Tue, 28 Nov 2006 01:11:11 -0600, Jason L Tibbitts III scripst: >> I have not attempted to pick a list of those common licenses, >> although I have provided some data on what License: tags are in >> use. MC> Certainly I am missing in the list my preferred (and very common) MC> MIT/X license. Well, two issues here: As I wrote in the text you quoted, I wasn't attempting to provide an exhaustive list of licenses to be standardized; I only listed a few examples so that I could get feedback on the proposal itself first and work on the complete list of tags afterwords. Unfortunately so far the only comments I've received has been about tags that are missing form the examples. So the only thing you should infer from the purposefully incomplete random list of examples is that it's incomplete. But if you want to discuss the license tag to be used for the X11 license, that's OK. In their commentary on the X11 license, FSF says: "This license is sometimes called the "MIT" license, but that term is misleading, since MIT has used many licenses for software." and then, referring to the Expat license: "It is sometimes ambiguously referred to as the MIT License." So if we're discussing the tag to use for the X11 license, I think it would be less problematic to use just "X11" but there's certainly room for discussion. Note: I've no idea what to do about the rather large number of packages tagged "MIT". Change them to X11 as well? - J< From rdieter at math.unl.edu Thu Dec 14 17:51:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 14 Dec 2006 11:51:08 -0600 Subject: [Fedora-packaging] iconcache proposal, v2 In-Reply-To: <1166117874.5819.8.camel@localhost.localdomain> References: <45805582.2030706@math.unl.edu> <1166117874.5819.8.camel@localhost.localdomain> Message-ID: <45818F0C.60600@math.unl.edu> Toshio Kuratomi wrote: > On Wed, 2006-12-13 at 13:33 -0600, Rex Dieter wrote: >> I've updated the iconcache proposal: >> http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache >> per the suggestions made at the recent fedora-packaging meeting. >> >> In short, simplify to use xdg-utils, and add (when needed): >> Requires(post): xdg-utils >> Requires(postun): xdg-utils >> >> We could likely optimize %postun to include >> if [ $1 -eq 0 ]; then >> ... >> fi >> but I'm not sure if it's worth it. > > Hey Rex, > Looks like your edit got lost somewhere. The last edit I see to the > page was 2006-12-04. Arg! You're right. ???? ok, one more try. -- Rex From smooge at gmail.com Thu Dec 14 18:32:45 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 14 Dec 2006 11:32:45 -0700 Subject: [Fedora-packaging] Re: Revived License: tag proposal In-Reply-To: References: Message-ID: <80d7e4090612141032m2c78d9f7j6ad03e9a94c16a05@mail.gmail.com> On 14 Dec 2006 11:49:16 -0600, Jason L Tibbitts III wrote: > >>>>> "MC" == Matej Cepl writes: > > MC> On Tue, 28 Nov 2006 01:11:11 -0600, Jason L Tibbitts III scripst: > > >> I have not attempted to pick a list of those common licenses, > >> although I have provided some data on what License: tags are in > >> use. > > MC> Certainly I am missing in the list my preferred (and very common) > MC> MIT/X license. > > Well, two issues here: > > As I wrote in the text you quoted, I wasn't attempting to provide an > exhaustive list of licenses to be standardized; I only listed a few > examples so that I could get feedback on the proposal itself first and > work on the complete list of tags afterwords. Unfortunately so far > the only comments I've received has been about tags that are missing > form the examples. So the only thing you should infer from the > purposefully incomplete random list of examples is that it's > incomplete. Comments: A) Thankyou very much for continuing on this. I made a list for FC-6 and could not get back to it because of job changes B) One should distinguish v1 and v2 of the GPL. The changes if I remember were rather important. I don't know of any code though under v1. C) There are multiple versions of the LGPL. I do not remember the differences between renaming it from Library GPL to Lesser GPL. D) I would go for a standardization as the following: Name of license, Version of license, File(s) to see details. BSD, Original, See /usr/share/licenses/BSD.Original BSD, Updated, See /usr/share/licenses/BSD.Updated Multiple, See /usr/share//licenses/ GPL, v1, See /usr/share/licenses/GPL.v1.0 There could be a package called Fedora-Recognized-Licenses-1.0 that installs most of the ones that are considered matching the purpose of the project. It should not be a grab-bag of every license the OSI said was ok.. but the core ones that Fedora considers to be good examples of the central values of Liberty, Equality, and Justice. All other licenses would be required to be placed in the /usr/share/package-name/licenses directory. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From tibbs at math.uh.edu Thu Dec 14 19:39:29 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Dec 2006 13:39:29 -0600 Subject: [Fedora-packaging] Re: Revived License: tag proposal In-Reply-To: <80d7e4090612141032m2c78d9f7j6ad03e9a94c16a05@mail.gmail.com> References: <80d7e4090612141032m2c78d9f7j6ad03e9a94c16a05@mail.gmail.com> Message-ID: >>>>> "SJS" == Stephen John Smoogen writes: SJS> B) One should distinguish v1 and v2 of the GPL. The changes if I SJS> remember were rather important. I don't know of any code though SJS> under v1. I recall that the original discussion about this came to the conclusion that GPL1 and 2 shouldn't be distinguished. I'll see if I can't dig it up: [Thu Aug 10 2006] [11:41:43] Okay. License Tags isnext [Thu Aug 10 2006] [11:42:09] List discussion seemed to lean towards this being just a superficial description of the license. [Thu Aug 10 2006] [11:42:31] That we shouldn't try to get too specific with the license tags. [Thu Aug 10 2006] [11:42:46] yeah, I don't see that ever being more than an indication [Thu Aug 10 2006] [11:42:51] I tend to agree with that. [Thu Aug 10 2006] [11:43:00] So "GPL", not "GPLv2" and "GPLv3", etc. [Thu Aug 10 2006] [11:43:20] And "BSD", not "BSD with advertising". [Thu Aug 10 2006] [11:43:21] The License field shouldn't be misleading, though. [Thu Aug 10 2006] [11:44:10] So if GPLv2 and GPLv3 are different enough we would want to differentiate. [Thu Aug 10 2006] [11:44:13] And packagers should brave the rpmlint warning rather than lying about the license just to shut it up. [Thu Aug 10 2006] [11:44:17] for GPL, I could go either way; if it's BSD with modifications, why not just 'BSD variation' SJS> D) I would go for a standardization as the following: SJS> Name of license, Version of license, File(s) to see details. Well, that's contrary to pretty much all of the previous discussion. How do others feel? - J< From rdieter at math.unl.edu Thu Dec 14 20:53:33 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 14 Dec 2006 14:53:33 -0600 Subject: [Fedora-packaging] Re: iconcache proposal, v2 References: <45805582.2030706@math.unl.edu> <1166117874.5819.8.camel@localhost.localdomain> <45818F0C.60600@math.unl.edu> Message-ID: Rex Dieter wrote: > Toshio Kuratomi wrote: >> Hey Rex, >> Looks like your edit got lost somewhere. The last edit I see to the >> page was 2006-12-04. > Arg! You're right. ???? OK, http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache *really* is v0.2 now. To re-iterate, simplify to use xdg-utils, and add (when needed): Requires(post): xdg-utils Requires(postun): xdg-utils From opensource at till.name Thu Dec 14 22:21:55 2006 From: opensource at till.name (Till Maas) Date: Thu, 14 Dec 2006 23:21:55 +0100 Subject: [Fedora-packaging] iconcache proposal, v2 In-Reply-To: <45805582.2030706@math.unl.edu> References: <45805582.2030706@math.unl.edu> Message-ID: <200612142322.17118.opensource@till.name> On Wednesday 13 December 2006 20:33, Rex Dieter wrote: > In short, simplify to use xdg-utils, and add (when needed): > Requires(post): xdg-utils > Requires(postun): xdg-utils How about removing this completely from .spec files and add it to a yum-plugin, that runs whenever package adds a file to {_datadir}/icons/ and then only once per yum invocation? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Dec 14 23:23:06 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 14 Dec 2006 17:23:06 -0600 Subject: [Fedora-packaging] iconcache proposal, v2 In-Reply-To: <200612142322.17118.opensource@till.name> References: <45805582.2030706@math.unl.edu> <200612142322.17118.opensource@till.name> Message-ID: <4581DCDA.70205@math.unl.edu> Till Maas wrote: > On Wednesday 13 December 2006 20:33, Rex Dieter wrote: > >> In short, simplify to use xdg-utils, and add (when needed): >> Requires(post): xdg-utils >> Requires(postun): xdg-utils > > How about removing this completely from .spec files and add it to a > yum-plugin, that runs whenever package adds a file to {_datadir}/icons/ and > then only once per yum invocation? sure, got code for that? (: Besides, I don't think wouldn't work for manual rpm installs. -- Rex From Axel.Thimm at ATrpms.net Thu Dec 14 23:42:20 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Dec 2006 00:42:20 +0100 Subject: [Fedora-packaging] Re: iconcache proposal, v2 In-Reply-To: <45805582.2030706@math.unl.edu> References: <45805582.2030706@math.unl.edu> Message-ID: <20061214234220.GH15553@neu.nirvana> On Wed, Dec 13, 2006 at 01:33:22PM -0600, Rex Dieter wrote: > I've updated the iconcache proposal: > http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache > per the suggestions made at the recent fedora-packaging meeting. > > In short, simplify to use xdg-utils, and add (when needed): > Requires(post): xdg-utils > Requires(postun): xdg-utils Hi, I have two questions (which will have been answered, but I haven't caught up with all traffic on this topic, so please answer again :): a) "If none of the package's existing dependencies themselves already depend on xdg-utils3, include ..." I wouldn't rely on dependencies providing dependencies. Sure, we do remove some redundancy technically, but cut&paste methods are used more often than reading the guidelines, recursive dependencies may change and so on. Let's keep it simple and always require it. b) "someday when xdg-utils becomes universally available (hopefully, this will include F*7)," While the xdg-utils sound like a trivial tool the sentence seems to imply that there are larger obstacles to getting this done. Why? If this improves/simplifies package quality then who would block this? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smooge at gmail.com Thu Dec 14 23:44:58 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 14 Dec 2006 16:44:58 -0700 Subject: [Fedora-packaging] Re: Revived License: tag proposal In-Reply-To: References: <80d7e4090612141032m2c78d9f7j6ad03e9a94c16a05@mail.gmail.com> Message-ID: <80d7e4090612141544o37cf7ec1qa15c0adb60c4eb84@mail.gmail.com> On 14 Dec 2006 13:39:29 -0600, Jason L Tibbitts III wrote: > >>>>> "SJS" == Stephen John Smoogen writes: > > SJS> B) One should distinguish v1 and v2 of the GPL. The changes if I > SJS> remember were rather important. I don't know of any code though > SJS> under v1. > > I recall that the original discussion about this came to the > conclusion that GPL1 and 2 shouldn't be distinguished. I'll see if I > can't dig it up: > > [Thu Aug 10 2006] [11:41:43] Okay. License Tags isnext > [Thu Aug 10 2006] [11:42:09] List discussion seemed to lean towards this being just a superficial description of the license. > [Thu Aug 10 2006] [11:42:31] That we shouldn't try to get too specific with the license tags. > [Thu Aug 10 2006] [11:42:46] yeah, I don't see that ever being more than an indication > [Thu Aug 10 2006] [11:42:51] I tend to agree with that. > [Thu Aug 10 2006] [11:43:00] So "GPL", not "GPLv2" and "GPLv3", etc. > [Thu Aug 10 2006] [11:43:20] And "BSD", not "BSD with advertising". > [Thu Aug 10 2006] [11:43:21] The License field shouldn't be misleading, though. > [Thu Aug 10 2006] [11:44:10] So if GPLv2 and GPLv3 are different enough we would want to differentiate. > [Thu Aug 10 2006] [11:44:13] And packagers should brave the rpmlint warning rather than lying about the license just to shut it up. > [Thu Aug 10 2006] [11:44:17] for GPL, I could go either way; if it's BSD with modifications, why not just 'BSD variation' > I see a disagreement between abadger and tibbs about 2 and 3. Not 1 & 2. > SJS> D) I would go for a standardization as the following: > > SJS> Name of license, Version of license, File(s) to see details. > > Well, that's contrary to pretty much all of the previous discussion. > How do others feel? What can I say.. I can be a pretty contrary person. The issue of the license field is mainly to help inform the user of the rights they can expect on copying and/or modifying the code/binary. Since most people only see the compiled source.. it probably doesnt matter if the license just says: You can distribute/modify it. OR You can't distribute/modify it. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From Axel.Thimm at ATrpms.net Thu Dec 14 23:45:36 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Dec 2006 00:45:36 +0100 Subject: [Fedora-packaging] Re: iconcache proposal, v2 In-Reply-To: <20061214234220.GH15553@neu.nirvana> References: <45805582.2030706@math.unl.edu> <20061214234220.GH15553@neu.nirvana> Message-ID: <20061214234536.GI15553@neu.nirvana> On Fri, Dec 15, 2006 at 12:42:20AM +0100, Axel Thimm wrote: > On Wed, Dec 13, 2006 at 01:33:22PM -0600, Rex Dieter wrote: > > I've updated the iconcache proposal: > > http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache > > per the suggestions made at the recent fedora-packaging meeting. > > > > In short, simplify to use xdg-utils, and add (when needed): > > Requires(post): xdg-utils > > Requires(postun): xdg-utils > > Hi, > > I have two questions (which will have been answered, but I haven't > caught up with all traffic on this topic, so please answer again :): > > a) "If none of the package's existing dependencies themselves already > depend on xdg-utils3, include ..." > > I wouldn't rely on dependencies providing dependencies. Sure, we do > remove some redundancy technically, but cut&paste methods are used > more often than reading the guidelines, recursive dependencies may > change and so on. Let's keep it simple and always require it. > > b) "someday when xdg-utils becomes universally available (hopefully, > this will include F*7)," > > While the xdg-utils sound like a trivial tool the sentence seems to > imply that there are larger obstacles to getting this done. Why? If > this improves/simplifies package quality then who would block this? And the third of the two questions is: ;) c) why is xdg-icon-resource's exit code thrown away? We do know it will exist (explicit direct or indirect Requires:) contrary to gtk-update-icon-cache, so if it fails it probably indicates some system error that should propagate up to the user and get hos attention (e.g. write failure to the cache/fs full etc.) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Fri Dec 15 00:27:07 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 14 Dec 2006 18:27:07 -0600 Subject: [Fedora-packaging] Re: iconcache proposal, v2 In-Reply-To: <20061214234536.GI15553@neu.nirvana> References: <45805582.2030706@math.unl.edu> <20061214234220.GH15553@neu.nirvana> <20061214234536.GI15553@neu.nirvana> Message-ID: <4581EBDB.7050803@math.unl.edu> Axel Thimm wrote: > c) why is xdg-icon-resource's exit code thrown away? failed scriptlets = aborted rpm transaction, which is bad bad bad. -- Rex From rdieter at math.unl.edu Fri Dec 15 00:30:24 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 14 Dec 2006 18:30:24 -0600 Subject: [Fedora-packaging] Re: iconcache proposal, v2 In-Reply-To: <20061214234536.GI15553@neu.nirvana> References: <45805582.2030706@math.unl.edu> <20061214234220.GH15553@neu.nirvana> <20061214234536.GI15553@neu.nirvana> Message-ID: <4581ECA0.7020303@math.unl.edu> Axel Thimm wrote: > On Fri, Dec 15, 2006 at 12:42:20AM +0100, Axel Thimm wrote: >> On Wed, Dec 13, 2006 at 01:33:22PM -0600, Rex Dieter wrote: >>> I've updated the iconcache proposal: >>> http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache >>> per the suggestions made at the recent fedora-packaging meeting. >>> >>> In short, simplify to use xdg-utils, and add (when needed): >>> Requires(post): xdg-utils >>> Requires(postun): xdg-utils >> Hi, >> >> I have two questions (which will have been answered, but I haven't >> caught up with all traffic on this topic, so please answer again :): >> >> a) "If none of the package's existing dependencies themselves already >> depend on xdg-utils3, include ..." >> >> I wouldn't rely on dependencies providing dependencies. Sure, we do ... >> >> b) "someday when xdg-utils becomes universally available (hopefully, >> this will include F*7)," >> >> While the xdg-utils sound like a trivial tool the sentence seems to >> imply that there are larger obstacles to getting this done. Why? If >> this improves/simplifies package quality then who would block this? blockers? None, that I'm aware of. Well, a) is a just pre-cursor to b). I'd like to someday not need the Requires: xdg-utils at all. I'm just as ok with Requiring it's unconditional use too. -- Rex From Axel.Thimm at ATrpms.net Fri Dec 15 08:27:28 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Dec 2006 09:27:28 +0100 Subject: [Fedora-packaging] Re: iconcache proposal, v2 In-Reply-To: <4581EBDB.7050803@math.unl.edu> References: <45805582.2030706@math.unl.edu> <20061214234220.GH15553@neu.nirvana> <20061214234536.GI15553@neu.nirvana> <4581EBDB.7050803@math.unl.edu> Message-ID: <20061215082728.GA13938@neu.nirvana> On Thu, Dec 14, 2006 at 06:27:07PM -0600, Rex Dieter wrote: > Axel Thimm wrote: > > c) why is xdg-icon-resource's exit code thrown away? We do know it > > will exist (explicit direct or indirect Requires:) contrary to > > gtk-update-icon-cache, so if it fails it probably indicates some > > system error that should propagate up to the user and get hos > > attention (e.g. write failure to the cache/fs full etc.) > > failed scriptlets = aborted rpm transaction, which is bad bad bad. Yes, I'm aware of that, aborted transaction = user is notified of somethng broken. So the question is if xdg-icon-resource is always present and is known (is it?) to not fail unless the file system was remounted read-only or the binary is of the wrong elf format or other catastrophies, then better fail early than late. Of course the actual work not having been done by this script is negligible, but I just don't want to silence away any failures in all scriplets for the sake of (presumably) allowing rpm to install further on. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Dec 15 08:29:18 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Dec 2006 09:29:18 +0100 Subject: [Fedora-packaging] Re: iconcache proposal, v2 In-Reply-To: <4581ECA0.7020303@math.unl.edu> References: <45805582.2030706@math.unl.edu> <20061214234220.GH15553@neu.nirvana> <20061214234536.GI15553@neu.nirvana> <4581ECA0.7020303@math.unl.edu> Message-ID: <20061215082918.GB13938@neu.nirvana> On Thu, Dec 14, 2006 at 06:30:24PM -0600, Rex Dieter wrote: > Axel Thimm wrote: > > On Fri, Dec 15, 2006 at 12:42:20AM +0100, Axel Thimm wrote: > >> On Wed, Dec 13, 2006 at 01:33:22PM -0600, Rex Dieter wrote: > >>> I've updated the iconcache proposal: > >>> http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache > >>> per the suggestions made at the recent fedora-packaging meeting. > >>> > >>> In short, simplify to use xdg-utils, and add (when needed): > >>> Requires(post): xdg-utils > >>> Requires(postun): xdg-utils > >> Hi, > >> > >> I have two questions (which will have been answered, but I haven't > >> caught up with all traffic on this topic, so please answer again :): > >> > >> a) "If none of the package's existing dependencies themselves already > >> depend on xdg-utils3, include ..." > >> > >> I wouldn't rely on dependencies providing dependencies. Sure, we do > ... > >> > >> b) "someday when xdg-utils becomes universally available (hopefully, > >> this will include F*7)," > >> > >> While the xdg-utils sound like a trivial tool the sentence seems to > >> imply that there are larger obstacles to getting this done. Why? If > >> this improves/simplifies package quality then who would block this? > > blockers? None, that I'm aware of. Then let's vote on it. > Well, a) is a just pre-cursor to b). I'd like to someday not need the > Requires: xdg-utils > at all. > > I'm just as ok with Requiring it's unconditional use too. I'm fine with the proposal as is (wouldn't mind adding strict requirements on xdg-utils3 and removing "|| :", but that's just nice to have ;), so +1 from here -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jamatos at fc.up.pt Fri Dec 15 23:47:17 2006 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Fri, 15 Dec 2006 23:47:17 +0000 Subject: [Fedora-packaging] what policy for python egg files Message-ID: <200612152347.17221.jamatos@fc.up.pt> I am reviewing [Bug 219751] Review Request: python-TurboMail In the spec file Luke has packaged the egg files for that package. What is Fedora policy regarding this issue. Should we package the egg files or should we leave them? I remember that we have discussed this sometime ago but I don't remember the outcome. Regards, -- Jos? Ab?lio From a.badger at gmail.com Sat Dec 16 00:44:22 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 15 Dec 2006 16:44:22 -0800 Subject: [Fedora-packaging] what policy for python egg files In-Reply-To: <200612152347.17221.jamatos@fc.up.pt> References: <200612152347.17221.jamatos@fc.up.pt> Message-ID: On 12/15/06, Jos? Matos wrote: > I am reviewing > [Bug 219751] Review Request: python-TurboMail > > In the spec file Luke has packaged the egg files for that package. What is > Fedora policy regarding this issue. Should we package the egg files or should > we leave them? > I think we should package them. I think tibbs had the opposite viewpoint but I don't remember if we got to a point where he decided it didn't matter or we came to an agreement or just let it drop. -Toshio From tibbs at math.uh.edu Sat Dec 16 01:43:04 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 15 Dec 2006 19:43:04 -0600 Subject: [Fedora-packaging] what policy for python egg files In-Reply-To: References: <200612152347.17221.jamatos@fc.up.pt> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> I think tibbs had the opposite viewpoint but I don't remember if TK> we got to a point where he decided it didn't matter or we came to TK> an agreement or just let it drop. I guess the point is that I can't figure out what additional value it adds, and in general it's bad to package up something that's completely needless. - J< From Axel.Thimm at ATrpms.net Sat Dec 16 13:09:05 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 16 Dec 2006 14:09:05 +0100 Subject: [Fedora-packaging] Re: what policy for python egg files In-Reply-To: References: <200612152347.17221.jamatos@fc.up.pt> Message-ID: <20061216130905.GG14601@neu.nirvana> On Fri, Dec 15, 2006 at 07:43:04PM -0600, Jason L Tibbitts III wrote: > >>>>> "TK" == Toshio Kuratomi writes: > > TK> I think tibbs had the opposite viewpoint but I don't remember if > TK> we got to a point where he decided it didn't matter or we came to > TK> an agreement or just let it drop. > > I guess the point is that I can't figure out what additional value it > adds, and in general it's bad to package up something that's > completely needless. egg is a packaging method that is orthogonal to what we use. Leaving the eggs around may get users to start using egg-installation and get files on the system unregistered by rpm. Or not? If the above is correct eggs should even be banned just as other non-native package formats are banned (debs or tarballs for example). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jamatos at fc.up.pt Sat Dec 16 13:16:08 2006 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Sat, 16 Dec 2006 13:16:08 +0000 Subject: [Fedora-packaging] Re: what policy for python egg files In-Reply-To: <20061216130905.GG14601@neu.nirvana> References: <200612152347.17221.jamatos@fc.up.pt> <20061216130905.GG14601@neu.nirvana> Message-ID: <200612161316.08764.jamatos@fc.up.pt> On Saturday 16 December 2006 1:09 pm, Axel Thimm wrote: > egg is a packaging method that is orthogonal to what we use. Leaving > the eggs around may get users to start using egg-installation and get > files on the system unregistered by rpm. > > Or not? If the above is correct eggs should even be banned just as > other non-native package formats are banned (debs or tarballs for > example). On one hand I agree with Axel, on the other this allows installations per user, no? What is our policy regarding other programming language ( with their repositories cpan, cran, ctan)... This should probably be a general policy, no? > -- > Axel.Thimm at ATrpms.net -- Jos? Ab?lio From mattdm at mattdm.org Sat Dec 16 13:22:28 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 16 Dec 2006 08:22:28 -0500 Subject: [Fedora-packaging] Re: what policy for python egg files In-Reply-To: <200612161316.08764.jamatos@fc.up.pt> References: <200612152347.17221.jamatos@fc.up.pt> <20061216130905.GG14601@neu.nirvana> <200612161316.08764.jamatos@fc.up.pt> Message-ID: <20061216132227.GA12184@jadzia.bu.edu> On Sat, Dec 16, 2006 at 01:16:08PM +0000, Jos? Matos wrote: > What is our policy regarding other programming language ( with their > repositories cpan, cran, ctan)... Don't ever use CPAN directly. It can really muck up your system. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at leemhuis.info Sat Dec 16 13:28:39 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 16 Dec 2006 14:28:39 +0100 Subject: [Fedora-packaging] Re: File deps outside "/etc {/usr,}/{s,}bin/" In-Reply-To: <20061213172444.GA21921@neu.nirvana> References: <458031B6.6050605@leemhuis.info> <20061213172444.GA21921@neu.nirvana> Message-ID: <4583F487.3060803@leemhuis.info> Axel Thimm schrieb: > On Wed, Dec 13, 2006 at 06:00:38PM +0100, Thorsten Leemhuis wrote: >> %pre: fedora-packaging at redhat.com CCed, reply-to set to >> fedora-extras-list at redhat.com -- I suspects mailman will eat it; please >> simply reply to fedora-extras-list manually to avoid further >> crossposting and slitted discussions; tia! > mailman seems to do fine ;) No, it eat it, as the post on fedora-packaging at redhat.com would have had set "Reply-to: fedora-extras-list at redhat.com" Anyway, we discussed this topic in the FESCo meeting last Thursday. The result was: It's job of the packaging committee to codify some rules around this and FESCo's job will be to implement them afterwards. rdieter promised to bring it up the packaging committee, so all further discussion should be held on fedora-packaging at redhat.com to avoid confusion. Cu thl From Axel.Thimm at ATrpms.net Sat Dec 16 13:50:24 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 16 Dec 2006 14:50:24 +0100 Subject: [Fedora-packaging] Re: what policy for python egg files In-Reply-To: <200612161316.08764.jamatos@fc.up.pt> References: <200612152347.17221.jamatos@fc.up.pt> <20061216130905.GG14601@neu.nirvana> <200612161316.08764.jamatos@fc.up.pt> Message-ID: <20061216135024.GH14601@neu.nirvana> On Sat, Dec 16, 2006 at 01:16:08PM +0000, Jos? Matos wrote: > On Saturday 16 December 2006 1:09 pm, Axel Thimm wrote: > > egg is a packaging method that is orthogonal to what we use. Leaving > > the eggs around may get users to start using egg-installation and get > > files on the system unregistered by rpm. > > > > Or not? If the above is correct eggs should even be banned just as > > other non-native package formats are banned (debs or tarballs for > > example). > > On one hand I agree with Axel, on the other this allows installations per > user, no? > > What is our policy regarding other programming language ( with their > repositories cpan, cran, ctan)... A user may download tarballs, cpan/ctan, alienated debs and install them under $HOME or /usr/local, we don't mandate anything about that places. But we wouldn't start shipping rpm-foreign bits to endorse people doing so - especially not, if they would override the rpm itself that is shipping the egg for example. E.g. the user has an issue with the package (maybe a real bug, maybe just not rtfm), sees the egg, erroneously thinks that he needs to complete the rpm installation by using it and does so. Later package updates are not seen anymore by the user, since he's using a local copy of the previous package. > This should probably be a general policy, no? Well, even if it is not written down somewhere explicitely it is rather assumed. It is also a difficult wording, of course the user is free to use debs, ctan, eggs and so on, and we won't explicitely forbid this, but we shouldn't push users to do so either. Perhaps: "Packaging tarballs or other non-rpm packaging formats within the package is strongly discoursaged as it may misguide users to override the package by using them" -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dlutter at redhat.com Mon Dec 18 17:47:48 2006 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 18 Dec 2006 17:47:48 +0000 Subject: [Fedora-packaging] Re: what policy for python egg files In-Reply-To: <20061216130905.GG14601@neu.nirvana> References: <200612152347.17221.jamatos@fc.up.pt> <20061216130905.GG14601@neu.nirvana> Message-ID: <1166464068.4534.8.camel@localhost.localdomain> On Sat, 2006-12-16 at 14:09 +0100, Axel Thimm wrote: > On Fri, Dec 15, 2006 at 07:43:04PM -0600, Jason L Tibbitts III wrote: > > >>>>> "TK" == Toshio Kuratomi writes: > > > > TK> I think tibbs had the opposite viewpoint but I don't remember if > > TK> we got to a point where he decided it didn't matter or we came to > > TK> an agreement or just let it drop. > > > > I guess the point is that I can't figure out what additional value it > > adds, and in general it's bad to package up something that's > > completely needless. > > egg is a packaging method that is orthogonal to what we use. Leaving > the eggs around may get users to start using egg-installation and get > files on the system unregistered by rpm. > > Or not? If the above is correct eggs should even be banned just as > other non-native package formats are banned (debs or tarballs for > example). The crucial issue are the dependencies that right now have to stay within each packaging format; if rpm's can't contain any egg (or gem or whatnot) info, users will end up installing the same package twice, just to fulfill dependencies completely within each packaging system. It would be much more userfriendly if we laid the groundwork for other packaging systems to depend on rpm-installed bits; that mostly means to _allow_ inclusion of non-rpm packaging metadata in rpms. David From a.badger at gmail.com Mon Dec 18 18:18:20 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 18 Dec 2006 10:18:20 -0800 Subject: [Fedora-packaging] Re: what policy for python egg files In-Reply-To: <1166464068.4534.8.camel@localhost.localdomain> References: <200612152347.17221.jamatos@fc.up.pt> <20061216130905.GG14601@neu.nirvana> <1166464068.4534.8.camel@localhost.localdomain> Message-ID: <1166465900.21769.10.camel@localhost.localdomain> On Mon, 2006-12-18 at 17:47 +0000, David Lutterkort wrote: > On Sat, 2006-12-16 at 14:09 +0100, Axel Thimm wrote: > > On Fri, Dec 15, 2006 at 07:43:04PM -0600, Jason L Tibbitts III wrote: > > > >>>>> "TK" == Toshio Kuratomi writes: > > > > > > TK> I think tibbs had the opposite viewpoint but I don't remember if > > > TK> we got to a point where he decided it didn't matter or we came to > > > TK> an agreement or just let it drop. > > > > > > I guess the point is that I can't figure out what additional value it > > > adds, and in general it's bad to package up something that's > > > completely needless. > > > > egg is a packaging method that is orthogonal to what we use. Leaving > > the eggs around may get users to start using egg-installation and get > > files on the system unregistered by rpm. > > > > Or not? If the above is correct eggs should even be banned just as > > other non-native package formats are banned (debs or tarballs for > > example). > > The crucial issue are the dependencies that right now have to stay > within each packaging format; if rpm's can't contain any egg (or gem or > whatnot) info, users will end up installing the same package twice, just > to fulfill dependencies completely within each packaging system. > > It would be much more userfriendly if we laid the groundwork for other > packaging systems to depend on rpm-installed bits; that mostly means to > _allow_ inclusion of non-rpm packaging metadata in rpms. +1 Some end users are going to install via eggs/gems/cpan anyways. It's better if we allow them to use as many FE packages as possible when they do this, rather than forcing them to install duplicates of packages they already have installed via rpm. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Mon Dec 18 18:23:29 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 18 Dec 2006 19:23:29 +0100 Subject: [Fedora-packaging] Re: what policy for python egg files In-Reply-To: <1166464068.4534.8.camel@localhost.localdomain> References: <200612152347.17221.jamatos@fc.up.pt> <20061216130905.GG14601@neu.nirvana> <1166464068.4534.8.camel@localhost.localdomain> Message-ID: <20061218182329.GC9890@neu.nirvana> On Mon, Dec 18, 2006 at 05:47:48PM +0000, David Lutterkort wrote: > On Sat, 2006-12-16 at 14:09 +0100, Axel Thimm wrote: > > On Fri, Dec 15, 2006 at 07:43:04PM -0600, Jason L Tibbitts III wrote: > > > >>>>> "TK" == Toshio Kuratomi writes: > > > > > > TK> I think tibbs had the opposite viewpoint but I don't remember if > > > TK> we got to a point where he decided it didn't matter or we came to > > > TK> an agreement or just let it drop. > > > > > > I guess the point is that I can't figure out what additional value it > > > adds, and in general it's bad to package up something that's > > > completely needless. > > > > egg is a packaging method that is orthogonal to what we use. Leaving > > the eggs around may get users to start using egg-installation and get > > files on the system unregistered by rpm. > > > > Or not? If the above is correct eggs should even be banned just as > > other non-native package formats are banned (debs or tarballs for > > example). > > The crucial issue are the dependencies that right now have to stay > within each packaging format; if rpm's can't contain any egg (or gem or > whatnot) info, users will end up installing the same package twice, just > to fulfill dependencies completely within each packaging system. Don't you have the same issue if you install the egg with -Z? If not, then the (egg-)package dependencies are obvioulsy spooled somewhere on disk for easy_install and friends to find. > It would be much more userfriendly if we laid the groundwork for other > packaging systems to depend on rpm-installed bits; that mostly means to > _allow_ inclusion of non-rpm packaging metadata in rpms. If you like so, having "egg-provides" is fine, of course. Just like we have foo.pc, but don't keep the full tarball around. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Dec 18 18:49:35 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 18 Dec 2006 19:49:35 +0100 Subject: [Fedora-packaging] Re: what policy for python egg files In-Reply-To: <20061218182329.GC9890@neu.nirvana> References: <200612152347.17221.jamatos@fc.up.pt> <20061216130905.GG14601@neu.nirvana> <1166464068.4534.8.camel@localhost.localdomain> <20061218182329.GC9890@neu.nirvana> Message-ID: <20061218184935.GF9890@neu.nirvana> On Mon, Dec 18, 2006 at 07:23:29PM +0100, Axel Thimm wrote: > On Mon, Dec 18, 2006 at 05:47:48PM +0000, David Lutterkort wrote: > > On Sat, 2006-12-16 at 14:09 +0100, Axel Thimm wrote: > > > On Fri, Dec 15, 2006 at 07:43:04PM -0600, Jason L Tibbitts III wrote: > > > > >>>>> "TK" == Toshio Kuratomi writes: > > > > > > > > TK> I think tibbs had the opposite viewpoint but I don't remember if > > > > TK> we got to a point where he decided it didn't matter or we came to > > > > TK> an agreement or just let it drop. > > > > > > > > I guess the point is that I can't figure out what additional value it > > > > adds, and in general it's bad to package up something that's > > > > completely needless. > > > > > > egg is a packaging method that is orthogonal to what we use. Leaving > > > the eggs around may get users to start using egg-installation and get > > > files on the system unregistered by rpm. > > > > > > Or not? If the above is correct eggs should even be banned just as > > > other non-native package formats are banned (debs or tarballs for > > > example). > > > > The crucial issue are the dependencies that right now have to stay > > within each packaging format; if rpm's can't contain any egg (or gem or > > whatnot) info, users will end up installing the same package twice, just > > to fulfill dependencies completely within each packaging system. > > Don't you have the same issue if you install the egg with -Z? If not, > then the (egg-)package dependencies are obvioulsy spooled somewhere on > disk for easy_install and friends to find. Looks like all has been considered in advance by the egg folks: > --single-version-externally-managed > This boolean option tells the install command to perform an "old > style" installation, with the addition of an .egg-info directory > so that the installed project will still have its metadata > available and operate normally. If you use this option, you must > also specify the --root or --record options (or both), because > otherwise you will have no way to identify and remove the > installed files. > > It would be much more userfriendly if we laid the groundwork for other > > packaging systems to depend on rpm-installed bits; that mostly means to > > _allow_ inclusion of non-rpm packaging metadata in rpms. > > If you like so, having "egg-provides" is fine, of course. Just like we > have foo.pc, but don't keep the full tarball around. The equivalent to *.pc files seem to be the .egg-info subdirs. So we don't need to ship the egg file in addition within the rpm file, but still feed the egg packaging system with information. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Mon Dec 18 20:33:19 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 18 Dec 2006 12:33:19 -0800 Subject: [Fedora-packaging] Re: what policy for python egg files In-Reply-To: <20061218184935.GF9890@neu.nirvana> References: <200612152347.17221.jamatos@fc.up.pt> <20061216130905.GG14601@neu.nirvana> <1166464068.4534.8.camel@localhost.localdomain> <20061218182329.GC9890@neu.nirvana> <20061218184935.GF9890@neu.nirvana> Message-ID: <1166473999.21769.16.camel@localhost.localdomain> On Mon, 2006-12-18 at 19:49 +0100, Axel Thimm wrote: > On Mon, Dec 18, 2006 at 07:23:29PM +0100, Axel Thimm wrote: > > On Mon, Dec 18, 2006 at 05:47:48PM +0000, David Lutterkort wrote: > > > The crucial issue are the dependencies that right now have to stay > > > within each packaging format; if rpm's can't contain any egg (or gem or > > > whatnot) info, users will end up installing the same package twice, just > > > to fulfill dependencies completely within each packaging system. > > > > Don't you have the same issue if you install the egg with -Z? If not, > > then the (egg-)package dependencies are obvioulsy spooled somewhere on > > disk for easy_install and friends to find. > > Looks like all has been considered in advance by the egg folks: > > > --single-version-externally-managed > > This boolean option tells the install command to perform an "old > > style" installation, with the addition of an .egg-info directory > > so that the installed project will still have its metadata > > available and operate normally. If you use this option, you must > > also specify the --root or --record options (or both), because > > otherwise you will have no way to identify and remove the > > installed files. > > > > It would be much more userfriendly if we laid the groundwork for other > > > packaging systems to depend on rpm-installed bits; that mostly means to > > > _allow_ inclusion of non-rpm packaging metadata in rpms. > > > > If you like so, having "egg-provides" is fine, of course. Just like we > > have foo.pc, but don't keep the full tarball around. > > The equivalent to *.pc files seem to be the .egg-info subdirs. So we > don't need to ship the egg file in addition within the rpm file, but > still feed the egg packaging system with information. Heh. This is what we've been doing :-) From lmacken's TurboMail spec, for instance: %files %defattr(-,root,root,-) %{python_sitelib}/TurboMail-%{version}-py%{pyver}.egg-info -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Mon Dec 18 21:40:56 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 18 Dec 2006 22:40:56 +0100 Subject: [Fedora-packaging] Re: what policy for python egg files In-Reply-To: <1166473999.21769.16.camel@localhost.localdomain> References: <200612152347.17221.jamatos@fc.up.pt> <20061216130905.GG14601@neu.nirvana> <1166464068.4534.8.camel@localhost.localdomain> <20061218182329.GC9890@neu.nirvana> <20061218184935.GF9890@neu.nirvana> <1166473999.21769.16.camel@localhost.localdomain> Message-ID: <20061218214056.GG9890@neu.nirvana> On Mon, Dec 18, 2006 at 12:33:19PM -0800, Toshio Kuratomi wrote: > On Mon, 2006-12-18 at 19:49 +0100, Axel Thimm wrote: > > On Mon, Dec 18, 2006 at 07:23:29PM +0100, Axel Thimm wrote: > > > On Mon, Dec 18, 2006 at 05:47:48PM +0000, David Lutterkort wrote: > > > > The crucial issue are the dependencies that right now have to stay > > > > within each packaging format; if rpm's can't contain any egg (or gem or > > > > whatnot) info, users will end up installing the same package twice, just > > > > to fulfill dependencies completely within each packaging system. > > > > > > Don't you have the same issue if you install the egg with -Z? If not, > > > then the (egg-)package dependencies are obvioulsy spooled somewhere on > > > disk for easy_install and friends to find. > > > > Looks like all has been considered in advance by the egg folks: > > > > > --single-version-externally-managed > > > This boolean option tells the install command to perform an "old > > > style" installation, with the addition of an .egg-info directory > > > so that the installed project will still have its metadata > > > available and operate normally. If you use this option, you must > > > also specify the --root or --record options (or both), because > > > otherwise you will have no way to identify and remove the > > > installed files. > > > > > > It would be much more userfriendly if we laid the groundwork for other > > > > packaging systems to depend on rpm-installed bits; that mostly means to > > > > _allow_ inclusion of non-rpm packaging metadata in rpms. > > > > > > If you like so, having "egg-provides" is fine, of course. Just like we > > > have foo.pc, but don't keep the full tarball around. > > > > The equivalent to *.pc files seem to be the .egg-info subdirs. So we > > don't need to ship the egg file in addition within the rpm file, but > > still feed the egg packaging system with information. > > Heh. This is what we've been doing :-) Then why are we trying to change that? > From lmacken's TurboMail spec, for instance: > %files > %defattr(-,root,root,-) > %{python_sitelib}/TurboMail-%{version}-py%{pyver}.egg-info -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Mon Dec 18 22:01:27 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 18 Dec 2006 14:01:27 -0800 Subject: [Fedora-packaging] Re: what policy for python egg files In-Reply-To: <20061218214056.GG9890@neu.nirvana> References: <200612152347.17221.jamatos@fc.up.pt> <20061216130905.GG14601@neu.nirvana> <1166464068.4534.8.camel@localhost.localdomain> <20061218182329.GC9890@neu.nirvana> <20061218184935.GF9890@neu.nirvana> <1166473999.21769.16.camel@localhost.localdomain> <20061218214056.GG9890@neu.nirvana> Message-ID: <1166479288.21769.46.camel@localhost.localdomain> On Mon, 2006-12-18 at 22:40 +0100, Axel Thimm wrote: > On Mon, Dec 18, 2006 at 12:33:19PM -0800, Toshio Kuratomi wrote: > > On Mon, 2006-12-18 at 19:49 +0100, Axel Thimm wrote: > > > The equivalent to *.pc files seem to be the .egg-info subdirs. So we > > > don't need to ship the egg file in addition within the rpm file, but > > > still feed the egg packaging system with information. > > > > Heh. This is what we've been doing :-) > > Then why are we trying to change that? > > > From lmacken's TurboMail spec, for instance: > > %files > > %defattr(-,root,root,-) > > %{python_sitelib}/TurboMail-%{version}-py%{pyver}.egg-info I think it was confusion from inexact wording in the original post. I knew what lmacken had been doing in Turbo* packages so I replied with the idea that "egg files" meant these files inside the .egg-info directory. Meanwhile you took it to mean the zipped up PACKAGE.egg files. In any case, it looks like TurboMail was approved and the cvs version shows that it's including the .egg_info directory not the .egg files. I think we're in agreement that this is the correct way to go? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Mon Dec 18 22:06:17 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 18 Dec 2006 23:06:17 +0100 Subject: [Fedora-packaging] Re: what policy for python egg files In-Reply-To: <1166479288.21769.46.camel@localhost.localdomain> References: <200612152347.17221.jamatos@fc.up.pt> <20061216130905.GG14601@neu.nirvana> <1166464068.4534.8.camel@localhost.localdomain> <20061218182329.GC9890@neu.nirvana> <20061218184935.GF9890@neu.nirvana> <1166473999.21769.16.camel@localhost.localdomain> <20061218214056.GG9890@neu.nirvana> <1166479288.21769.46.camel@localhost.localdomain> Message-ID: <20061218220617.GI9890@neu.nirvana> On Mon, Dec 18, 2006 at 02:01:27PM -0800, Toshio Kuratomi wrote: > On Mon, 2006-12-18 at 22:40 +0100, Axel Thimm wrote: > > On Mon, Dec 18, 2006 at 12:33:19PM -0800, Toshio Kuratomi wrote: > > > On Mon, 2006-12-18 at 19:49 +0100, Axel Thimm wrote: > > > > The equivalent to *.pc files seem to be the .egg-info subdirs. So we > > > > don't need to ship the egg file in addition within the rpm file, but > > > > still feed the egg packaging system with information. > I think it was confusion from inexact wording in the original post. I > knew what lmacken had been doing in Turbo* packages so I replied with > the idea that "egg files" meant these files inside the .egg-info > directory. Meanwhile you took it to mean the zipped up PACKAGE.egg > files. > > In any case, it looks like TurboMail was approved and the cvs version > shows that it's including the .egg_info directory not the .egg files. > > I think we're in agreement that this is the correct way to go? Fully. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at city-fan.org Tue Dec 19 08:36:43 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 19 Dec 2006 08:36:43 +0000 Subject: [Fedora-packaging] More Mono confusion Message-ID: <1166517403.28834.9.camel@metropolis.intra.city-fan.org> I have a mono-based package called "lat", which I believe follows the current packaging guidelines, i.e. it installs lat.exe and its associated DLLs into %{_libdir}/lat. The package has dependencies on some mono packages from Core, particularly avahi-sharp. On x86_64, the avahi-sharp package contains: /usr/lib/mono/avahi-sharp /usr/lib/mono/avahi-sharp/avahi-sharp.dll /usr/lib/mono/gac/avahi-sharp /usr/lib/mono/gac/avahi-sharp/1.0.0.0__4d116c78973743f5 /usr/lib/mono/gac/avahi-sharp/1.0.0.0__4d116c78973743f5/avahi-sharp.dll /usr/lib/mono/gac/avahi-sharp/1.0.0.0__4d116c78973743f5/avahi-sharp.dll.config /usr/lib/mono/gac/avahi-sharp/1.0.0.0__4d116c78973743f5/avahi-sharp.dll.mdb /usr/lib64/pkgconfig/avahi-sharp.pc So avahi-sharp.dll is in /usr/lib rather than %{_libdir} When I try to start lat on x86_64, I get: $ lat lat [09776] INFO Starting lat (version 1.2.1.1) ** (lat:9776): WARNING **: The following assembly referenced from /usr/lib64/lat/lat.exe could not be loaded: Assembly: avahi-sharp (assemblyref_index=14) Version: 1.0.0.0 Public Key: 4d116c78973743f5 The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/usr/lib64/lat). ** (lat:9776): WARNING **: Could not load file or assembly 'avahi-sharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=4d116c78973743f5' or one of its dependencies. lat [09776] ERROR Error occured: Could not load file or assembly 'avahi-sharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=4d116c78973743f5' or one of its dependencies. lat [09776] INFO Exiting lat I can work around this though: $ MONO_PATH=/usr/lib/mono lat That works. So my question is: is my package in error, or is it avahi-sharp? Should I set $MONO_PATH in /usr/bin/lat? Paul. From bpepple at fedoraproject.org Tue Dec 19 15:10:41 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 19 Dec 2006 10:10:41 -0500 Subject: [Fedora-packaging] More Mono confusion In-Reply-To: <1166517403.28834.9.camel@metropolis.intra.city-fan.org> References: <1166517403.28834.9.camel@metropolis.intra.city-fan.org> Message-ID: <1166541041.10916.2.camel@Chuck> On Tue, 2006-12-19 at 08:36 +0000, Paul Howarth wrote: > > So my question is: is my package in error, or is it avahi-sharp? Should > I set $MONO_PATH in /usr/bin/lat? I believe Avahi-sharp should be fixed to follow the mono packaging guideline. There's been a bug opened on this for a while, but I've been fairly busy and haven't had any time to look into it. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185692 /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 a.badger at gmail.com Tue Dec 19 17:04:43 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 Dec 2006 09:04:43 -0800 Subject: [Fedora-packaging] More Mono confusion In-Reply-To: <1166541041.10916.2.camel@Chuck> References: <1166517403.28834.9.camel@metropolis.intra.city-fan.org> <1166541041.10916.2.camel@Chuck> Message-ID: <1166547883.21769.55.camel@localhost.localdomain> On Tue, 2006-12-19 at 10:10 -0500, Brian Pepple wrote: > On Tue, 2006-12-19 at 08:36 +0000, Paul Howarth wrote: > > > > So my question is: is my package in error, or is it avahi-sharp? Should > > I set $MONO_PATH in /usr/bin/lat? > > I believe Avahi-sharp should be fixed to follow the mono packaging > guideline. There's been a bug opened on this for a while, but I've been > fairly busy and haven't had any time to look into it. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185692 I believe Brian's correct. Looking through that bug, it appears that avahi-sharp was moved to /usr/lib/ instead of %{_libdir} before mono's shared dirs were moved to %{_libdir}. It has not been moved back. It looks like there's a short patch and a snippet in the spec file that need to be reverted in order to fix this. I'll submit those to the bug report. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Tue Dec 19 19:56:09 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 19 Dec 2006 13:56:09 -0600 Subject: [Fedora-packaging] Re: rawhide report: 20061219 changes In-Reply-To: <45883489.4040603@FamilleCollet.com> References: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> <45883489.4040603@FamilleCollet.com> Message-ID: >>>>> "RC" == Remi Collet writes: > php-5.2.0-8 > ----------- > * Tue Dec 05 2006 Joe Orton 5.2.0-8 > - fix filter.h installation path > - fix php-zend-abi version (Remi Collet, #212804) RC> I think this new virtual provides give us the opportunity to RC> modify the "Guidelines for packaging PHP addon modules" for all RC> pecl packages to require this (fc6 and fc7) Could you elaborate on that a bit? We currently have mandate Requires: php-abi = version; how would we use php-zend-abi? - J< From rdieter at math.unl.edu Wed Dec 20 14:45:11 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Dec 2006 08:45:11 -0600 Subject: [Fedora-packaging] Re: icon cache scriplet guideline update In-Reply-To: <45894A49.6040707@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <1166624235.5608.49.camel@max.booze> <45894A49.6040707@math.unl.edu> Message-ID: <45894C77.4090903@math.unl.edu> Rex Dieter wrote: > Callum Lerwick wrote: >> On Wed, 2006-12-20 at 07:43 -0600, Rex Dieter wrote: >>> Because, frankly, poo-pooing the current proposal/guidelines in favor >>> of some handy-wavy theoretical lacking-actual-implementation >>> solution, is no solution. >> >> Well, the point is, the current proposal does not address the "multiple >> packages needlessly updating caches multiple times" problem at all. > > Fair enough, I'll investigate hooking into rpm's %posttrans hooks. My > findings so far are promising. I formally withdraw the iconcache proposal as-is, pending investigation of the previously unaddressed "needlessly updating cache multiple times" issue. -- Rex From rdieter at math.unl.edu Wed Dec 20 16:00:55 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Dec 2006 10:00:55 -0600 Subject: [Fedora-packaging] Re: %posttrans scriptlet In-Reply-To: <45894C77.4090903@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <1166624235.5608.49.camel@max.booze> <45894A49.6040707@math.unl.edu> <45894C77.4090903@math.unl.edu> Message-ID: <45895E37.2060609@math.unl.edu> Rex Dieter wrote: > I formally withdraw the iconcache proposal as-is, pending investigation > of the previously unaddressed "needlessly updating cache multiple times" > issue. OK, %posttrans doesn't seem to work as I expect it to (on fc6). (specfile attached) %posttrans runs on installs (good), but not on uninstall (bad). Any ideas? Am I misunderstanding it, or is this possibly an rpm bug? $ rpm -q rpm rpm-4.4.2-32 $ rpm -U posttrans-test-1.0-1.noarch.rpm %pretrans: %pre: %post: touch %posttrans: gtk-update-icon-cacheCache file created successfully. $ rpm -e posttrans-test %preun: %postun: touch -- Rex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: posttrans-test.spec URL: From rdieter at math.unl.edu Wed Dec 20 17:42:40 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Dec 2006 11:42:40 -0600 Subject: [Fedora-packaging] Re: icon cache scriplets, using %posttrans In-Reply-To: <45894A49.6040707@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <1166624235.5608.49.camel@max.booze> <45894A49.6040707@math.unl.edu> Message-ID: <45897610.9050805@math.unl.edu> Rex Dieter wrote: > Callum Lerwick wrote: >> On Wed, 2006-12-20 at 07:43 -0600, Rex Dieter wrote: >>> Because, frankly, poo-pooing the current proposal/guidelines in favor >>> of some handy-wavy theoretical lacking-actual-implementation >>> solution, is no solution. >> >> Well, the point is, the current proposal does not address the "multiple >> packages needlessly updating caches multiple times" problem at all. > > Fair enough, I'll investigate hooking into rpm's %posttrans hooks. My > findings so far are promising. How about something like this? %posttrans operations run at the end of the rpm transaction(1), only the first gtk-update-icon-cache would take any real cpu time (subsequent runs of gtk-update-icon-cache are smart enough to know the cache is not stale, and run virtually instantly). I'll look into patching xdg-icon-utils into doing a "smart" update operation (like gtk-update-*), but until then, we need to use gtk-update-icon-cache here. ########################## %post touch --no-create %_datadir/icons/hicolor ||: %postun touch --no-create %_datadir/icons/hicolor ||: # Keep this until http://bugzilla.redhat.com/170335 is fixed %posttrans gtk-update-icon-cache -q %_datadir/icons/hicolor >& /dev/null ||: ########################## In my testing using a fair-to-middlin laptop, gtk-update-icon-cache takes 0.5-1.0 seconds to regenerate a stale cache, so doing it this way, if I had to install/update 10 icon-using apps, I'd save ~5-10 seconds install time. Not too shabby. (1) This same trick could be used for other expensive scriptlet operations too. ldconfig, in general, is not a good candidate for this, since items installed by one rpm may be needed by subsequent items within the same transaction. -- Rex From notting at redhat.com Wed Dec 20 17:44:04 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Dec 2006 12:44:04 -0500 Subject: [Fedora-packaging] Re: %posttrans scriptlet In-Reply-To: <45895E37.2060609@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <1166624235.5608.49.camel@max.booze> <45894A49.6040707@math.unl.edu> <45894C77.4090903@math.unl.edu> <45895E37.2060609@math.unl.edu> Message-ID: <20061220174404.GC12415@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > %posttrans runs on installs (good), but not on uninstall (bad). Any > ideas? Am I misunderstanding it, or is this possibly an rpm bug? Without actually looking, is there %postuntrans or %posttransun? Bill, shuddering at the concept of %triggerpostuntrans From notting at redhat.com Wed Dec 20 17:45:45 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Dec 2006 12:45:45 -0500 Subject: [Fedora-packaging] Re: %posttrans scriptlet In-Reply-To: <20061220174404.GC12415@nostromo.devel.redhat.com> References: <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <1166624235.5608.49.camel@max.booze> <45894A49.6040707@math.unl.edu> <45894C77.4090903@math.unl.edu> <45895E37.2060609@math.unl.edu> <20061220174404.GC12415@nostromo.devel.redhat.com> Message-ID: <20061220174545.GD12415@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Rex Dieter (rdieter at math.unl.edu) said: > > %posttrans runs on installs (good), but not on uninstall (bad). Any > > ideas? Am I misunderstanding it, or is this possibly an rpm bug? > > Without actually looking, is there %postuntrans or %posttransun? And the answer is 'no', thank goodness. Bill From rdieter at math.unl.edu Wed Dec 20 17:48:09 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Dec 2006 11:48:09 -0600 Subject: [Fedora-packaging] Re: %posttrans scriptlet In-Reply-To: <20061220174404.GC12415@nostromo.devel.redhat.com> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <1166624235.5608.49.camel@max.booze> <45894A49.6040707@math.unl.edu> <45894C77.4090903@math.unl.edu> <45895E37.2060609@math.unl.edu> <20061220174404.GC12415@nostromo.devel.redhat.com> Message-ID: <45897759.7020306@math.unl.edu> Bill Nottingham wrote: > Rex Dieter (rdieter at math.unl.edu) said: >> %posttrans runs on installs (good), but not on uninstall (bad). Any >> ideas? Am I misunderstanding it, or is this possibly an rpm bug? > > Without actually looking, is there %postuntrans or %posttransun? Yes, it apparently exists (postuntrans, preuntrans), but they (too) don't seem to work for single package erasure. I think it's (mostly) ok: 1. That'll like be a corner case that doesn't happen too often in practice. 2. I consider it an rpm bug, which we should be able to drive to get fixed, right? (: -- Rex From katzj at redhat.com Wed Dec 20 18:06:24 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Dec 2006 13:06:24 -0500 Subject: [Fedora-packaging] Re: icon cache scriplets, using %posttrans In-Reply-To: <45897610.9050805@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <1166624235.5608.49.camel@max.booze> <45894A49.6040707@math.unl.edu> <45897610.9050805@math.unl.edu> Message-ID: <1166637984.10717.30.camel@aglarond.local> On Wed, 2006-12-20 at 11:42 -0600, Rex Dieter wrote: > Rex Dieter wrote: > > Callum Lerwick wrote: > >> On Wed, 2006-12-20 at 07:43 -0600, Rex Dieter wrote: > >>> Because, frankly, poo-pooing the current proposal/guidelines in favor > >>> of some handy-wavy theoretical lacking-actual-implementation > >>> solution, is no solution. > >> > >> Well, the point is, the current proposal does not address the "multiple > >> packages needlessly updating caches multiple times" problem at all. > > > > Fair enough, I'll investigate hooking into rpm's %posttrans hooks. My > > findings so far are promising. > > How about something like this? %posttrans operations run at the end of > the rpm transaction(1), only the first gtk-update-icon-cache would take > any real cpu time (subsequent runs of gtk-update-icon-cache are smart > enough to know the cache is not stale, and run virtually instantly). The problem is that this is still just working around the problem... if we start moving towards doing multiple transactions[1], then the script starts to run more times and we can watch the benefit start to dwindle. I think instead of doing a paper-over fix like this, we really need to look at the cases that scriptlets are used in and see if there's a way to have a "smarter scriptlet"[2] with rpm moving forward Jeremy [1] There are definitely advantages as far as memory usage in doing this as well as resiliency to things "going wrong" during the transaction. I'm not sure what the real effect on time would be of doing so. It's definitely something that I at least want to do more investigation of [2] This is one of the things that I think conary has gotten right :-) From rdieter at math.unl.edu Wed Dec 20 18:33:03 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Dec 2006 12:33:03 -0600 Subject: [Fedora-packaging] Re: Re: icon cache scriplets References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <1166624235.5608.49.camel@max.booze> <45894A49.6040707@math.unl.edu> <45897610.9050805@math.unl.edu> <1166637984.10717.30.camel@aglarond.local> Message-ID: Jeremy Katz wrote: > On Wed, 2006-12-20 at 11:42 -0600, Rex Dieter wrote: >> Rex Dieter wrote: >> How about something like this? %posttrans operations run at the end of >> the rpm transaction(1), only the first gtk-update-icon-cache would take >> any real cpu time (subsequent runs of gtk-update-icon-cache are smart >> enough to know the cache is not stale, and run virtually instantly). > > The problem is that this is still just working around the problem... Of course it's a workaround! Modulo workarounds, I'm back to advocating dropping gtk-update-icon-cache from scriptlet guidelines altogether, effectively forcing issue wrt existing gtk2 packaging bug, ie, gtk2 currently contains no mechanism to create/refresh it's own icon cache. -- Rex From Fedora at FamilleCollet.com Wed Dec 20 20:20:10 2006 From: Fedora at FamilleCollet.com (Remi Collet) Date: Wed, 20 Dec 2006 21:20:10 +0100 Subject: [Fedora-packaging] Packaging/PHP : some update proposal Message-ID: <45899AFA.9040205@FamilleCollet.com> Here is some updates proposal for the Guidelines for packaging PHP addon modules 1 ------ No file in BUILD directory PEAR & PECL Packages The source archive contains a package.xml outside any directory, so you should/must use %setup -q -c 2 ----- Initial spec. PEAR Packages To create your specfile, you could use the default template provided by rpmdevtools or generate one with the command "pear make-rpm-spec Sources.tgz" (install php-pear-PEAR-Command-Packaging) 3 ---- API version check PECL Packages With php-5.1.6-3.3 on FC6 and php-5.2.0-8 on rawhide php-common now provide php-zend-api. This exact version must be require by pecl extension. The php-common in Fedora Core 7 and above (version 5.2.0-8) provides several useful macros: %{php_core_api} %{php_zend_api} %{php_pdo_api} Solution 1 (using the macros, only available on rawhide) %if %{?php_zend_api}0 Requires: php_zend_api = %{php_zend_api} %endif Solution 2 (not using the /etc/rpm/macros.php) %global php_zendapi %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP Extension => //p') | tail -1) %if %{fedora} >= 6 Requires: php_zend_api = %{php_zendapi} %endif We can also post a RFE on php to also provide the macros on FC6 --- Some comments. A load time, PHP check that each extension is compatible. php_dl.c compare ZEND_MODULE_API_NO value at php build time and at extension build time. If this values doesn't match, the extension is not loaded and an error is displayed : > PHP Warning: PHP Startup: mailparse: Unable to initialize module > Module compiled with module API=20060613, debug=0, thread-safety=0 > PHP compiled with module API=20050922, debug=0, thread-safety=0 > These options need to match > php-abi (PHP_API_VERSION) is 20041225 for a very long time. php-zend-abi (ZEND_MODULE_API_NO) is the true API version need to check extension compatibility Ex : php-5.1.4, 5.1.5, 5.1.6 PHP Api Version: 20041225 Zend Module Api No: 20050922 php-5.2.0 PHP Api Version: 20041225 Zend Module Api No: 20060613 See Bugzilla #212804 Requires: php-api could be keep, but is not very useful Thanks for your comments, I could edit the wiki if this is approved and if you want me to do it. Remi. P.S. i hope this is clear ? From jkeating at redhat.com Wed Dec 20 20:35:50 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 15:35:50 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash. Message-ID: <200612201535.50971.jkeating@redhat.com> A while ago we had a long discussion about the naming of jpackage packages within Fedora. Currently the naming convention that is used by Fedora for jpackage packages does not mesh with the Fedora Packaging Guidelines. See http://fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming There are a number of proposals on that page, but the one I'd like to focus on is http://fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming#Proposal_1 This changes how we number the Fedora spins of the jpackage packages, but doesn't introduce any extra chars into the version/release. Please, jpackage folks who are now on this list, review the page and the proposal and comment / suggest / flame / whatever. Please note that part of the core/extras merge, every package will be reviewed, and currently the jpackage packages (of which there are many, and some 90~ new ones pending for maven2) will not pass the review. Resolution on this matter is urgent. Thanks! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Wed Dec 20 22:43:13 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 21 Dec 2006 00:43:13 +0200 Subject: [Fedora-packaging] Re: %posttrans scriptlet In-Reply-To: <45897759.7020306@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <1166624235.5608.49.camel@max.booze> <45894A49.6040707@math.unl.edu> <45894C77.4090903@math.unl.edu> <45895E37.2060609@math.unl.edu> <20061220174404.GC12415@nostromo.devel.redhat.com> <45897759.7020306@math.unl.edu> Message-ID: <1166654593.4142.37.camel@viper.local> On Wed, 2006-12-20 at 11:48 -0600, Rex Dieter wrote: > Bill Nottingham wrote: > > Rex Dieter (rdieter at math.unl.edu) said: > >> %posttrans runs on installs (good), but not on uninstall (bad). Any > >> ideas? Am I misunderstanding it, or is this possibly an rpm bug? > > > > Without actually looking, is there %postuntrans or %posttransun? > > Yes, it apparently exists (postuntrans, preuntrans), but they (too) > don't seem to work for single package erasure. > > I think it's (mostly) ok: > 1. That'll like be a corner case that doesn't happen too often in practice. > 2. I consider it an rpm bug, which we should be able to drive to get > fixed, right? (: There's quite a bit of related discussion at http://thread.gmane.org/gmane.linux.redhat.rpm.devel/547/ From a.badger at gmail.com Thu Dec 21 04:55:25 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 20 Dec 2006 20:55:25 -0800 Subject: [Fedora-packaging] Proposal to limit file deps Message-ID: <1166676925.21769.97.camel@localhost.localdomain> Hey all, I've just added a draft proposal for limiting file dependencies in packages. It's a "should" recommendation at this point. http://www.fedoraproject.org/wiki/PackagingDrafts/FileDeps = File Deps Guideline = == Problem == Resolving file dependencies can be a bottleneck when running yum. With our current repodata format, information on which package owns files in /etc and the bin directories (/bin /sbin /usr/bin /usr/sbin) are kept in primary.xml. All other file deps are kept in filelist.xml. This means that anytime yum has to resolve a file dep in /etc or a bin directory it can just download primary.xml to resolve it. If the file dep is outside of those directories, yum has to download and parse a second xml file, filelist.xml, which is much larger than primary.xml. Fedora 6 repodata compressed and uncompressed: || ||primary.xml||filelist.xml|| ||Core ||1M/7.6M ||3.1M/39.2M|| ||Extras ||4.7M/11.7M ||4M/50.8M|| ||Updates||0.4M/4.2M ||2.1M/27.5M|| The compressed size has direct bearing on the additional time it will take to download the additional filelist.xml. The uncompressed size is one indicator of how much additional time is needed to parse for the file that satisfies the dependency. If yum does not need to refresh its primary.xml and filelist.xml (because it downloaded a copy previously and the repository has not been updated since), yum won't have to parse a new file and the filelist info will be quicker to find (as the file will have been parsed into an sqlite database), however this is the exception rather than the rule. If we can avoid having to download and parse filelist.xml, we can greatly speed up yum's dependency resolution times. == Proposed Guideline == '''SHOULD''': If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. Using file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin requires yum (and other depsolvers using the repomd format) to download and parse a large xml file looking for the dependency. Helping the depsolvers avoid this processing by depending on the package instead of the file saves our end users a lot of time. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Thu Dec 21 08:06:25 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 21 Dec 2006 09:06:25 +0100 Subject: [Fedora-packaging] printing textual messages in %post etc.? Message-ID: <1166688385.12477.13.camel@mccallum.corsepiu.local> Hi, Do the GuideLines/Does the FPC have an opinion on rpms intentionally printing out textual messages during installs? At least, I could not find a corresponding paragraph in the GuideLines. Background: tripwire's spec (Currently under review) contains this: %post ... # Print getting started help message if [ $1 -eq 1 ]; then echo To configure tripwire, read: %_docdir/%{name}-%{version}/README.Fedora fi I don't have a strong opinion on this and actually am ambivalent. On one hand, such messages can be helpful to users. On the other hand, in general, rpm-installs should be silent as much as possible. Furthermore, I am not sure if printing such messages is safe. How does rpm handle such messages/ to which file descriptor will they be piped (stdout, stderr ...)? Will they desturb installers (yum, apt, shell scripts, pirut, yumex, synaptic, ...) and what happens with such messages during unsupervised installs? Ralf [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203864 From pmatilai at laiskiainen.org Thu Dec 21 10:59:37 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 21 Dec 2006 12:59:37 +0200 (EET) Subject: [Fedora-packaging] Proposal to limit file deps In-Reply-To: <1166676925.21769.97.camel@localhost.localdomain> References: <1166676925.21769.97.camel@localhost.localdomain> Message-ID: On Wed, 20 Dec 2006, Toshio Kuratomi wrote: > '''SHOULD''': If the package has file dependencies outside > of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the > package which provides the file instead of the file itself. > > Using file dependencies outside of /etc, /bin, /sbin, /usr/bin, > or /usr/sbin requires yum (and other depsolvers using the repomd format) > to download and parse a large xml file looking for the dependency. > Helping the depsolvers avoid this processing by depending on the package > instead of the file saves our end users a lot of time. Just FWIW, this doesn't actually help smart and apt at all, unless file dependencies outside what's recorded in primary.xml are outright banned in the repodata specification itself by refusing to add dependencies to other paths than what's in primary.xml. Yum is the only one of the three doing dependency resolution "on demand", both apt and smart precalculate the full dependency tree for all operations so they need all the information at all times. Note that I've absolutely nothing against this proposal, this helps yum (meaning most Fedora users) without hurting the others so nothing wrong with it. File dependencies are a mixed blessing... - Panu - From dominik at greysector.net Thu Dec 21 11:02:32 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 21 Dec 2006 12:02:32 +0100 Subject: [Fedora-packaging] printing textual messages in %post etc.? In-Reply-To: <1166688385.12477.13.camel@mccallum.corsepiu.local> References: <1166688385.12477.13.camel@mccallum.corsepiu.local> Message-ID: <20061221110232.GB16479@ryvius.pekin.waw.pl> On Thursday, 21 December 2006 at 09:06, Ralf Corsepius wrote: > Hi, > > Do the GuideLines/Does the FPC have an opinion on rpms intentionally > printing out textual messages during installs? > > At least, I could not find a corresponding paragraph in the GuideLines. > > > Background: tripwire's spec (Currently under review) contains this: > > %post > ... > # Print getting started help message > if [ $1 -eq 1 ]; then > echo To configure tripwire, read: %_docdir/%{name}-%{version}/README.Fedora > fi > > > I don't have a strong opinion on this and actually am ambivalent. > > On one hand, such messages can be helpful to users. > > On the other hand, in general, rpm-installs should be silent as much as > possible. Personally I'm against any install-time messages from rpm. If there are any, they should indicate a warning or an error. I was going to ask the submitter to remove this. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From fedora at leemhuis.info Thu Dec 21 11:49:47 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 21 Dec 2006 12:49:47 +0100 Subject: [Fedora-packaging] printing textual messages in %post etc.? In-Reply-To: <1166688385.12477.13.camel@mccallum.corsepiu.local> References: <1166688385.12477.13.camel@mccallum.corsepiu.local> Message-ID: <458A74DB.8060802@leemhuis.info> On 21.12.2006 09:06, Ralf Corsepius wrote: > Do the GuideLines/Does the FPC have an opinion on rpms intentionally > printing out textual messages during installs? > At least, I could not find a corresponding paragraph in the GuideLines. Hmm, I think we discussed this some weeks/months ago and I think the consensus was that "RPM files should not output anything during (un)install". But I can't find it in the guidelines just yet -- maybe was forgotten again... (or I'm to blind to find it) > I don't have a strong opinion on this and actually am ambivalent. > On one hand, such messages can be helpful to users. > On the other hand, in general, rpm-installs should be silent as much as > possible. /me strongly votes for silent. Yes, having "something" that sends notes like the one from tripwire to the sysadmin somehow would be helpfull. But %pre{,un},%post{,un} are the wrong place for it IMHO as it often scrolls away quickly unnoticed and is not even shown in pirut and other tools afaik. CU th? From Axel.Thimm at ATrpms.net Thu Dec 21 12:46:05 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 21 Dec 2006 13:46:05 +0100 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: References: <1166676925.21769.97.camel@localhost.localdomain> Message-ID: <20061221124605.GA16827@neu.nirvana> On Thu, Dec 21, 2006 at 12:59:37PM +0200, Panu Matilainen wrote: > On Wed, 20 Dec 2006, Toshio Kuratomi wrote: > >'''SHOULD''': If the package has file dependencies outside > >of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the > >package which provides the file instead of the file itself. > > > >Using file dependencies outside of /etc, /bin, /sbin, /usr/bin, > >or /usr/sbin requires yum (and other depsolvers using the repomd format) > >to download and parse a large xml file looking for the dependency. > >Helping the depsolvers avoid this processing by depending on the package > >instead of the file saves our end users a lot of time. > > Just FWIW, this doesn't actually help smart and apt at all, Why? If unneccessary file dependencies are removed the files sizes get smaller. Of course, yum has the larger benefits, but apt/smart/etc would benefit from say cutting off half of the file dependencies, too. The only problem I see is to identify when some file dependencies were used "unneccessarily". Using file dependencies was never really preferred over proper package depedencies, so most likely the packager really wanted file dependencies when he explcitely used them. That means w/o a proper analysis of what we currently have, we shouldn't simply ban them. Instead an analysis would show why packagers used this method and whether we can offer better workarounds for what they wanted to achieve. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Dec 21 13:10:18 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 21 Dec 2006 14:10:18 +0100 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <1166676925.21769.97.camel@localhost.localdomain> References: <1166676925.21769.97.camel@localhost.localdomain> Message-ID: <20061221131018.GB16827@neu.nirvana> On Wed, Dec 20, 2006 at 08:55:25PM -0800, Toshio Kuratomi wrote: > Hey all, I've just added a draft proposal for limiting file dependencies > in packages. It's a "should" recommendation at this point. > > http://www.fedoraproject.org/wiki/PackagingDrafts/FileDeps > > = File Deps Guideline = > > == Problem == How often does this problem really occur? I just checked core's x86_64 packages and there are exactly 12 files in such dependencies affecting 18 packages out of 2422 (that's 0.7%): cman-kernel dlm-kernel gamin-python gdm GFS-kernel gnbd-kernel httpd ImageMagick-perl inn libvirt-python libxml2-python libxslt-python openldap-servers openmotif openssh-server python-lcms redhat-lsb vsftpd That's 0.7%. I thought that the problem was much larger. I either miscalculated the number of file dependencies or there is no problem :) (At least not one that has to be solved by creating new guidelines, most of these packages like lsb or kernel modules seem to need special handling anyway) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Dec 21 13:19:20 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 21 Dec 2006 14:19:20 +0100 Subject: [Fedora-packaging] Re: printing textual messages in %post etc.? In-Reply-To: <20061221110232.GB16479@ryvius.pekin.waw.pl> References: <1166688385.12477.13.camel@mccallum.corsepiu.local> <20061221110232.GB16479@ryvius.pekin.waw.pl> Message-ID: <20061221131920.GC16827@neu.nirvana> On Thu, Dec 21, 2006 at 12:02:32PM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 21 December 2006 at 09:06, Ralf Corsepius wrote: > > Hi, > > > > Do the GuideLines/Does the FPC have an opinion on rpms intentionally > > printing out textual messages during installs? > > > > At least, I could not find a corresponding paragraph in the GuideLines. > > > > > > Background: tripwire's spec (Currently under review) contains this: > > > > %post > > ... > > # Print getting started help message > > if [ $1 -eq 1 ]; then > > echo To configure tripwire, read: %_docdir/%{name}-%{version}/README.Fedora > > fi > > > > > > I don't have a strong opinion on this and actually am ambivalent. > > > > On one hand, such messages can be helpful to users. The same is true of about every daemon in Fedora, e.g. installing a server would spill your screen with several dozens of hints of you needing to configure web, nfs, ftp etc. services. :) The nose would drown real errors from the rpm transaction. > > On the other hand, in general, rpm-installs should be silent as much as > > possible. > > Personally I'm against any install-time messages from rpm. If there are > any, they should indicate a warning or an error. > I was going to ask the submitter to remove this. I agree with Rathann: rpm output has been assumed to be silent if everything is all right since its very beginning. Perhaps it's even documented in maximum rpm or rpm's source code. Anyway a strong -1 to allowing any non-error/warning output. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Dec 21 13:24:10 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 21 Dec 2006 14:24:10 +0100 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <20061221131018.GB16827@neu.nirvana> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221131018.GB16827@neu.nirvana> Message-ID: <20061221132410.GD16827@neu.nirvana> On Thu, Dec 21, 2006 at 02:10:18PM +0100, Axel Thimm wrote: > On Wed, Dec 20, 2006 at 08:55:25PM -0800, Toshio Kuratomi wrote: > > Hey all, I've just added a draft proposal for limiting file dependencies > > in packages. It's a "should" recommendation at this point. > > > > http://www.fedoraproject.org/wiki/PackagingDrafts/FileDeps > > > > = File Deps Guideline = > > > > == Problem == > > How often does this problem really occur? I just checked core's x86_64 > packages and there are exactly 12 files in such dependencies > affecting 18 packages out of 2422 (that's 0.7%): > > cman-kernel dlm-kernel gamin-python gdm GFS-kernel gnbd-kernel httpd > ImageMagick-perl inn libvirt-python libxml2-python libxslt-python > openldap-servers openmotif openssh-server python-lcms redhat-lsb > vsftpd > > That's 0.7%. I thought that the problem was much larger. I either > miscalculated the number of file dependencies or there is no problem :) And the same metrics for extras: 26 files required by 27 packages out of 3660 packages: chess clamav-devel ctapi-cyberjack cvs2cl em8300-devel freefont ftnchek-emacs gnash-plugin libibverbs-devel mimetex mozilla-opensc-signer openbox openct pcsc-perl perl-Image-Info pyxdg SoQt-devel tuxpaint util-vserver util-vserver-legacy util-vserver-sysv uuid-devel uuid-pgsql uuid-php w3c-markup-validator-libs x11-ssh-askpass xmms That's again 0.7%, so the combined Fedora is at 0.7%, too. Still hoping my calculations aren't flawed ... > (At least not one that has to be solved by creating new guidelines, > most of these packages like lsb or kernel modules seem to need special > handling anyway) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Dec 21 13:26:09 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 21 Dec 2006 14:26:09 +0100 Subject: [Fedora-packaging] Re: printing textual messages in %post etc.? In-Reply-To: <20061221131920.GC16827@neu.nirvana> References: <1166688385.12477.13.camel@mccallum.corsepiu.local> <20061221110232.GB16479@ryvius.pekin.waw.pl> <20061221131920.GC16827@neu.nirvana> Message-ID: <20061221132609.GE16827@neu.nirvana> On Thu, Dec 21, 2006 at 02:19:20PM +0100, Axel Thimm wrote: > The nose would drown real errors from the rpm transaction. Well, the nose may drown, too, but I really meant noise ... ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Dec 21 13:42:16 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 21 Dec 2006 07:42:16 -0600 Subject: [Fedora-packaging] Re: Re: %posttrans scriptlet References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <1166624235.5608.49.camel@max.booze> <45894A49.6040707@math.unl.edu> <45894C77.4090903@math.unl.edu> <45895E37.2060609@math.unl.edu> <20061220174404.GC12415@nostromo.devel.redhat.com> <45897759.7020306@math.unl.edu> <1166654593.4142.37.camel@viper.local> Message-ID: Ville Skytt? wrote: > There's quite a bit of related discussion at > http://thread.gmane.org/gmane.linux.redhat.rpm.devel/547/ Thanks Ville, that confirms my suspicions: %posttrans can't be relied upon as any sole solution to the iconcache issue. -- Rex From fedora at leemhuis.info Thu Dec 21 13:43:31 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 21 Dec 2006 14:43:31 +0100 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <20061221132410.GD16827@neu.nirvana> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221131018.GB16827@neu.nirvana> <20061221132410.GD16827@neu.nirvana> Message-ID: <458A8F83.307@leemhuis.info> On 21.12.2006 14:24, Axel Thimm wrote: > On Thu, Dec 21, 2006 at 02:10:18PM +0100, Axel Thimm wrote: >> On Wed, Dec 20, 2006 at 08:55:25PM -0800, Toshio Kuratomi wrote: >>> Hey all, I've just added a draft proposal for limiting file dependencies >>> in packages. It's a "should" recommendation at this point. >>> >>> http://www.fedoraproject.org/wiki/PackagingDrafts/FileDeps >>> >>> = File Deps Guideline = >>> >>> == Problem == >> How often does this problem really occur? I just checked core's x86_64 >> packages and there are exactly 12 files in such dependencies >> affecting 18 packages out of 2422 (that's 0.7%): >> >> cman-kernel dlm-kernel gamin-python gdm GFS-kernel gnbd-kernel httpd >> ImageMagick-perl inn libvirt-python libxml2-python libxslt-python >> openldap-servers openmotif openssh-server python-lcms redhat-lsb >> vsftpd >> >> That's 0.7%. I thought that the problem was much larger. I either >> miscalculated the number of file dependencies or there is no problem :) > > And the same metrics for extras: 26 files required by 27 packages out > of 3660 packages: > > chess clamav-devel ctapi-cyberjack cvs2cl em8300-devel freefont > ftnchek-emacs gnash-plugin libibverbs-devel mimetex > mozilla-opensc-signer openbox openct pcsc-perl perl-Image-Info pyxdg > SoQt-devel tuxpaint util-vserver util-vserver-legacy util-vserver-sysv > uuid-devel uuid-pgsql uuid-php w3c-markup-validator-libs > x11-ssh-askpass xmms > > That's again 0.7%, so the combined Fedora is at 0.7%, too. Well, my initial calculations found 32 file based deps outside of "/etc {/usr,}/{s,}bin/" in Extras 6 x64 ;-) Just to note, I mentioned that when I started the whole mess after skvidal poked me about it. See https://www.redhat.com/archives/fedora-packaging/2006-December/msg00077.html CU thl From pmatilai at laiskiainen.org Thu Dec 21 14:25:10 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 21 Dec 2006 16:25:10 +0200 (EET) Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <20061221124605.GA16827@neu.nirvana> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221124605.GA16827@neu.nirvana> Message-ID: On Thu, 21 Dec 2006, Axel Thimm wrote: > On Thu, Dec 21, 2006 at 12:59:37PM +0200, Panu Matilainen wrote: >> On Wed, 20 Dec 2006, Toshio Kuratomi wrote: >>> '''SHOULD''': If the package has file dependencies outside >>> of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the >>> package which provides the file instead of the file itself. >>> >>> Using file dependencies outside of /etc, /bin, /sbin, /usr/bin, >>> or /usr/sbin requires yum (and other depsolvers using the repomd format) >>> to download and parse a large xml file looking for the dependency. >>> Helping the depsolvers avoid this processing by depending on the package >>> instead of the file saves our end users a lot of time. >> >> Just FWIW, this doesn't actually help smart and apt at all, > > Why? If unneccessary file dependencies are removed the files sizes get > smaller. Of course, yum has the larger benefits, but apt/smart/etc > would benefit from say cutting off half of the file dependencies, too. Looking up a file dependency is just as cheap as looking up a package dependency in apt and smart (AFAIK, haven't studien smart in too much detail), once the initial crunching through the available files is done. Throwing out *unnecessary* dependencies (file or package) is obviously good, even if it's hardly noticeable in the filesizes in reality. This simply doesn't change the fact that apt and smart need to download the filelists.xml along with primary.xml at all times to guarantee working with any old repomd repository. - Panu - From fnasser at redhat.com Thu Dec 21 14:33:51 2006 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 21 Dec 2006 09:33:51 -0500 Subject: [Fedora-packaging] printing textual messages in %post etc.? In-Reply-To: <458A74DB.8060802@leemhuis.info> References: <1166688385.12477.13.camel@mccallum.corsepiu.local> <458A74DB.8060802@leemhuis.info> Message-ID: <458A9B4F.4000402@redhat.com> Thorsten Leemhuis wrote: > On 21.12.2006 09:06, Ralf Corsepius wrote: >> Do the GuideLines/Does the FPC have an opinion on rpms intentionally >> printing out textual messages during installs? >> At least, I could not find a corresponding paragraph in the GuideLines. > > Hmm, I think we discussed this some weeks/months ago and I think the > consensus was that "RPM files should not output anything during > (un)install". But I can't find it in the guidelines just yet -- maybe > was forgotten again... (or I'm to blind to find it) > >> I don't have a strong opinion on this and actually am ambivalent. >> On one hand, such messages can be helpful to users. >> On the other hand, in general, rpm-installs should be silent as much as >> possible. > > /me strongly votes for silent. Yes, having "something" that sends notes > like the one from tripwire to the sysadmin somehow would be helpfull. > But %pre{,un},%post{,un} are the wrong place for it IMHO as it often > scrolls away quickly unnoticed and is not even shown in pirut and other > tools afaik. > They also mess up automatic installation/upgrading systems output unnecessarily. +1 for only warnings and/or errors. Not however that people will try and fix this by redirecting the whole output to /dev/null , so not even errors or warnings will show up ;-) Perhaps a footnote that that is not the preferred way of fixing it. Regards, Fernando From overholt at redhat.com Thu Dec 21 15:10:20 2006 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 21 Dec 2006 10:10:20 -0500 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <20061221124605.GA16827@neu.nirvana> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221124605.GA16827@neu.nirvana> Message-ID: <1166713820.13489.7.camel@localhost.localdomain> On Thu, 2006-21-12 at 13:46 +0100, Axel Thimm wrote: > Instead an analysis would show why > packagers used this method and whether we can offer better workarounds > for what they wanted to achieve. In the Eclipse SDK package set, we recently went through the multilib-ification process. We had to add a few file-level dependencies to get this to work. This was due to the inability to specify %{arch} in a Requires. How would this have been better accomplished? Ben can probably explain this better than I can. Andrew -------------- 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 tcallawa at redhat.com Thu Dec 21 15:19:41 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 21 Dec 2006 09:19:41 -0600 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <1166713820.13489.7.camel@localhost.localdomain> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221124605.GA16827@neu.nirvana> <1166713820.13489.7.camel@localhost.localdomain> Message-ID: <1166714381.4139.67.camel@localhost.localdomain> On Thu, 2006-12-21 at 10:10 -0500, Andrew Overholt wrote: > On Thu, 2006-21-12 at 13:46 +0100, Axel Thimm wrote: > > Instead an analysis would show why > > packagers used this method and whether we can offer better workarounds > > for what they wanted to achieve. > > In the Eclipse SDK package set, we recently went through the > multilib-ification process. We had to add a few file-level dependencies > to get this to work. This was due to the inability to specify %{arch} > in a Requires. How would this have been better accomplished? > > Ben can probably explain this better than I can. Honestly, this is the only valid case for file-level dependencies I can think of, and unfortunately, the only way to work around it is to fix rpm to permit %{arch} specific Requires. ~spot From Axel.Thimm at ATrpms.net Thu Dec 21 15:58:08 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 21 Dec 2006 16:58:08 +0100 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: References: <1166676925.21769.97.camel@localhost.localdomain> <20061221124605.GA16827@neu.nirvana> Message-ID: <20061221155808.GF16827@neu.nirvana> On Thu, Dec 21, 2006 at 04:25:10PM +0200, Panu Matilainen wrote: > This simply doesn't change the fact that apt and smart need to > download the filelists.xml along with primary.xml at all times to > guarantee working with any old repomd repository. What is an "old" and "new" repomd? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Dec 21 16:13:34 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 21 Dec 2006 10:13:34 -0600 Subject: [Fedora-packaging] iconcache, v0.5 Message-ID: <458AB2AE.8060609@math.unl.edu> FYI, updated iconcache proposal v0.5: * nixed xdg-utils. * Updated motivations/justifications, * gtk2 implementation suggestions/links, http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache Looks like Core folks won't settle for anything in between status-quo and 100% fix (no in-between-compromising like using xdg-utils), so let's give it a shot. This time round, I'll try to put all relavent suggestions, comments, dialog on the wiki. Hopefully, that will help keep those not following the intimate details of the ml threads informed. -- Rex From rdieter at math.unl.edu Thu Dec 21 16:16:22 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 21 Dec 2006 10:16:22 -0600 Subject: [Fedora-packaging] iconcache, v0.5 In-Reply-To: <458AB2AE.8060609@math.unl.edu> References: <458AB2AE.8060609@math.unl.edu> Message-ID: <458AB356.4030505@math.unl.edu> Rex Dieter wrote: > http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache ... > This time round, I'll try to put all relavent suggestions, comments, > dialog on the wiki. Hopefully, that will help keep those not following > the intimate details of the ml threads informed. Heck, it is a *wiki* afterall, everyone with input is encouraged to add content there. -- Rex From rc040203 at freenet.de Thu Dec 21 16:17:53 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 21 Dec 2006 17:17:53 +0100 Subject: [Fedora-packaging] iconcache, v0.5 In-Reply-To: <458AB2AE.8060609@math.unl.edu> References: <458AB2AE.8060609@math.unl.edu> Message-ID: <1166717873.5079.14.camel@mccallum.corsepiu.local> On Thu, 2006-12-21 at 10:13 -0600, Rex Dieter wrote: > FYI, updated iconcache proposal v0.5: > * nixed xdg-utils. > * Updated motivations/justifications, > * gtk2 implementation suggestions/links, > > http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache > > Looks like Core folks won't settle for anything in between status-quo > and 100% fix (no in-between-compromising like using xdg-utils), so let's > give it a shot. Due to this and due to the fact the current practice is impractical and defective, I am in favor of scratching all coverage of handling icon caches in the GuideLines until somebody can provide a functional, portable and GUI-independent solution. Ralf From rdieter at math.unl.edu Thu Dec 21 16:35:58 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 21 Dec 2006 10:35:58 -0600 Subject: [Fedora-packaging] iconcache, v0.5 In-Reply-To: <1166717873.5079.14.camel@mccallum.corsepiu.local> References: <458AB2AE.8060609@math.unl.edu> <1166717873.5079.14.camel@mccallum.corsepiu.local> Message-ID: <458AB7EE.1010403@math.unl.edu> Ralf Corsepius wrote: > On Thu, 2006-12-21 at 10:13 -0600, Rex Dieter wrote: >> FYI, updated iconcache proposal v0.5: >> * nixed xdg-utils. >> * Updated motivations/justifications, >> * gtk2 implementation suggestions/links, >> >> http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache >> >> Looks like Core folks won't settle for anything in between status-quo >> and 100% fix (no in-between-compromising like using xdg-utils), so let's >> give it a shot. > Due to this and due to the fact the current practice is impractical and > defective, I am in favor of scratching all coverage of handling icon > caches in the GuideLines until somebody can provide a functional, > portable and GUI-independent solution. As it turns out, the current proposal satisfies your criteria... it is just worded a little nicer. (: -- Rex From fnasser at redhat.com Thu Dec 21 16:39:38 2006 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 21 Dec 2006 11:39:38 -0500 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: References: <1166676925.21769.97.camel@localhost.localdomain> <20061221124605.GA16827@neu.nirvana> Message-ID: <458AB8CA.2020406@redhat.com> I have two questions: 1) If this is a problem that only affects yum and all the other depsolvers do it efficiently, would it be better to fix yum instead or working around it by spec file changes? 2) If we still use file deps for things in /bin /sbin /usr/bin /usr/sbin, which happens for all GCJ compiled packages, wouldn't it force the reading of the second file anyways? regards, Fernando Panu Matilainen wrote: > On Thu, 21 Dec 2006, Axel Thimm wrote: > >> On Thu, Dec 21, 2006 at 12:59:37PM +0200, Panu Matilainen wrote: >>> On Wed, 20 Dec 2006, Toshio Kuratomi wrote: >>>> '''SHOULD''': If the package has file dependencies outside >>>> of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the >>>> package which provides the file instead of the file itself. >>>> >>>> Using file dependencies outside of /etc, /bin, /sbin, /usr/bin, >>>> or /usr/sbin requires yum (and other depsolvers using the repomd >>>> format) >>>> to download and parse a large xml file looking for the dependency. >>>> Helping the depsolvers avoid this processing by depending on the >>>> package >>>> instead of the file saves our end users a lot of time. >>> >>> Just FWIW, this doesn't actually help smart and apt at all, >> >> Why? If unneccessary file dependencies are removed the files sizes get >> smaller. Of course, yum has the larger benefits, but apt/smart/etc >> would benefit from say cutting off half of the file dependencies, too. > > Looking up a file dependency is just as cheap as looking up a package > dependency in apt and smart (AFAIK, haven't studien smart in too much > detail), once the initial crunching through the available files is done. > > Throwing out *unnecessary* dependencies (file or package) is obviously > good, even if it's hardly noticeable in the filesizes in reality. This > simply doesn't change the fact that apt and smart need to download the > filelists.xml along with primary.xml at all times to guarantee working > with any old repomd repository. > > - Panu - > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > From rdieter at math.unl.edu Thu Dec 21 16:42:09 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 21 Dec 2006 10:42:09 -0600 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <458AB8CA.2020406@redhat.com> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221124605.GA16827@neu.nirvana> <458AB8CA.2020406@redhat.com> Message-ID: <458AB961.7020709@math.unl.edu> Fernando Nasser wrote: > I have two questions: > > 1) If this is a problem that only affects yum and all the other > depsolvers do it efficiently, would it be better to fix yum instead or > working around it by spec file changes? It's still generally a good idea to minimize file deps. > 2) If we still use file deps for things in /bin /sbin /usr/bin > /usr/sbin, which happens for all GCJ compiled packages, wouldn't it > force the reading of the second file anyways? No, just for items *outside* of those locations does yum need extra processing. That's the whole point of this exercise. -- Rex From Axel.Thimm at ATrpms.net Thu Dec 21 17:00:26 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 21 Dec 2006 18:00:26 +0100 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <458AB8CA.2020406@redhat.com> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221124605.GA16827@neu.nirvana> <458AB8CA.2020406@redhat.com> Message-ID: <20061221170026.GA29595@neu.nirvana> On Thu, Dec 21, 2006 at 11:39:38AM -0500, Fernando Nasser wrote: > 1) If this is a problem that only affects yum and all the other > depsolvers do it efficiently, would it be better to fix yum instead or > working around it by spec file changes? No, it's the other way round: yum is more efficient in downloading because it most often does not need to download everything, while the other depsolvers always download the bist in advance. It's a bit oversimplified, but that servers for a first picture. The discussion is about whether some packages force yum to go download and drop its bandwidth performance to that of the other depsolvers, but that's just 0.7% of all packages, so not really worth attacking at all IMHO. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Dec 21 17:04:06 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 21 Dec 2006 18:04:06 +0100 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <458A8F83.307@leemhuis.info> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221131018.GB16827@neu.nirvana> <20061221132410.GD16827@neu.nirvana> <458A8F83.307@leemhuis.info> Message-ID: <20061221170406.GB29595@neu.nirvana> On Thu, Dec 21, 2006 at 02:43:31PM +0100, Thorsten Leemhuis wrote: > On 21.12.2006 14:24, Axel Thimm wrote: > >On Thu, Dec 21, 2006 at 02:10:18PM +0100, Axel Thimm wrote: > >>On Wed, Dec 20, 2006 at 08:55:25PM -0800, Toshio Kuratomi wrote: > >>>Hey all, I've just added a draft proposal for limiting file dependencies > >>>in packages. It's a "should" recommendation at this point. > >>> > >>>http://www.fedoraproject.org/wiki/PackagingDrafts/FileDeps > >>> > >>>= File Deps Guideline = > >>> > >>>== Problem == > >>How often does this problem really occur? I just checked core's x86_64 > >>packages and there are exactly 12 files in such dependencies > >>affecting 18 packages out of 2422 (that's 0.7%): > >And the same metrics for extras: 26 files required by 27 packages out > >of 3660 packages: > >That's again 0.7%, so the combined Fedora is at 0.7%, too. > > Well, my initial calculations found 32 file based deps outside of "/etc > {/usr,}/{s,}bin/" in Extras 6 x64 ;-) Just to note, I mentioned that > when I started the whole mess after skvidal poked me about it. See > https://www.redhat.com/archives/fedora-packaging/2006-December/msg00077.html But then it was known that this is negligible, why does it escalate to become even a proposal for guidelines? Do we care that yum fetches the filelists every 140 package updates? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fnasser at redhat.com Thu Dec 21 17:13:43 2006 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 21 Dec 2006 12:13:43 -0500 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <458AB961.7020709@math.unl.edu> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221124605.GA16827@neu.nirvana> <458AB8CA.2020406@redhat.com> <458AB961.7020709@math.unl.edu> Message-ID: <458AC0C7.7010307@redhat.com> Rex Dieter wrote: > Fernando Nasser wrote: >> I have two questions: >> >> 1) If this is a problem that only affects yum and all the other >> depsolvers do it efficiently, would it be better to fix yum instead or >> working around it by spec file changes? > > It's still generally a good idea to minimize file deps. > Sure, but there are cases where it is desirable. I am afraid a dull guideline will put a straight jacket on developers. For instance, I know a couple of folks working on a software that in the current release needs two independent packages. Another developer needs one (a single one) file from them, but the file may change places. They thought of adding a virtual provides, but it seems overkill in this case and it is probably only temporary (which would mean we would use a name unnecessarily and regret later). So the best way around it was to require the file, at least until the set of packages stabilize on a future version of the dependency. Perhaps a "recommendation" guideline? (if there is such a thing) >> 2) If we still use file deps for things in /bin /sbin /usr/bin >> /usr/sbin, which happens for all GCJ compiled packages, wouldn't it >> force the reading of the second file anyways? > > No, just for items *outside* of those locations does yum need extra > processing. That's the whole point of this exercise. > Ah, thanks for the clarification. The use of file deps prevents an optimization to kick in. Is this list complete: /bin /sbin /usr/bin /usr/sbin ? Or there are others that do not cause the loading of the second file? Regards, Fernando From fnasser at redhat.com Thu Dec 21 17:14:47 2006 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 21 Dec 2006 12:14:47 -0500 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <20061221170026.GA29595@neu.nirvana> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221124605.GA16827@neu.nirvana> <458AB8CA.2020406@redhat.com> <20061221170026.GA29595@neu.nirvana> Message-ID: <458AC107.9040504@redhat.com> Axel Thimm wrote: > On Thu, Dec 21, 2006 at 11:39:38AM -0500, Fernando Nasser wrote: >> 1) If this is a problem that only affects yum and all the other >> depsolvers do it efficiently, would it be better to fix yum instead or >> working around it by spec file changes? > > No, it's the other way round: yum is more efficient in downloading > because it most often does not need to download everything, while the > other depsolvers always download the bist in advance. It's a bit > oversimplified, but that servers for a first picture. > Thanks for the clarification. The use of file deps prevents an optimization to kick in. From a.badger at gmail.com Thu Dec 21 17:35:04 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 21 Dec 2006 09:35:04 -0800 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <458AC0C7.7010307@redhat.com> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221124605.GA16827@neu.nirvana> <458AB8CA.2020406@redhat.com> <458AB961.7020709@math.unl.edu> <458AC0C7.7010307@redhat.com> Message-ID: <1166722504.21769.147.camel@localhost.localdomain> On Thu, 2006-12-21 at 12:13 -0500, Fernando Nasser wrote: > Rex Dieter wrote: > > Fernando Nasser wrote: > >> I have two questions: > >> > >> 1) If this is a problem that only affects yum and all the other > >> depsolvers do it efficiently, would it be better to fix yum instead or > >> working around it by spec file changes? > > > > It's still generally a good idea to minimize file deps. > > > Actually, what's happening is that all depsolvers have the ability to optimize two time consuming steps if the file deps follow these guidelines. The two steps are 1) downloading filelist.xml.gz and 2) parsing filelist.xml to find the package which provides the file deps. [And this problem is multiplied the more repositories you have defined as the depsolver will have to grab the filelist.xml file from multiple repositories]. Panu points out that only yum currently optimizes this but there's nothing stopping the others doing it as well. > Sure, but there are cases where it is desirable. I am afraid a dull > guideline will put a straight jacket on developers. > > For instance, I know a couple of folks working on a software that in the > current release needs two independent packages. Another developer needs > one (a single one) file from them, but the file may change places. They > thought of adding a virtual provides, but it seems overkill in this case > and it is probably only temporary (which would mean we would use a name > unnecessarily and regret later). So the best way around it was to > require the file, at least until the set of packages stabilize on a > future version of the dependency. > > Perhaps a "recommendation" guideline? (if there is such a thing) > Yes. This proposal is for a "Should" rather than a "Must" guideline. In the case you outline, I'd like to see the package depend on the file until it was settled which package would provide it. Then the dependency could be converted to a package dep instead. We don't currently have an ongoing QA requirement, though, so remembering to make the change would largely be the responsibility of the packager. > >> 2) If we still use file deps for things in /bin /sbin /usr/bin > >> /usr/sbin, which happens for all GCJ compiled packages, wouldn't it > >> force the reading of the second file anyways? > > > > No, just for items *outside* of those locations does yum need extra > > processing. That's the whole point of this exercise. > > > > Ah, thanks for the clarification. The use of file deps prevents an > optimization to kick in. > Correct. > Is this list complete: /bin /sbin /usr/bin /usr/sbin ? > Or there are others that do not cause the loading of the second file? /etc is the other one. That's why the guideline applies to file deps outside of /etc /bin /sbin /usr/bin and /usr/sbin. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Thu Dec 21 18:00:06 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 21 Dec 2006 19:00:06 +0100 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <20061221170406.GB29595@neu.nirvana> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221131018.GB16827@neu.nirvana> <20061221132410.GD16827@neu.nirvana> <458A8F83.307@leemhuis.info> <20061221170406.GB29595@neu.nirvana> Message-ID: <458ACBA6.7070205@leemhuis.info> Axel Thimm schrieb: > On Thu, Dec 21, 2006 at 02:43:31PM +0100, Thorsten Leemhuis wrote: >> On 21.12.2006 14:24, Axel Thimm wrote: >>> On Thu, Dec 21, 2006 at 02:10:18PM +0100, Axel Thimm wrote: >>>> On Wed, Dec 20, 2006 at 08:55:25PM -0800, Toshio Kuratomi wrote: >>>>> Hey all, I've just added a draft proposal for limiting file dependencies >>>>> in packages. It's a "should" recommendation at this point. >>>>> http://www.fedoraproject.org/wiki/PackagingDrafts/FileDeps >>>>> = File Deps Guideline = >>>>> == Problem == >>>> How often does this problem really occur? I just checked core's x86_64 >>>> packages and there are exactly 12 files in such dependencies >>>> affecting 18 packages out of 2422 (that's 0.7%): >>> And the same metrics for extras: 26 files required by 27 packages out >>> of 3660 packages: >>> That's again 0.7%, so the combined Fedora is at 0.7%, too. >> Well, my initial calculations found 32 file based deps outside of "/etc >> {/usr,}/{s,}bin/" in Extras 6 x64 ;-) Just to note, I mentioned that >> when I started the whole mess after skvidal poked me about it. See >> https://www.redhat.com/archives/fedora-packaging/2006-December/msg00077.html > But then it was known that this is negligible, "negligible" IMHO is debatable, but yes, it's not a big problem (currently). And just to clarify: I just started to look into it because skvidal poked me about it. I had no interest in it myself and after the initial research I did te thing rolled on its own. > why does it escalate > to become even a proposal for guidelines? To avoid that there get more of those added in the future? > Do we care that yum fetches > the filelists every 140 package updates? If it can be avoided easiy: yes. There is also the OLPC hardware that seems to be quite slow and will probably take ages to resolve such a dep. We should keep that in mind, too. CU thl From fnasser at redhat.com Thu Dec 21 18:00:40 2006 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 21 Dec 2006 13:00:40 -0500 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <1166722504.21769.147.camel@localhost.localdomain> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221124605.GA16827@neu.nirvana> <458AB8CA.2020406@redhat.com> <458AB961.7020709@math.unl.edu> <458AC0C7.7010307@redhat.com> <1166722504.21769.147.camel@localhost.localdomain> Message-ID: <458ACBC8.5060506@redhat.com> Toshio Kuratomi wrote: > On Thu, 2006-12-21 at 12:13 -0500, Fernando Nasser wrote: >> Rex Dieter wrote: >>> Fernando Nasser wrote: >>>> I have two questions: >>>> >>>> 1) If this is a problem that only affects yum and all the other >>>> depsolvers do it efficiently, would it be better to fix yum instead or >>>> working around it by spec file changes? >>> It's still generally a good idea to minimize file deps. >>> > Actually, what's happening is that all depsolvers have the ability to > optimize two time consuming steps if the file deps follow these > guidelines. The two steps are 1) downloading filelist.xml.gz and 2) > parsing filelist.xml to find the package which provides the file deps. > [And this problem is multiplied the more repositories you have defined > as the depsolver will have to grab the filelist.xml file from multiple > repositories]. > > Panu points out that only yum currently optimizes this but there's > nothing stopping the others doing it as well. > OK >> Sure, but there are cases where it is desirable. I am afraid a dull >> guideline will put a straight jacket on developers. >> >> For instance, I know a couple of folks working on a software that in the >> current release needs two independent packages. Another developer needs >> one (a single one) file from them, but the file may change places. They >> thought of adding a virtual provides, but it seems overkill in this case >> and it is probably only temporary (which would mean we would use a name >> unnecessarily and regret later). So the best way around it was to >> require the file, at least until the set of packages stabilize on a >> future version of the dependency. >> >> Perhaps a "recommendation" guideline? (if there is such a thing) >> > Yes. This proposal is for a "Should" rather than a "Must" guideline. > In the case you outline, I'd like to see the package depend on the file > until it was settled which package would provide it. Then the > dependency could be converted to a package dep instead. We don't > currently have an ongoing QA requirement, though, so remembering to make > the change would largely be the responsibility of the packager. > That will work for them. I think it is a sensible approach. Perhaps adding a FIXME to the specfile above that dependency would be a good idea. >>>> 2) If we still use file deps for things in /bin /sbin /usr/bin >>>> /usr/sbin, which happens for all GCJ compiled packages, wouldn't it >>>> force the reading of the second file anyways? >>> No, just for items *outside* of those locations does yum need extra >>> processing. That's the whole point of this exercise. >>> >> Ah, thanks for the clarification. The use of file deps prevents an >> optimization to kick in. >> > Correct. > >> Is this list complete: /bin /sbin /usr/bin /usr/sbin ? >> Or there are others that do not cause the loading of the second file? > > /etc is the other one. > Thanks. I guess the list of exceptions will be in the guidelines. > That's why the guideline applies to file deps outside > of /etc /bin /sbin /usr/bin and /usr/sbin. > > -Toshio > > Thanks for the clarifications Fernando From nicolas.mailhot at laposte.net Thu Dec 21 18:32:28 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 21 Dec 2006 19:32:28 +0100 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <458ACBA6.7070205@leemhuis.info> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221131018.GB16827@neu.nirvana> <20061221132410.GD16827@neu.nirvana> <458A8F83.307@leemhuis.info> <20061221170406.GB29595@neu.nirvana> <458ACBA6.7070205@leemhuis.info> Message-ID: <1166725948.16180.28.camel@rousalka.dyndns.org> Le jeudi 21 d?cembre 2006 ? 19:00 +0100, Thorsten Leemhuis a ?crit : > Axel Thimm schrieb: > > why does it escalate > > to become even a proposal for guidelines? > > To avoid that there get more of those added in the future? As the numbers show no one is particularly inclined to add a large number of such deps today. They won't become more common unless they start providing some benefit to users or packagers. (for example proper rpm directory handling at last). I don't see how we can decide today a yum-specific optimisation will take precedence over this yet-to-be-known benefit. -- 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 pmatilai at laiskiainen.org Thu Dec 21 18:55:48 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 21 Dec 2006 20:55:48 +0200 (EET) Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <1166722504.21769.147.camel@localhost.localdomain> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221124605.GA16827@neu.nirvana> <458AB8CA.2020406@redhat.com> <458AB961.7020709@math.unl.edu> <458AC0C7.7010307@redhat.com> <1166722504.21769.147.camel@localhost.localdomain> Message-ID: On Thu, 21 Dec 2006, Toshio Kuratomi wrote: > On Thu, 2006-12-21 at 12:13 -0500, Fernando Nasser wrote: >> Rex Dieter wrote: >>> Fernando Nasser wrote: >>>> I have two questions: >>>> >>>> 1) If this is a problem that only affects yum and all the other >>>> depsolvers do it efficiently, would it be better to fix yum instead or >>>> working around it by spec file changes? >>> >>> It's still generally a good idea to minimize file deps. >> > Actually, what's happening is that all depsolvers have the ability to > optimize two time consuming steps if the file deps follow these > guidelines. The two steps are 1) downloading filelist.xml.gz and 2) > parsing filelist.xml to find the package which provides the file deps. > [And this problem is multiplied the more repositories you have defined > as the depsolver will have to grab the filelist.xml file from multiple > repositories]. > > Panu points out that only yum currently optimizes this but there's > nothing stopping the others doing it as well. Because of their very design, smart and apt CAN NOT optimize it as long as the repodata format permits arbitrary file dependencies. That's what I've been trying to say here. Assume for a moment that FC + FE are cleaned up from all file dependencies outside of those present in primary.xml. Sure, it'd be possible to make a fedora-specific one-liner patch to avoid downloading the filelists.xml and that would "work." But as long as it's just a Fedora policy and not forced by the tools, things would break as soon as any 3rd party repository not enforcing that particular Fedora policy is used (Axel, this is what I meant with "any old repository", no such thing as "new repodata" at the moment) What does it mean? Heck, nothing really. Apt and smart have a radically different internal design from that of yum, each has their own benefits. The partial filelist info within primary.xml is really what I'd call a RH/Fedora specific performance hack, based on rough "these directories cover 99% of the filedeps in practice" heuristic. Which is all and well, except it's annoyingly close-but-no-cigar to working for apt and smart as well, they need to download the huge filelists.xml only because of that remaining 1% :) Again, cleaning up obscure file dependencies is good, nothing against this thing at all. I just wanted to correct the idea that it would help "the other" depsolvers as well - it doesn't, but that doesn't make the idea bad. - Panu - From Axel.Thimm at ATrpms.net Fri Dec 22 12:20:23 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 22 Dec 2006 13:20:23 +0100 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <458AB2AE.8060609@math.unl.edu> References: <458AB2AE.8060609@math.unl.edu> Message-ID: <20061222122023.GA1613@neu.nirvana> On Thu, Dec 21, 2006 at 10:13:34AM -0600, Rex Dieter wrote: > Looks like Core folks won't settle for anything in between status-quo > and 100% fix (no in-between-compromising like using xdg-utils), so let's > give it a shot. What is the 100% fix? I'm just comapring this to ldconfig, which is a similar issue, right? What would the 100% fix be there? inotify on /lib,/usr/lib? What about scrollkeeper? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Fri Dec 22 12:49:46 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 22 Dec 2006 06:49:46 -0600 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <20061222122023.GA1613@neu.nirvana> References: <458AB2AE.8060609@math.unl.edu> <20061222122023.GA1613@neu.nirvana> Message-ID: <458BD46A.9000308@math.unl.edu> Axel Thimm wrote: > On Thu, Dec 21, 2006 at 10:13:34AM -0600, Rex Dieter wrote: >> Looks like Core folks won't settle for anything in between status-quo >> and 100% fix (no in-between-compromising like using xdg-utils), so let's >> give it a shot. > > What is the 100% fix? 100% fix is loosely defined as satisfying the motivations/criteria outlined in the latest version of the proposal. Note, however, that 100% fix is outside the scope of packaging guidelines. One thing that needs fixing wrt guidelines, however, is to not regenerate icon cache on every single package install, hence, why this newest version of the proposal drops the use of gtk-update-icon-cache in %post/%postun. On this, everyone from Core agrees (including Matthias, gtk maintainer). -- Rex From Axel.Thimm at ATrpms.net Fri Dec 22 13:26:31 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 22 Dec 2006 14:26:31 +0100 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <458BD46A.9000308@math.unl.edu> References: <458AB2AE.8060609@math.unl.edu> <20061222122023.GA1613@neu.nirvana> <458BD46A.9000308@math.unl.edu> Message-ID: <20061222132631.GD1625@neu.nirvana> On Fri, Dec 22, 2006 at 06:49:46AM -0600, Rex Dieter wrote: > Axel Thimm wrote: > >On Thu, Dec 21, 2006 at 10:13:34AM -0600, Rex Dieter wrote: > >>Looks like Core folks won't settle for anything in between status-quo > >>and 100% fix (no in-between-compromising like using xdg-utils), so let's > >>give it a shot. > > > >What is the 100% fix? > > 100% fix is loosely defined as satisfying the motivations/criteria > outlined in the latest version of the proposal. Yes, but how would that work technically? Would an equivalent of gtk-update-icon-cache be run on a directory upon first access to a file within a folder with an aged index.theme? That would the only sensible "100% fix" sound like. > Note, however, that 100% fix is outside the scope of packaging > guidelines. One thing that needs fixing wrt guidelines, however, is to > not regenerate icon cache on every single package install, hence, why > this newest version of the proposal drops the use of > gtk-update-icon-cache in %post/%postun. On this, everyone from Core > agrees (including Matthias, gtk maintainer). And what about the vaccuum that this leaves behind? A non-updated gtk cache mechanism that cannot share mmaped icons? I don't known how bad that actually is, but why not wait with changing the guidelines until any better mechanism is in place? BTW # time gtk-update-icon-cache; time ldconfig real 0m0.003s user 0m0.001s sys 0m0.002s real 0m0.274s user 0m0.130s sys 0m0.143s -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Fri Dec 22 13:37:19 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 22 Dec 2006 07:37:19 -0600 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <20061222132631.GD1625@neu.nirvana> References: <458AB2AE.8060609@math.unl.edu> <20061222122023.GA1613@neu.nirvana> <458BD46A.9000308@math.unl.edu> <20061222132631.GD1625@neu.nirvana> Message-ID: <458BDF8F.3010706@math.unl.edu> Axel Thimm wrote: > On Fri, Dec 22, 2006 at 06:49:46AM -0600, Rex Dieter wrote: >> Axel Thimm wrote: >>> On Thu, Dec 21, 2006 at 10:13:34AM -0600, Rex Dieter wrote: >>>> Looks like Core folks won't settle for anything in between status-quo >>>> and 100% fix (no in-between-compromising like using xdg-utils), so let's >>>> give it a shot. >>> What is the 100% fix? >> 100% fix is loosely defined as satisfying the motivations/criteria >> outlined in the latest version of the proposal. > > Yes, but how would that work technically? Would an equivalent of > gtk-update-icon-cache be run on a directory upon first access to a > file within a folder with an aged index.theme? That would the only > sensible "100% fix" sound like. Yeah, something like that. The idea with the most momentum (among Core folks) involves some sort of filesystem-monitoring deamon of some sort to auto-update cache as needed. My initially-proposed cron job which works (now) and is infinitely simpler, has pretty much been rejected. Frankly, I don't care about the details of solving that: *it is not our(PC) problem* to address or solve. >> Note, however, that 100% fix is outside the scope of packaging >> guidelines. One thing that needs fixing wrt guidelines, however, is to >> not regenerate icon cache on every single package install, hence, why >> this newest version of the proposal drops the use of >> gtk-update-icon-cache in %post/%postun. On this, everyone from Core >> agrees (including Matthias, gtk maintainer). > > And what about the vaccuum that this leaves behind? A non-updated gtk > cache mechanism that cannot share mmaped icons? I don't known how bad > that actually is, but why not wait with changing the guidelines until > any better mechanism is in place? Sigh, problem being, we've now been waiting 14+ months for this theoretical better mechanism. You're willing to wait indefinitely? Not me. Further, I vehemently argue that problem is outside the scope of packaging guidelines. Let's try to keep focus on what we (as packaging committee) *can* solve, please. -- Rex -- Rex From jkeating at redhat.com Fri Dec 22 14:06:54 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Dec 2006 09:06:54 -0500 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <458BDF8F.3010706@math.unl.edu> References: <458AB2AE.8060609@math.unl.edu> <20061222132631.GD1625@neu.nirvana> <458BDF8F.3010706@math.unl.edu> Message-ID: <200612220906.59116.jkeating@redhat.com> On Friday 22 December 2006 08:37, Rex Dieter wrote: > Sigh, problem being, we've now been waiting 14+ months for this > theoretical better mechanism. ?You're willing to wait indefinitely? ?Not > me. ?Further, I vehemently argue that problem is outside the scope of > packaging guidelines. ?Let's try to keep focus on what we (as packaging > committee) *can* solve, please. I'm not keen on creating rules to "force" the issue though. That is not a good "use" of our power. We have constraints to work within, those constraints being what the operating system can handle. Lets not make this a political thing. We're not going to go ban the use of ldconfig in %post until the rpm folks work out a way to do it in stages when needed, so why would we do it for icon cache too? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Fri Dec 22 14:22:13 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 22 Dec 2006 08:22:13 -0600 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <200612220906.59116.jkeating@redhat.com> References: <458AB2AE.8060609@math.unl.edu> <20061222132631.GD1625@neu.nirvana> <458BDF8F.3010706@math.unl.edu> <200612220906.59116.jkeating@redhat.com> Message-ID: <458BEA15.6010301@math.unl.edu> Jesse Keating wrote: > On Friday 22 December 2006 08:37, Rex Dieter wrote: >> Sigh, problem being, we've now been waiting 14+ months for this >> theoretical better mechanism. You're willing to wait indefinitely? Not >> me. Further, I vehemently argue that problem is outside the scope of >> packaging guidelines. Let's try to keep focus on what we (as packaging >> committee) *can* solve, please. > > I'm not keen on creating rules to "force" the issue though. IMO, we're not trying to force anything here. We're trying to fix what is in our domain to fix. Most feedback I've received (even that from Matthias) agrees this is a *good thing*. > Lets not make this a political thing. This is *so* not a political thing. I regret ever even treading on those troubled waters(1). I've resigned myself on trying to solve the *technical* problem only, at least that which is within our domain to do so. > We're not going to go ban the use of ldconfig in %post > until the rpm folks work out a way to do it in stages when needed, so why > would we do it for icon cache too? imo, ldconfig example isn't a good one, but I get your point. Difference being here, messing with ldconfig can horribly break things. A stale iconcache doesn't break anything, at worst only affects app startup time (a little). How about we turn this around a bit, instead of focusing on the bad, how about something good that could come of this: installs/updates will go a heck of a lot faster, ~0.2-0.5 seconds per package! I wonder how faster a default Fedora install would be. (: -- Rex (1) Yes, I got a little pissy when my proposed cron-job solution was rejected out-of-hand, for some better, unimplimented, theoretical one. I'm over it, I've moved on, I feel better now. Really. From jkeating at redhat.com Fri Dec 22 14:26:21 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Dec 2006 09:26:21 -0500 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <458BEA15.6010301@math.unl.edu> References: <458AB2AE.8060609@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> Message-ID: <200612220926.21147.jkeating@redhat.com> On Friday 22 December 2006 09:22, Rex Dieter wrote: > imo, ldconfig example isn't a good one, but I get your point. > Difference being here, messing with ldconfig can horribly break things. > ? A stale iconcache doesn't break anything, at worst only affects app > startup time (a little). Ah! I missed this point. If the above statement is true, I'm all for it. I had thought we were going down the road of making a rule that would leave the cache unupdated period, and Some Other Process As Of Yet Unwritten would have to clean up behind us. If this happens already, and all the end user sees is a slight delay, I'm for it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Fri Dec 22 14:29:28 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 22 Dec 2006 08:29:28 -0600 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <200612220926.21147.jkeating@redhat.com> References: <458AB2AE.8060609@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <200612220926.21147.jkeating@redhat.com> Message-ID: <458BEBC8.9020700@math.unl.edu> Jesse Keating wrote: > On Friday 22 December 2006 09:22, Rex Dieter wrote: >> imo, ldconfig example isn't a good one, but I get your point. >> Difference being here, messing with ldconfig can horribly break things. >> A stale iconcache doesn't break anything, at worst only affects app >> startup time (a little). > > Ah! I missed this point. If the above statement is true, I'm all for it. I > had thought we were going down the road of making a rule that would leave the > cache unupdated period, and Some Other Process As Of Yet Unwritten would have > to clean up behind us. If this happens already, and all the end user sees is > a slight delay, I'm for it. Yay! Christmas came early! -- Rex From Axel.Thimm at ATrpms.net Fri Dec 22 14:32:37 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 22 Dec 2006 15:32:37 +0100 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <458BEA15.6010301@math.unl.edu> <20061222132631.GD1625@neu.nirvana> References: <458AB2AE.8060609@math.unl.edu> <20061222132631.GD1625@neu.nirvana> <458BDF8F.3010706@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <458AB2AE.8060609@math.unl.edu> <20061222122023.GA1613@neu.nirvana> <458BD46A.9000308@math.unl.edu> <20061222132631.GD1625@neu.nirvana> Message-ID: <20061222143237.GE1625@neu.nirvana> On Fri, Dec 22, 2006 at 02:26:31PM +0100, Axel Thimm wrote: > # time gtk-update-icon-cache; time ldconfig > > real 0m0.003s > user 0m0.001s > sys 0m0.002s > > real 0m0.274s > user 0m0.130s > sys 0m0.143s On Fri, Dec 22, 2006 at 08:22:13AM -0600, Rex Dieter wrote: > How about we turn this around a bit, instead of focusing on the bad, how > about something good that could come of this: > installs/updates will go a heck of a lot faster, ~0.2-0.5 seconds per > package! I wonder how faster a default Fedora install would be. (: Not a real winner on my 3 year old lappy. I'd need 300 gtk packages with redundant gtk-update-icon-cache to notice a second ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Dec 22 14:33:02 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Dec 2006 09:33:02 -0500 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <20061222143237.GE1625@neu.nirvana> References: <458AB2AE.8060609@math.unl.edu> <20061222132631.GD1625@neu.nirvana> <20061222143237.GE1625@neu.nirvana> Message-ID: <200612220933.02134.jkeating@redhat.com> On Friday 22 December 2006 09:32, Axel Thimm wrote: > Not a real winner on my 3 year old lappy. I'd need 300 gtk packages > with redundant gtk-update-icon-cache to notice a second We should get seth to run this on the olpc, I bet there is a win there (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Fri Dec 22 14:54:35 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 22 Dec 2006 08:54:35 -0600 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <20061222143237.GE1625@neu.nirvana> References: <458AB2AE.8060609@math.unl.edu> <20061222132631.GD1625@neu.nirvana> <458BDF8F.3010706@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <458AB2AE.8060609@math.unl.edu> <20061222122023.GA1613@neu.nirvana> <458BD46A.9000308@math.unl.edu> <20061222132631.GD1625@neu.nirvana> <20061222143237.GE1625@neu.nirvana> Message-ID: <458BF1AB.60907@math.unl.edu> Axel Thimm wrote: > On Fri, Dec 22, 2006 at 02:26:31PM +0100, Axel Thimm wrote: >> # time gtk-update-icon-cache; time ldconfig gtk-update-icon-cache is pretty much a no-op, if cache is fresh. Try this instead: touch /usr/share/icons/hicolor time gtk-update-icon-cache -- Rex From rdieter at math.unl.edu Fri Dec 22 14:55:00 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 22 Dec 2006 08:55:00 -0600 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <200612220933.02134.jkeating@redhat.com> References: <458AB2AE.8060609@math.unl.edu> <20061222132631.GD1625@neu.nirvana> <20061222143237.GE1625@neu.nirvana> <200612220933.02134.jkeating@redhat.com> Message-ID: <458BF1C4.1040704@math.unl.edu> Jesse Keating wrote: > On Friday 22 December 2006 09:32, Axel Thimm wrote: >> Not a real winner on my 3 year old lappy. I'd need 300 gtk packages >> with redundant gtk-update-icon-cache to notice a second > > We should get seth to run this on the olpc, I bet there is a win there (: I'd bet $$ a big win. -- Rex From rdieter at math.unl.edu Fri Dec 22 14:56:43 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 22 Dec 2006 08:56:43 -0600 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <458BF1AB.60907@math.unl.edu> References: <458AB2AE.8060609@math.unl.edu> <20061222132631.GD1625@neu.nirvana> <458BDF8F.3010706@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <458AB2AE.8060609@math.unl.edu> <20061222122023.GA1613@neu.nirvana> <458BD46A.9000308@math.unl.edu> <20061222132631.GD1625@neu.nirvana> <20061222143237.GE1625@neu.nirvana> <458BF1AB.60907@math.unl.edu> Message-ID: <458BF22B.3010400@math.unl.edu> Rex Dieter wrote: > Axel Thimm wrote: >> On Fri, Dec 22, 2006 at 02:26:31PM +0100, Axel Thimm wrote: >>> # time gtk-update-icon-cache; time ldconfig > > gtk-update-icon-cache is pretty much a no-op, if cache is fresh. > > Try this instead: > touch /usr/share/icons/hicolor > time gtk-update-icon-cache OK, how about a test that actually works: (: touch /usr/share/icons/hicolor time gtk-update-icon-cache /usr/share/icons/hicolor -- Rex From rdieter at math.unl.edu Fri Dec 22 15:09:17 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 22 Dec 2006 09:09:17 -0600 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <458BF22B.3010400@math.unl.edu> References: <458AB2AE.8060609@math.unl.edu> <20061222132631.GD1625@neu.nirvana> <458BDF8F.3010706@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <458AB2AE.8060609@math.unl.edu> <20061222122023.GA1613@neu.nirvana> <458BD46A.9000308@math.unl.edu> <20061222132631.GD1625@neu.nirvana> <20061222143237.GE1625@neu.nirvana> <458BF1AB.60907@math.unl.edu> <458BF22B.3010400@math.unl.edu> Message-ID: <458BF51D.20204@math.unl.edu> Rex Dieter wrote: > Rex Dieter wrote: >> Axel Thimm wrote: >>> On Fri, Dec 22, 2006 at 02:26:31PM +0100, Axel Thimm wrote: >>>> # time gtk-update-icon-cache; time ldconfig >> >> gtk-update-icon-cache is pretty much a no-op, if cache is fresh. > OK, how about a test that actually works: (: > touch /usr/share/icons/hicolor > time gtk-update-icon-cache /usr/share/icons/hicolor Or even better, (for completeness): time gtk-update-icon-cache --force /usr/share/icons/hicolor -- Rex From a.badger at gmail.com Fri Dec 22 17:23:05 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 22 Dec 2006 09:23:05 -0800 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <200612220926.21147.jkeating@redhat.com> References: <458AB2AE.8060609@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <200612220926.21147.jkeating@redhat.com> Message-ID: <1166808185.19928.28.camel@localhost.localdomain> On Fri, 2006-12-22 at 09:26 -0500, Jesse Keating wrote: > On Friday 22 December 2006 09:22, Rex Dieter wrote: > > imo, ldconfig example isn't a good one, but I get your point. > > Difference being here, messing with ldconfig can horribly break things. > > A stale iconcache doesn't break anything, at worst only affects app > > startup time (a little). > > Ah! I missed this point. If the above statement is true, I'm all for it. I > had thought we were going down the road of making a rule that would leave the > cache unupdated period, and Some Other Process As Of Yet Unwritten would have > to clean up behind us. If this happens already, and all the end user sees is > a slight delay, I'm for it. Rex may need to correct me here but I believe with the current gtk package and removing the gtk-update-icon-cache calls in the %post scripts will create a situation where the cache is not updated consistently. Only when a package that has a gtk-update-icon-cache scriptlet is installed/updated will the cache be updated. The difference Rex is speaking of is the level of necessity of ldconfig's cache vs the iconcache. If the iconcache is not up to date gtk is supposed to fall back to not using the cache. If ldconfig's cache is not updated, basic pieces of the system can go boom. That said, if we want to change the guidelines, to not require the iconcache is in place I'd like to see something take care of updating the cache if it's out of date. So the choices I see are: 1) Leave the guidelines the way they are. The drawbacks have been stated several times with different ones being important to different people. 2) Use Rex's cron script. This leaves a stale cache around part of the time but has the benefit of being written now. 3) Write a file watching daemon that can refresh the cache when new files are installed. (This may either be a daemon specific to gtk or, as Havoc suggested in bugzilla, a generic daemon that can be configured to invoke a program when a filesystem event occurs.) Matthias, in the bug report it seemed that you weren't opposed to leaving the scriptlets out of the packages and let the icon cache go stale. Is there a reason not to include the cron script as a temporary measure until a script to monitor for icon changes is written? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Fri Dec 22 17:30:17 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 22 Dec 2006 11:30:17 -0600 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <1166808185.19928.28.camel@localhost.localdomain> References: <458AB2AE.8060609@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <200612220926.21147.jkeating@redhat.com> <1166808185.19928.28.camel@localhost.localdomain> Message-ID: <458C1629.1020804@math.unl.edu> Toshio Kuratomi wrote: > Rex may need to correct me here but I believe with the current gtk > package and removing the gtk-update-icon-cache calls in the %post > scripts will create a situation where the cache is not updated > consistently. Only when a package that has a gtk-update-icon-cache > scriptlet is installed/updated will the cache be updated. Correct. icon cache coherency is (still) the unsolved/unimplemented part of this issue. FYI, I've updated the icon cache wiki so that this has it's own section, since it really is a separate issue, outside the scope of packaging guidelines. -- Rex From Axel.Thimm at ATrpms.net Fri Dec 22 17:47:05 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 22 Dec 2006 18:47:05 +0100 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <1166808185.19928.28.camel@localhost.localdomain> References: <458AB2AE.8060609@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <200612220926.21147.jkeating@redhat.com> <1166808185.19928.28.camel@localhost.localdomain> Message-ID: <20061222174705.GF1625@neu.nirvana> On Fri, Dec 22, 2006 at 09:23:05AM -0800, Toshio Kuratomi wrote: > On Fri, 2006-12-22 at 09:26 -0500, Jesse Keating wrote: > > On Friday 22 December 2006 09:22, Rex Dieter wrote: > > > imo, ldconfig example isn't a good one, but I get your point. > > > Difference being here, messing with ldconfig can horribly break things. > > > A stale iconcache doesn't break anything, at worst only affects app > > > startup time (a little). > > > > Ah! I missed this point. If the above statement is true, I'm all for it. I > > had thought we were going down the road of making a rule that would leave the > > cache unupdated period, and Some Other Process As Of Yet Unwritten would have > > to clean up behind us. If this happens already, and all the end user sees is > > a slight delay, I'm for it. > > Rex may need to correct me here but I believe with the current gtk > package and removing the gtk-update-icon-cache calls in the %post > scripts will create a situation where the cache is not updated > consistently. Only when a package that has a gtk-update-icon-cache > scriptlet is installed/updated will the cache be updated. > > The difference Rex is speaking of is the level of necessity of > ldconfig's cache vs the iconcache. If the iconcache is not up to date > gtk is supposed to fall back to not using the cache. If ldconfig's > cache is not updated, basic pieces of the system can go boom. > > That said, if we want to change the guidelines, to not require the > iconcache is in place I'd like to see something take care of updating > the cache if it's out of date. So the choices I see are: > > 1) Leave the guidelines the way they are. The drawbacks have been > stated several times with different ones being important to different > people. > 2) Use Rex's cron script. This leaves a stale cache around part of the > time but has the benefit of being written now. > 3) Write a file watching daemon that can refresh the cache when new > files are installed. (This may either be a daemon specific to gtk or, > as Havoc suggested in bugzilla, a generic daemon that can be configured > to invoke a program when a filesystem event occurs.) or 4) have gtk do the cache maintenance it on the fly, e.g. when an icon is accessed gtk checks for index.theme's timestamp in the folder the icon is in and does the equivalent to gtk-update-icon-cache in the background? I'd prefer that over 3) because if you have a folder inotify a daemon you'd be running the updating again several times per larger rpm transaction. Unless that daemon would have a wait timeout on inotifies to collect several triggers, but then it sounds easier to do 4) > Matthias, in the bug report it seemed that you weren't opposed to > leaving the scriptlets out of the packages and let the icon cache go > stale. Is there a reason not to include the cron script as a temporary > measure until a script to monitor for icon changes is written? I'd also prefer a simpler packages + cron script until the "100% fix" :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Fri Dec 22 19:33:14 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 22 Dec 2006 13:33:14 -0600 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <20061222174705.GF1625@neu.nirvana> References: <458AB2AE.8060609@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <200612220926.21147.jkeating@redhat.com> <1166808185.19928.28.camel@localhost.localdomain> <20061222174705.GF1625@neu.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> I'd prefer that over 3) because if you have a folder inotify a AT> daemon you'd be running the updating again several times per AT> larger rpm transaction. Unless that daemon would have a wait AT> timeout on inotifies to collect several triggers, but then it AT> sounds easier to do 4) Besides, how do you then update the cache during, say, the initial install, or if I install some packages in single-user mode? Hopefully the installer won't have to start a pile of daemons just to get a proper system. I have to wonder, are the people who advocate keeping a daemon running forever to keep things in sync over a one-line crontab the same ones who oppose xdg-utils because it's a shell script of moderate length? Because if so, there seems to be a significant disconnect there and I'm having trouble figuring out what the rules are. - J< From Axel.Thimm at ATrpms.net Fri Dec 22 19:39:14 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 22 Dec 2006 20:39:14 +0100 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: References: <458AB2AE.8060609@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <200612220926.21147.jkeating@redhat.com> <1166808185.19928.28.camel@localhost.localdomain> <20061222174705.GF1625@neu.nirvana> Message-ID: <20061222193914.GG1625@neu.nirvana> On Fri, Dec 22, 2006 at 01:33:14PM -0600, Jason L Tibbitts III wrote: > >>>>> "AT" == Axel Thimm writes: > > AT> I'd prefer that over 3) because if you have a folder inotify a > AT> daemon you'd be running the updating again several times per > AT> larger rpm transaction. Unless that daemon would have a wait > AT> timeout on inotifies to collect several triggers, but then it > AT> sounds easier to do 4) > > Besides, how do you then update the cache during, say, the initial > install, or if I install some packages in single-user mode? > Hopefully the installer won't have to start a pile of daemons just to > get a proper system. > > I have to wonder, are the people who advocate keeping a daemon running > forever to keep things in sync over a one-line crontab the same ones > who oppose xdg-utils because it's a shell script of moderate length? > Because if so, there seems to be a significant disconnect there and > I'm having trouble figuring out what the rules are. I wasn't thinking of forking daemons for the on-the-fly cache updating, more a side effect of using gtk libs, e.g. a model like python creating pyc on the fly, tex creating fonts etc. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Fri Dec 22 20:46:10 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 22 Dec 2006 14:46:10 -0600 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <20061222193914.GG1625@neu.nirvana> References: <458AB2AE.8060609@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <200612220926.21147.jkeating@redhat.com> <1166808185.19928.28.camel@localhost.localdomain> <20061222174705.GF1625@neu.nirvana> <20061222193914.GG1625@neu.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> I wasn't thinking of forking daemons for the on-the-fly cache AT> updating, more a side effect of using gtk libs, e.g. a model like AT> python creating pyc on the fly, tex creating fonts etc. The python setup requires that the specific scripts run as root; the TeX stuff requires rather tricky things like world-writable directories or setgid bits. Neither is close to ideal. In any case, it seems as if one proposed solution does indeed require a daemon sitting around watching for changes to the icon directories and regenerating the cache on the fly. That's what I was commenting on. - J< From Axel.Thimm at ATrpms.net Fri Dec 22 22:37:03 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 22 Dec 2006 23:37:03 +0100 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: References: <458AB2AE.8060609@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <200612220926.21147.jkeating@redhat.com> <1166808185.19928.28.camel@localhost.localdomain> <20061222174705.GF1625@neu.nirvana> <20061222193914.GG1625@neu.nirvana> Message-ID: <20061222223703.GI1625@neu.nirvana> On Fri, Dec 22, 2006 at 02:46:10PM -0600, Jason L Tibbitts III wrote: > >>>>> "AT" == Axel Thimm writes: > > AT> I wasn't thinking of forking daemons for the on-the-fly cache > AT> updating, more a side effect of using gtk libs, e.g. a model like > AT> python creating pyc on the fly, tex creating fonts etc. > > The python setup requires that the specific scripts run as root; the > TeX stuff requires rather tricky things like world-writable > directories or setgid bits. Neither is close to ideal. Those were just examples, noone suggests copying the implementations ;) There is anyway the question of having generated files under /usr, e.g. a better implementation of a cache will move the generated bit to under /var for stateless/livecd/ro-usr purposes. > In any case, it seems as if one proposed solution does indeed require > a daemon sitting around watching for changes to the icon directories > and regenerating the cache on the fly. That's what I was commenting > on. Well, we've become rather off-topic anyway, we're not gtk developers, and they probably already know what the solution will look like. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Fri Dec 22 22:39:57 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 23 Dec 2006 00:39:57 +0200 Subject: [Fedora-packaging] Re: Proposal to limit file deps In-Reply-To: <1166714381.4139.67.camel@localhost.localdomain> References: <1166676925.21769.97.camel@localhost.localdomain> <20061221124605.GA16827@neu.nirvana> <1166713820.13489.7.camel@localhost.localdomain> <1166714381.4139.67.camel@localhost.localdomain> Message-ID: <1166827197.14554.60.camel@viper.local> On Thu, 2006-12-21 at 09:19 -0600, Tom 'spot' Callaway wrote: > On Thu, 2006-12-21 at 10:10 -0500, Andrew Overholt wrote: > > > > In the Eclipse SDK package set, we recently went through the > > multilib-ification process. We had to add a few file-level dependencies > > to get this to work. This was due to the inability to specify %{arch} > > in a Requires. How would this have been better accomplished? > > > > Ben can probably explain this better than I can. > > Honestly, this is the only valid case for file-level dependencies I can > think of, and unfortunately, the only way to work around it is to fix > rpm to permit %{arch} specific Requires. One thing for which a dir based dependency is the best we have at the moment are plugins for Mozilla compatible browsers (Requires: %{_libdir}/mozilla/plugins). That could be changed if those browser packages had a common Provides indicating that they load plugins from that dir. By the way, would it be possible/feasible to modify yum so that before downloading filelists metadata, it would check the headers of packages already inserted into a transaction to see if they already satisfy the needed file based dependencies (even if those deps are not available in primary metadata)? One example case where this would be useful is what I currently do in w3c-markup-validator-libs: Requires: xhtml1-dtds /usr/share/sgml/xhtml1/xhtml1-20020801/DTD The DTDs are really expected to be found in that exact path. Even though I know it's currently that way in xhtml1-dtds, I'd like to have the path based dependency there for additional safeguard in case the path to the DTDs ever changes (there's a date embedded in the path so it's inherently at least theoretically prone to that). So when yum sees the above two dependencies without having full filelists available, it'd first insert xhtml1-dtds and try it out if it happened to satisfy /usr/share/sgml/xhtml1/xhtml1-20020801/DTD too, without downloading filelists yet. If yes, no need to download filelists. From tibbs at math.uh.edu Fri Dec 22 22:42:23 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 22 Dec 2006 16:42:23 -0600 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <20061222223703.GI1625@neu.nirvana> References: <458AB2AE.8060609@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <200612220926.21147.jkeating@redhat.com> <1166808185.19928.28.camel@localhost.localdomain> <20061222174705.GF1625@neu.nirvana> <20061222193914.GG1625@neu.nirvana> <20061222223703.GI1625@neu.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> Those were just examples, noone suggests copying the AT> implementations ;) There is anyway the question of having AT> generated files under /usr, e.g. a better implementation of a AT> cache will move the generated bit to under /var for AT> stateless/livecd/ro-usr purposes. Wow, does it really store the cache under /usr? I didn't realize that. If people are really looking into the caching issue then they should look at fixing that as well. - J< From caillon at redhat.com Sun Dec 24 01:10:35 2006 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 23 Dec 2006 20:10:35 -0500 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <458BEA15.6010301@math.unl.edu> References: <458AB2AE.8060609@math.unl.edu> <20061222132631.GD1625@neu.nirvana> <458BDF8F.3010706@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> Message-ID: <458DD38B.1020102@redhat.com> Rex Dieter wrote: > imo, ldconfig example isn't a good one, but I get your point. > Difference being here, messing with ldconfig can horribly break > things. A stale iconcache doesn't break anything, at worst only > affects app startup time (a little). Stale icon cache has been known to break apps, though. nm-applet is one of them. From rdieter at math.unl.edu Sun Dec 24 04:08:09 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 23 Dec 2006 22:08:09 -0600 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <458DD38B.1020102@redhat.com> References: <458AB2AE.8060609@math.unl.edu> <20061222132631.GD1625@neu.nirvana> <458BDF8F.3010706@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <458DD38B.1020102@redhat.com> Message-ID: <458DFD29.2060106@math.unl.edu> Christopher Aillon wrote: > Rex Dieter wrote: >> imo, ldconfig example isn't a good one, but I get your point. >> Difference being here, messing with ldconfig can horribly break >> things. A stale iconcache doesn't break anything, at worst only >> affects app startup time (a little). > Stale icon cache has been known to break apps, though. nm-applet is one > of them. That's either not true, or simply a bug somewhere. Matthias' has stated gtk2's implementation will(should!) fallback to using brute-force search when icon cache is not fresh. -- Rex From Fedora at FamilleCollet.com Wed Dec 27 19:49:19 2006 From: Fedora at FamilleCollet.com (Remi Collet) Date: Wed, 27 Dec 2006 20:49:19 +0100 Subject: [Fedora-packaging] Packaging/PHP : some update proposal In-Reply-To: <45899AFA.9040205@FamilleCollet.com> References: <45899AFA.9040205@FamilleCollet.com> Message-ID: <4592CE3F.8090806@FamilleCollet.com> Remi Collet a ?crit : > Here is some updates proposal for the > Guidelines for packaging PHP addon modules No comment ? I'm waiting to push a php-pecl-zip update to FC5 & FC6 and i'd like to use new php-zend-api require. > > > 1 ------ No file in BUILD directory > > PEAR & PECL Packages > > The source archive contains a package.xml outside any directory, so you > should/must use > %setup -q -c > > 2 ----- Initial spec. > > PEAR Packages > > To create your specfile, you could use the default template provided by > rpmdevtools or generate one with the command "pear make-rpm-spec > Sources.tgz" (install php-pear-PEAR-Command-Packaging) > > 3 ---- API version check > > PECL Packages > > > With php-5.1.6-3.3 on FC6 and php-5.2.0-8 on rawhide php-common now > provide php-zend-api. > This exact version must be require by pecl extension. > > The php-common in Fedora Core 7 and above (version 5.2.0-8) provides > several useful macros: > > %{php_core_api} > %{php_zend_api} > %{php_pdo_api} > > > Solution 1 (using the macros, only available on rawhide) > > %if %{?php_zend_api}0 > Requires: php_zend_api = %{php_zend_api} > %endif > > Solution 2 (not using the /etc/rpm/macros.php) > > %global php_zendapi %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP > Extension => //p') | tail -1) > > %if %{fedora} >= 6 > Requires: php_zend_api = %{php_zendapi} > %endif > > We can also post a RFE on php to also provide the macros on FC6 > > --- > Some comments. > > A load time, PHP check that each extension is compatible. > php_dl.c compare ZEND_MODULE_API_NO value at php build time and at > extension build time. > > If this values doesn't match, the extension is not loaded and an error > is displayed : >> PHP Warning: PHP Startup: mailparse: Unable to initialize module >> Module compiled with module API=20060613, debug=0, thread-safety=0 >> PHP compiled with module API=20050922, debug=0, thread-safety=0 >> These options need to match >> > > php-abi (PHP_API_VERSION) is 20041225 for a very long time. > php-zend-abi (ZEND_MODULE_API_NO) is the true API version need to check > extension compatibility > > Ex : php-5.1.4, 5.1.5, 5.1.6 > PHP Api Version: 20041225 > Zend Module Api No: 20050922 > > php-5.2.0 > PHP Api Version: 20041225 > Zend Module Api No: 20060613 > > See Bugzilla #212804 > > Requires: php-api could be keep, but is not very useful > > > Thanks for your comments, > I could edit the wiki if this is approved and if you want me to do it. > > Remi. > P.S. i hope this is clear ? > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > > From caillon at redhat.com Thu Dec 28 15:27:53 2006 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 28 Dec 2006 10:27:53 -0500 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <458DFD29.2060106@math.unl.edu> References: <458AB2AE.8060609@math.unl.edu> <20061222132631.GD1625@neu.nirvana> <458BDF8F.3010706@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <458DD38B.1020102@redhat.com> <458DFD29.2060106@math.unl.edu> Message-ID: <4593E279.7080105@redhat.com> Rex Dieter wrote: > Christopher Aillon wrote: >> Rex Dieter wrote: >>> imo, ldconfig example isn't a good one, but I get your point. >>> Difference being here, messing with ldconfig can horribly break >>> things. A stale iconcache doesn't break anything, at worst only >>> affects app startup time (a little). > >> Stale icon cache has been known to break apps, though. nm-applet is one >> of them. > > That's either not true, or simply a bug somewhere. Matthias' has stated > gtk2's implementation will(should!) fallback to using brute-force search > when icon cache is not fresh. I'm not denying it is a bug somewhere that I'm trying to track down. What I'm saying is that there is the potential for breaking things due to whatever reasons. Saying that a stale cache does not cause things to break is a little misleading until the bugs are fixed. From Axel.Thimm at ATrpms.net Thu Dec 28 17:15:37 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 28 Dec 2006 18:15:37 +0100 Subject: [Fedora-packaging] (Un)packaging partly patented software Message-ID: <20061228171537.GB7705@neu.nirvana> Hi, I think I had read somehwere, or we just discussed it (?), that for tarballs carrying potential patent infringing bits it is not enough to build/package the other parts, but that also the src.rpm needs to be kept clean. E.g. the upstream tarball needs to be unpacked, the patent encumbered bits removed/patched out and the result repackaged into a new tarball (for example into foo-1.2-patentfree.tar.gz) Am I remembering correctly? Do we have something like a procedure in the wiki on creating these modified tarballs and commenting the specfile approriately (I couldn't find anything when searching for "patents", but there were perhaps too many hits ...). If not shouldn't we come up with one? The procedure needs to be documented and be reproducable for reviewers to be able to confirm that the tarball "matches" upstream indeed, since they won't have any nice md5sum method to compare. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Thu Dec 28 17:29:44 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 28 Dec 2006 18:29:44 +0100 Subject: [Fedora-packaging] (Un)packaging partly patented software In-Reply-To: <20061228171537.GB7705@neu.nirvana> References: <20061228171537.GB7705@neu.nirvana> Message-ID: <20061228172944.GD3714@free.fr> On Thu, Dec 28, 2006 at 06:15:37PM +0100, Axel Thimm wrote: > Hi, > > I think I had read somehwere, or we just discussed it (?), that for > tarballs carrying potential patent infringing bits it is not enough to > build/package the other parts, but that also the src.rpm needs to be > kept clean. Indeed, and it is similar for packages with non-free parts, or parts with conflicting licenses. > Am I remembering correctly? Do we have something like a procedure in > the wiki on creating these modified tarballs and commenting the > specfile approriately (I couldn't find anything when searching for > "patents", but there were perhaps too many hits ...). > > If not shouldn't we come up with one? The procedure needs to be > documented and be reproducable for reviewers to be able to confirm > that the tarball "matches" upstream indeed, since they won't have any > nice md5sum method to compare. What I do is that I provide a script in SourceXX, which can be used to unpack, remove the offending files and repack. Then a reviewer may do a diff to verify that the remaining files are the same. If the patented code is mixed with non-patented code, it becomes harder, maybe you can then make a diff and post it somewhere where patents are not problematic and point to that diff in the bugzilla ticket. I don't know if it is legal to put the url of the diff in a comment in the spec file. Even in the bugzilla ticket I don't know. You can have a look at the cernlib and grads packages for examples. Maybe this could be more formally stated. -- Pat From Fedora at FamilleCollet.com Fri Dec 29 18:11:21 2006 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 29 Dec 2006 19:11:21 +0100 Subject: [Fedora-packaging] Packaging/PHP : add channels packaging proposal. Message-ID: <45955A49.5070308@FamilleCollet.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is another update proposal for the PHP Guidelines. Context : some packages are provided on other channels than the default one (pear.php.net) The channel definition must be installed (in the pear registry) to allow the build, so this require an RPM of channel definition available in the repository : - - to build the package in mock. - - to install the package Note : i don't keep Requires php, as php-pear already require php and php-cli. Regards. - --------------------------------------------------------- ==Naming scheme== * CHANNEL definition packages should be named php-channel-channelname-%{version}-%{release}.noarch.rpm ==Requires and Provides== CHANNEL definition Packages * Requires: php-pear(PEAR) * Provides: php-channel(channelname) PEAR Packages * Requires: php-pear(PEAR) * Requires: php-channel(channelname) if needed * Provides: php-pear(foo) or php-pear(channelname/foo) ==Macros and scriptlets== CHANNEL definition %post if [ $1 -eq 1 ] ; then %{__pear} channel-add %{pear_xmldir}/%{channel_name}.xml > /dev/null || : else %{__pear} channel-update %{pear_xmldir}/%{channel_name}.xml > /dev/null ||: fi %postun if [ $1 -eq 0 ] ; then %{__pear} channel-delete %{channel_name} > /dev/null || : fi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFlVpJYUppBSnxahgRArDEAJ4jSt5d9UNxgnCldXdApC9fyg8L2wCg3H/z yojj8Exk1QfwtjqBtkJ4GKg= =Qb6D -----END PGP SIGNATURE----- From bugs.michael at gmx.net Sun Dec 31 15:55:23 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 31 Dec 2006 16:55:23 +0100 Subject: [Fedora-packaging] Re: iconcache, v0.5 In-Reply-To: <4593E279.7080105@redhat.com> References: <458AB2AE.8060609@math.unl.edu> <20061222132631.GD1625@neu.nirvana> <458BDF8F.3010706@math.unl.edu> <200612220906.59116.jkeating@redhat.com> <458BEA15.6010301@math.unl.edu> <458DD38B.1020102@redhat.com> <458DFD29.2060106@math.unl.edu> <4593E279.7080105@redhat.com> Message-ID: <20061231165523.75d39294.bugs.michael@gmx.net> On Thu, 28 Dec 2006 10:27:53 -0500, Christopher Aillon wrote: > Rex Dieter wrote: > > Christopher Aillon wrote: > >> Rex Dieter wrote: > >>> imo, ldconfig example isn't a good one, but I get your point. > >>> Difference being here, messing with ldconfig can horribly break > >>> things. A stale iconcache doesn't break anything, at worst only > >>> affects app startup time (a little). > > > >> Stale icon cache has been known to break apps, though. nm-applet is one > >> of them. > > > > That's either not true, or simply a bug somewhere. Matthias' has stated > > gtk2's implementation will(should!) fallback to using brute-force search > > when icon cache is not fresh. > > I'm not denying it is a bug somewhere that I'm trying to track down. > What I'm saying is that there is the potential for breaking things due > to whatever reasons. Saying that a stale cache does not cause things to > break is a little misleading until the bugs are fixed. It is a bug somewhere and the reason why gtk-update-icon-cache is executed in post-install scriptlets. It's the only way freshly installed icons show up in the GNOME desktop menu.