From rdieter at math.unl.edu Mon Jan 1 03:41:04 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 31 Dec 2006 21:41:04 -0600 Subject: [Fedora-packaging] Re: Re: iconcache, v0.5 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> <20061231165523.75d39294.bugs.michael@gmx.net> Message-ID: Michael Schwendt wrote: > 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. Running gtk-update-icon-cache is *not* the *only* way to see new icons. touch'ing the top-level icon dir is (should be!) sufficient for that. -- Rex From bugs.michael at gmx.net Mon Jan 1 12:34:14 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 1 Jan 2007 13:34:14 +0100 Subject: [Fedora-packaging] Re: Re: iconcache, v0.5 In-Reply-To: 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> <20061231165523.75d39294.bugs.michael@gmx.net> Message-ID: <20070101133414.0ac83ea1.bugs.michael@gmx.net> On Sun, 31 Dec 2006 21:41:04 -0600, Rex Dieter wrote: > > 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. > > Running gtk-update-icon-cache is *not* the *only* way to see new icons. > touch'ing the top-level icon dir is (should be!) sufficient for that. Yes, but it's a _manual operation_, because the last-modified time-stamp of that directory is not updated when a sub-directory is changed. And gtk-update-icon-cache doesn't do anything unless the top-level directory has changed (or is touched!). Hence running this stuff manually cannot be avoided so far. Also, the GNOME menu seems somewhat slow in noticing the fresh time-stamp. Probably due to some 2nd level of caching. From rdieter at math.unl.edu Mon Jan 1 14:14:35 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 01 Jan 2007 08:14:35 -0600 Subject: [Fedora-packaging] Re: Re: iconcache, v0.5 In-Reply-To: <20070101133414.0ac83ea1.bugs.michael@gmx.net> 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> <20061231165523.75d39294.bugs.michael@gmx.net> <20070101133414.0ac83ea1.bugs.michael@gmx.net> Message-ID: <4599174B.6070900@math.unl.edu> Michael Schwendt wrote: > On Sun, 31 Dec 2006 21:41:04 -0600, Rex Dieter wrote: > > >>> 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. >>> >> Running gtk-update-icon-cache is *not* the *only* way to see new icons. >> touch'ing the top-level icon dir is (should be!) sufficient for that. >> > > Yes, but it's a _manual operation_, because the last-modified time-stamp > of that directory is not updated when a sub-directory is changed. And > gtk-update-icon-cache doesn't do anything unless the top-level directory > has changed (or is touched!). Hence running this stuff manually cannot be > avoided so far. No one has ever suggested that 'touch' could be avoided. I don't think it can, the icon spec requires it. My point was that only 'touch' is required for proper function. Contrary to what it appeared (to me anyway) you were asserting, gtk-update-icon-cache is not required for proper function, being nothing more than an optimization (akin to prelink). -- Rex From bugs.michael at gmx.net Mon Jan 1 14:34:17 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 1 Jan 2007 15:34:17 +0100 Subject: [Fedora-packaging] Re: Re: iconcache, v0.5 In-Reply-To: <4599174B.6070900@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> <4593E279.7080105@redhat.com> <20061231165523.75d39294.bugs.michael@gmx.net> <20070101133414.0ac83ea1.bugs.michael@gmx.net> <4599174B.6070900@math.unl.edu> Message-ID: <20070101153417.e2dad4cf.bugs.michael@gmx.net> On Mon, 01 Jan 2007 08:14:35 -0600, Rex Dieter wrote: > Michael Schwendt wrote: > > On Sun, 31 Dec 2006 21:41:04 -0600, Rex Dieter wrote: > > > > > >>> 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. > >>> > >> Running gtk-update-icon-cache is *not* the *only* way to see new icons. > >> touch'ing the top-level icon dir is (should be!) sufficient for that. > >> > > > > Yes, but it's a _manual operation_, because the last-modified time-stamp > > of that directory is not updated when a sub-directory is changed. And > > gtk-update-icon-cache doesn't do anything unless the top-level directory > > has changed (or is touched!). Hence running this stuff manually cannot be > > avoided so far. > No one has ever suggested that 'touch' could be avoided. I don't think > it can, the icon spec requires it. > My point was that only 'touch' is required for proper function. > Contrary to what it appeared (to me anyway) you were asserting, > gtk-update-icon-cache is not required for proper function, being nothing > more than an optimization (akin to prelink). I've put it inaccurately, yes, and refer to the scriptlet in the Wiki. Let me rephrase: Only the non-trivial combination of touch plus gtk-update-icon-cache (or only gtk-update-icon-cache --force) updates the cache. And if a post-install scriptlet must be added anyway to touch a directory, running a second program in the same shell script is an obvious thing to do. From Axel.Thimm at ATrpms.net Fri Jan 5 03:15:17 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 5 Jan 2007 04:15:17 +0100 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> Message-ID: <20070105031517.GC8480@neu.nirvana> On Wed, Jul 19, 2006 at 08:54:22AM -0500, Rex Dieter wrote: > Axel Thimm wrote: > > Two independent reviewer considered this a blocker for a review's > > acceptance (even though it's marked "preferred"). > > The reviewers need to be whacked with a clue-stick. A working (non-broken) > buildroot is *not* a blocker. Care to lend me your clue-stick with instructions? I need to apply this to #220888? :) -- 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 Jan 5 18:20:55 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Jan 2007 12:20:55 -0600 Subject: [Fedora-packaging] Acceptability of "content" in merged Fedora Message-ID: The guidelines include the following statement in the "Code Vs. Content" section: "Note, content is only acceptable within Fedora Extras, not Core." I'm not sure why content isn't permissible in Core, but we need to figure out if the restriction will apply to the new Fedora and change the guidelines appropriately. So, why was content not permissible in Core? - J< From tcallawa at redhat.com Fri Jan 5 18:32:08 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 05 Jan 2007 12:32:08 -0600 Subject: [Fedora-packaging] Acceptability of "content" in merged Fedora In-Reply-To: References: Message-ID: <1168021928.3161.122.camel@dhcp-32-109.ord.redhat.com> On Fri, 2007-01-05 at 12:20 -0600, Jason L Tibbitts III wrote: > The guidelines include the following statement in the "Code > Vs. Content" section: > > "Note, content is only acceptable within Fedora Extras, not Core." > > I'm not sure why content isn't permissible in Core, but we need to > figure out if the restriction will apply to the new Fedora and change > the guidelines appropriately. > > So, why was content not permissible in Core? IIRC, f13 added that because of some sort of RHAT request. Dunno the details. ~spot From Axel.Thimm at ATrpms.net Sat Jan 6 12:13:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 6 Jan 2007 13:13:18 +0100 Subject: [Fedora-packaging] Guidelines and epochs Message-ID: <20070106121318.GD6654@neu.nirvana> Seems like it isn't really clear that we want packagers to evoid epochs like the devil. There are some situations that require epochs, when there is no other way to undo versioning and, of course, when there were epochs to start with. Currently epochs are only mentioned under the Requires section: > Second, the Epoch must be listed when adding a versioned dependency > to achieve robust epoch-version-release comparison. A quick way to > check the Epoch of package foo is to run: I'd like to clarify that so that it refers only to non-zero epochs to avoid people adding "0:" upfront of every mentioned version(-release), e.g. change "the Epoch" against "a non-zero Epoch" Then I'd like to have somewhere a recommendation that epochs should be avoided as much as possible. This seems to belong to Packaging/NamingGuidelines, where epochs seem to have been left off (probably deliberately to not lead people into temptation). How about > Package Epoch > > epochs are generally to be avoided. They provide a last-resort > mechanism to override package version and release, but are more > trouble than they are worth while. If you realy have to use an epoch > you MUST use a simple integer (technically anything that is suited > for the version/release tags is also suited here). Make sure you > explore all other possiblities before deciding to use epochs. -- 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 Mon Jan 8 14:41:56 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Mon, 08 Jan 2007 09:41:56 -0500 Subject: [Fedora-packaging] Guidelines and epochs In-Reply-To: <20070106121318.GD6654@neu.nirvana> References: <20070106121318.GD6654@neu.nirvana> Message-ID: <45A25834.7090008@redhat.com> Hi, I'd also change the format to "the smallest possible integer". Epoch's are already a pain as small integers like "1" or "2". Imagine as "anything that is suited for the version/release tags is also suited here". Also, I have mixed feeling about this. As there are some packages that for historic reasons had to have their Epoch bumped, it is very easy to forget to add the "1:" in front of the dependency versions. The other thing is that RPMs deal with "EVR" where "E" stands for "Epoch", so I wonder if the right thing wouldn't be to make that clear by having the Epoch, Version and Release tags all there, always (even if zero). Anyway, before it would be a problem to make this change as RPM had a bug that would not correctly equate "Epoch: 0" with a version dependency lacking the leading ":0", but I believe this has been fixed several RPM releases ago (right Paul?), so it shouldn't be a problem now. But please allow a release or two to enforce this so we can propagate this rule upstream to the packages we import (leaving it as a recommendation only for FC7 for instance). Regards, Fernando Axel Thimm wrote: > Seems like it isn't really clear that we want packagers to evoid > epochs like the devil. There are some situations that require epochs, > when there is no other way to undo versioning and, of course, when > there were epochs to start with. > > Currently epochs are only mentioned under the Requires section: > >> Second, the Epoch must be listed when adding a versioned dependency >> to achieve robust epoch-version-release comparison. A quick way to >> check the Epoch of package foo is to run: > > I'd like to clarify that so that it refers only to non-zero epochs to > avoid people adding "0:" upfront of every mentioned version(-release), > e.g. change "the Epoch" against "a non-zero Epoch" > > Then I'd like to have somewhere a recommendation that epochs should be > avoided as much as possible. This seems to belong to > Packaging/NamingGuidelines, where epochs seem to have been left off > (probably deliberately to not lead people into temptation). How about > >> Package Epoch >> >> epochs are generally to be avoided. They provide a last-resort >> mechanism to override package version and release, but are more >> trouble than they are worth while. If you realy have to use an epoch >> you MUST use a simple integer (technically anything that is suited >> for the version/release tags is also suited here). Make sure you >> explore all other possiblities before deciding to use epochs. > > > ------------------------------------------------------------------------ > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From bugs.michael at gmx.net Mon Jan 8 15:15:33 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 8 Jan 2007 16:15:33 +0100 Subject: [Fedora-packaging] Guidelines and epochs In-Reply-To: <45A25834.7090008@redhat.com> References: <20070106121318.GD6654@neu.nirvana> <45A25834.7090008@redhat.com> Message-ID: <20070108161533.ad9b5d98.bugs.michael@gmx.net> On Mon, 08 Jan 2007 09:41:56 -0500, Fernando Nasser wrote: > Hi, > > I'd also change the format to "the smallest possible integer". Epoch's > are already a pain as small integers like "1" or "2". Imagine as > "anything that is suited for the version/release tags is also suited here". > > Also, I have mixed feeling about this. As there are some packages that > for historic reasons had to have their Epoch bumped, it is very easy to > forget to add the "1:" in front of the dependency versions. The other > thing is that RPMs deal with "EVR" where "E" stands for "Epoch", so I > wonder if the right thing wouldn't be to make that clear by having the > Epoch, Version and Release tags all there, always (even if zero). The packaging guidelines request already that wherever a versioned dependency is used, the Epoch must be added. Better would be to keep Epoch out of explicit versioned dependencies completely and rely on Epoch-less "Provides". Example: Instead of doing "BuildRequires: gtk+-devel >= 1:1.2.10" (notice the Epoch) one would do "BuildRequires: gtk+(api) >= 1.2.10" and gtk+-devel would "Provides: gtk+(abi) = %{version}" regardless of its"Epoch: 1" in the package. The Epoch would continue to aid package resolvers. From fnasser at redhat.com Mon Jan 8 15:33:51 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Mon, 08 Jan 2007 10:33:51 -0500 Subject: [Fedora-packaging] Guidelines and epochs In-Reply-To: <20070108161533.ad9b5d98.bugs.michael@gmx.net> References: <20070106121318.GD6654@neu.nirvana> <45A25834.7090008@redhat.com> <20070108161533.ad9b5d98.bugs.michael@gmx.net> Message-ID: <45A2645F.6050300@redhat.com> Michael Schwendt wrote: > > Better would be to keep Epoch out of explicit versioned dependencies > completely and rely on Epoch-less "Provides". Example: Instead of doing > "BuildRequires: gtk+-devel >= 1:1.2.10" (notice the Epoch) one would do > "BuildRequires: gtk+(api) >= 1.2.10" and gtk+-devel would "Provides: > gtk+(abi) = %{version}" regardless of its"Epoch: 1" in the package. > The Epoch would continue to aid package resolvers. > This is an interesting concept: use a virtual provides to avoid referring to the Epoch of the package, and yet the Epock will displace old generation ones. I wonder if this is possible or convenient in all cases. We may end up with some ugly virtual provide names in some cases. But I like the idea in general -- people tend to forget the "1:" prefix. Regards, Fernando From Axel.Thimm at ATrpms.net Mon Jan 8 15:49:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 8 Jan 2007 16:49:27 +0100 Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <45A2645F.6050300@redhat.com> References: <20070106121318.GD6654@neu.nirvana> <45A25834.7090008@redhat.com> <20070108161533.ad9b5d98.bugs.michael@gmx.net> <45A2645F.6050300@redhat.com> Message-ID: <20070108154927.GA18545@neu.nirvana> On Mon, Jan 08, 2007 at 10:33:51AM -0500, Fernando Nasser wrote: > Michael Schwendt wrote: > > > >Better would be to keep Epoch out of explicit versioned dependencies > >completely and rely on Epoch-less "Provides". Example: Instead of doing > >"BuildRequires: gtk+-devel >= 1:1.2.10" (notice the Epoch) one would do > >"BuildRequires: gtk+(api) >= 1.2.10" and gtk+-devel would "Provides: > >gtk+(abi) = %{version}" regardless of its"Epoch: 1" in the package. > >The Epoch would continue to aid package resolvers. > > > > This is an interesting concept: use a virtual provides to avoid > referring to the Epoch of the package, and yet the Epock will displace > old generation ones. > > I wonder if this is possible or convenient in all cases. We may end up > with some ugly virtual provide names in some cases. But I like the idea > in general -- people tend to forget the "1:" prefix. Please remember what the true use of an epoch is, e.g. to override the version for whatever reason. If something goes like 1.09, 1.10, then you need the epoch because rpm sorts differently. And you would need it for any virtual provides, too. The reason Michael is proposing to use virtual dependencies is because at the beginning you think that you can evade epochs. They look like a secondary version. But unless there is strict control to not mess up you'll end up in the same scenarios requiring epochs like for conventional versioning. E.g. don't get fooled by that trick, it is more papering over than dealing with epochs. And once you start introducing "second-tier" epochs the confusion will be perfect. -- 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 Mon Jan 8 16:03:54 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Mon, 08 Jan 2007 11:03:54 -0500 Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <20070108154927.GA18545@neu.nirvana> References: <20070106121318.GD6654@neu.nirvana> <45A25834.7090008@redhat.com> <20070108161533.ad9b5d98.bugs.michael@gmx.net> <45A2645F.6050300@redhat.com> <20070108154927.GA18545@neu.nirvana> Message-ID: <45A26B6A.50802@redhat.com> Axel Thimm wrote: > > Please remember what the true use of an epoch is, e.g. to override the > version for whatever reason. If something goes like 1.09, 1.10, then > you need the epoch because rpm sorts differently. And you would need > it for any virtual provides, too. > Axel, 1.10 wins over 1.09. Why do you need an Epoch in this case? > The reason Michael is proposing to use virtual dependencies is because > at the beginning you think that you can evade epochs. They look like a > secondary version. But unless there is strict control to not mess up > you'll end up in the same scenarios requiring epochs like for > conventional versioning. > Epochs should be just: 1, 2, 3, 4... although I never saw it greather than 1. > E.g. don't get fooled by that trick, it is more papering over than > dealing with epochs. And once you start introducing "second-tier" > epochs the confusion will be perfect. > No need for second-tier epochs if people don't add anything than single integer digits in there, anmd only use Epochs as a last resource case. The 1-9 range should last for the decade at least. Regards, Fernando From Axel.Thimm at ATrpms.net Mon Jan 8 16:03:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 8 Jan 2007 17:03:19 +0100 Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <45A25834.7090008@redhat.com> References: <20070106121318.GD6654@neu.nirvana> <45A25834.7090008@redhat.com> Message-ID: <20070108160319.GB18545@neu.nirvana> On Mon, Jan 08, 2007 at 09:41:56AM -0500, Fernando Nasser wrote: > I'd also change the format to "the smallest possible integer". Epoch's > are already a pain as small integers like "1" or "2". Imagine as > "anything that is suited for the version/release tags is also suited here". Indeed, that's what I meant. "anything that is suited for the version/release tags is also suited here" was prefixed with "technically" meaning that this is what rpm accepts in this field. > Also, I have mixed feeling about this. As there are some packages that > for historic reasons had to have their Epoch bumped, it is very easy to > forget to add the "1:" in front of the dependency versions. Or whatever the epoch is, that's the issue, you always have to look up. But we shouldn't add "0:" prefixes for the sake of keeping the epoch mechanism in the packagers' back of the head. On the contrary epochs should be considered bad mechanisms and not displayed in that way into conscience. > The other thing is that RPMs deal with "EVR" where "E" stands for > "Epoch", so I wonder if the right thing wouldn't be to make that > clear by having the Epoch, Version and Release tags all there, > always (even if zero). Not for zero epochs - I'd even recommend strongly against adding the Release tag, which is most often not done anyway. There are some rare cases where you do need the Release tag, though (one example is when a package was FHSized and one needs to make sure one picks the right package of the same versions out), but generally that's not needed. > Anyway, before it would be a problem to make this change as RPM had a > bug that would not correctly equate "Epoch: 0" with a version dependency > lacking the leading ":0", but I believe this has been fixed several RPM > releases ago (right Paul?), This was never a problem with Fedora Core's rpm, the last release relying on promoteepoch was RHL9. FC1 and RHEL3 and above a promote-free. > so it shouldn't be a problem now. But please allow a release or two > to enforce this so we can propagate this rule upstream to the > packages we import (leaving it as a recommendation only for FC7 for > instance). But this doesn't break anything. It is just a safeguard for not having new packagers over-epochize their packages and for not considering epochs as the all-round-no-side-effects saviour for bad versioning choices, and mostly follows current practice anyhow. Consider it an educational measure, nothing more. Also note that other than mandating a simple integer (in case an epoch is really needed) the suggested changes are a mere recommendation: no existing package in either repo will become invalid due to that. Still for someone going thorugh the guidelines for the first time it is helpful to see what is considered bad practice. So all in all it is a very conservative change in the guidelines. > Regards, > Fernando > > Axel Thimm wrote: > >Seems like it isn't really clear that we want packagers to evoid > >epochs like the devil. There are some situations that require epochs, > >when there is no other way to undo versioning and, of course, when > >there were epochs to start with. > > > >Currently epochs are only mentioned under the Requires section: > > > >>Second, the Epoch must be listed when adding a versioned dependency > >>to achieve robust epoch-version-release comparison. A quick way to > >>check the Epoch of package foo is to run: > > > >I'd like to clarify that so that it refers only to non-zero epochs to > >avoid people adding "0:" upfront of every mentioned version(-release), > >e.g. change "the Epoch" against "a non-zero Epoch" > > > >Then I'd like to have somewhere a recommendation that epochs should be > >avoided as much as possible. This seems to belong to > >Packaging/NamingGuidelines, where epochs seem to have been left off > >(probably deliberately to not lead people into temptation). How about > > > >>Package Epoch > >> > >>epochs are generally to be avoided. They provide a last-resort > >>mechanism to override package version and release, but are more > >>trouble than they are worth while. If you realy have to use an epoch > >>you MUST use a simple integer (technically anything that is suited > >>for the version/release tags is also suited here). Make sure you > >>explore all other possiblities before deciding to use epochs. -- 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 Mon Jan 8 16:06:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 8 Jan 2007 11:06:00 -0500 Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <45A26B6A.50802@redhat.com> References: <20070106121318.GD6654@neu.nirvana> <20070108154927.GA18545@neu.nirvana> <45A26B6A.50802@redhat.com> Message-ID: <200701081106.00395.jkeating@redhat.com> On Monday 08 January 2007 11:03, Fernando Nasser wrote: > No need for second-tier epochs if people don't add anything than single > integer digits in there, anmd only use Epochs as a last resource case. > The 1-9 range should last for the decade at least. Well, discounting that Bind has an epoch somewhere in the 40s... What Axel is saying is this. Right now we use Version/Release We put something in the repo that is version 1.2, release 1. Then we say Lets try this new 2.0 release! Version 2.0, release 1 Oh damn, that was a really bad idea, this is totally broken, we need to roll back, but preserve upgrade path: Epoch 1, version 1.2, release 2 Now epoch is with this package forever. What you're saying is to use the Virtual provides right? Same scenario. Virtual provides of 1.2 is ABI/API/Whatever 1.2. This has no epoch, and even if the package itself had epoch, we aren't asking for it, we're asking for the newest package that provides foo(api) => 1.2. Now lets try that 2.0 again, which changes the api, and now we provide foo(api) = 2.0. Whoops, we need to rollback, now you have to add an epoch to the foo(api) of the 1.2 package, or you lose. -- 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 Axel.Thimm at ATrpms.net Mon Jan 8 16:09:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 8 Jan 2007 17:09:29 +0100 Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <45A26B6A.50802@redhat.com> References: <20070106121318.GD6654@neu.nirvana> <45A25834.7090008@redhat.com> <20070108161533.ad9b5d98.bugs.michael@gmx.net> <45A2645F.6050300@redhat.com> <20070108154927.GA18545@neu.nirvana> <45A26B6A.50802@redhat.com> Message-ID: <20070108160929.GC18545@neu.nirvana> On Mon, Jan 08, 2007 at 11:03:54AM -0500, Fernando Nasser wrote: > Axel Thimm wrote: > > > >Please remember what the true use of an epoch is, e.g. to override the > >version for whatever reason. If something goes like 1.09, 1.10, then > >you need the epoch because rpm sorts differently. And you would need > >it for any virtual provides, too. > > > > Axel, 1.10 wins over 1.09. Why do you need an Epoch in this case? Sorry, I meant 1.1 vs 1.09. > Epochs should be just: 1, 2, 3, 4... although I never saw it greather > than 1. mozilla was at over 35, bind is at 30+, aspell-de/en is at 50, arpwatch, dhclient, tcpdump 10+, and een kdebase/kdelibs at 6. > >E.g. don't get fooled by that trick, it is more papering over than > >dealing with epochs. And once you start introducing "second-tier" > >epochs the confusion will be perfect. > > No need for second-tier epochs if people don't add anything than single > integer digits in there, anmd only use Epochs as a last resource case. > The 1-9 range should last for the decade at least. With second-tier I was referring to the virtual provides. E.g. you have Provides: foo-abi = 1.09 and then you will need Provides: foo-abi = 1:1.1 That's what I means with second-tier epochs. -- 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 nicolas.mailhot at laposte.net Mon Jan 8 16:18:15 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 8 Jan 2007 17:18:15 +0100 (CET) Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <45A26B6A.50802@redhat.com> References: <20070106121318.GD6654@neu.nirvana> <45A25834.7090008@redhat.com> <20070108161533.ad9b5d98.bugs.michael@gmx.net> <45A2645F.6050300@redhat.com> <20070108154927.GA18545@neu.nirvana> <45A26B6A.50802@redhat.com> Message-ID: <53505.192.54.193.51.1168273095.squirrel@rousalka.dyndns.org> Le Lun 8 janvier 2007 17:03, Fernando Nasser a ?crit : > Epochs should be just: 1, 2, 3, 4... although I never saw it greather > than 1. IIRC the mozilla package ended its life at epoch ~ 37 -- Nicolas Mailhot From Axel.Thimm at ATrpms.net Mon Jan 8 16:18:52 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 8 Jan 2007 17:18:52 +0100 Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <20070108160929.GC18545@neu.nirvana> References: <20070106121318.GD6654@neu.nirvana> <45A25834.7090008@redhat.com> <20070108161533.ad9b5d98.bugs.michael@gmx.net> <45A2645F.6050300@redhat.com> <20070108154927.GA18545@neu.nirvana> <45A26B6A.50802@redhat.com> <20070108160929.GC18545@neu.nirvana> Message-ID: <20070108161852.GD18545@neu.nirvana> On Mon, Jan 08, 2007 at 05:09:29PM +0100, Axel Thimm wrote: > On Mon, Jan 08, 2007 at 11:03:54AM -0500, Fernando Nasser wrote: > > Epochs should be just: 1, 2, 3, 4... although I never saw it greather > > than 1. > > mozilla was at over 35, bind is at 30+, aspell-de/en is at 50, arpwatch, > dhclient, tcpdump 10+, and een kdebase/kdelibs at 6. > > The 1-9 range should last for the decade at least. Just to display the stats on this a bit better, for FC6/x86_64 repoquery returns the following stats for core and extras: core (number of packages vs epoch value) 2499 0 267 1 44 2 5 3 8 4 7 5 26 6 9 7 4 8 6 9 12 12 6 14 10 30 27 50 1 51 extras (number of packages vs epoch value) 3865 0 75 1 7 2 3 6 1 7 So, indeed extras really has been well disciplined! That is not to say anything against the core packagers, some epochized packages there have an ancient legacy, and some go back to times where the epoch problem wasn't as well perceived as today. Although epochs over 15/20 make one shudder. ;) -- 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 Mon Jan 8 16:22:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 8 Jan 2007 11:22:26 -0500 Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <20070108160319.GB18545@neu.nirvana> References: <20070106121318.GD6654@neu.nirvana> <45A25834.7090008@redhat.com> <20070108160319.GB18545@neu.nirvana> Message-ID: <200701081122.26828.jkeating@redhat.com> On Monday 08 January 2007 11:03, Axel Thimm wrote: > Also note that other than mandating a simple integer (in case an epoch > is really needed) the suggested changes are a mere recommendation: no > existing package in either repo will become invalid due to that. Still > for someone going thorugh the guidelines for the first time it is > helpful to see what is considered bad practice. > > So all in all it is a very conservative change in the guidelines. And please do remember all, the Guidelines were originally supposed to be a collection of Best Practices, and it is of the opinion of many that avoiding epoch is a Best Practice. -- 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 bugs.michael at gmx.net Mon Jan 8 16:37:42 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 8 Jan 2007 17:37:42 +0100 Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <200701081106.00395.jkeating@redhat.com> References: <20070106121318.GD6654@neu.nirvana> <20070108154927.GA18545@neu.nirvana> <45A26B6A.50802@redhat.com> <200701081106.00395.jkeating@redhat.com> Message-ID: <20070108173742.afbbaf73.bugs.michael@gmx.net> On Mon, 8 Jan 2007 11:06:00 -0500, Jesse Keating wrote: > What you're saying is to use the Virtual provides right? Same scenario. > > Virtual provides of 1.2 is ABI/API/Whatever 1.2. This has no epoch, and even > if the package itself had epoch, we aren't asking for it, we're asking for > the newest package that provides foo(api) => 1.2. Now lets try that 2.0 > again, which changes the api, and now we provide foo(api) = 2.0. Whoops, we > need to rollback, now you have to add an epoch to the foo(api) of the 1.2 > package, or you lose. No. You add the Epoch to the package, not the API. foo-1.2-1.i386.rpm provides foo(api) = 1.2 foo-2.0-1.i386.rpm provides foo(api) = 2.0 Rollback: foo-1:1.2-1.i386.rpm provides foo(api) = 1.2 ^^ The Epoch at the level of RPM version comparison achieves that the rollback works flawlessly. Perl modules work this way today, since their module version (in automatic "Provides") is independent from the package EVR. From nicolas.mailhot at laposte.net Mon Jan 8 16:37:10 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 8 Jan 2007 17:37:10 +0100 (CET) Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <20070108160929.GC18545@neu.nirvana> References: <20070106121318.GD6654@neu.nirvana> <45A25834.7090008@redhat.com> <20070108161533.ad9b5d98.bugs.michael@gmx.net> <45A2645F.6050300@redhat.com> <20070108154927.GA18545@neu.nirvana> <45A26B6A.50802@redhat.com> <20070108160929.GC18545@neu.nirvana> Message-ID: <51755.192.54.193.51.1168274230.squirrel@rousalka.dyndns.org> Le Lun 8 janvier 2007 17:09, Axel Thimm a ?crit : > On Mon, Jan 08, 2007 at 11:03:54AM -0500, Fernando Nasser wrote: >> Axel, 1.10 wins over 1.09. Why do you need an Epoch in this case? > > Sorry, I meant 1.1 vs 1.09. Then the best practice would be to write 1.1 1.10 (I hope this is documented somewhere). Tought of course it would be better if upstream used a fixed digit number, but some developpers have been known to take this suggestion as a pretext to rant on Red Hat in general, and rpm in particular. -- Nicolas Mailhot From jkeating at redhat.com Mon Jan 8 16:37:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 8 Jan 2007 11:37:22 -0500 Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <20070108173742.afbbaf73.bugs.michael@gmx.net> References: <20070106121318.GD6654@neu.nirvana> <200701081106.00395.jkeating@redhat.com> <20070108173742.afbbaf73.bugs.michael@gmx.net> Message-ID: <200701081137.22573.jkeating@redhat.com> On Monday 08 January 2007 11:37, Michael Schwendt wrote: > No. You add the Epoch to the package, not the API. > > ? foo-1.2-1.i386.rpm ?provides ?foo(api) = 1.2 > ? foo-2.0-1.i386.rpm ?provides ?foo(api) = 2.0 > > Rollback: > > ? foo-1:1.2-1.i386.rpm ?provides ?foo(api) = 1.2 > ? ? ? ^^ > > The Epoch at the level of RPM version comparison achieves that the > rollback works flawlessly. > > Perl modules work this way today, since their module version (in automatic > "Provides") is independent from the package EVR. Ah. So then all that would be left is rebuilding anything that required foo(api) 2.0, that is anything that was built against the bunk package, which is a problem we would have either way. -- 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 Axel.Thimm at ATrpms.net Mon Jan 8 16:51:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 8 Jan 2007 17:51:14 +0100 Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <51755.192.54.193.51.1168274230.squirrel@rousalka.dyndns.org> References: <20070106121318.GD6654@neu.nirvana> <45A25834.7090008@redhat.com> <20070108161533.ad9b5d98.bugs.michael@gmx.net> <45A2645F.6050300@redhat.com> <20070108154927.GA18545@neu.nirvana> <45A26B6A.50802@redhat.com> <20070108160929.GC18545@neu.nirvana> <51755.192.54.193.51.1168274230.squirrel@rousalka.dyndns.org> Message-ID: <20070108165114.GF18545@neu.nirvana> On Mon, Jan 08, 2007 at 05:37:10PM +0100, Nicolas Mailhot wrote: > > Le Lun 8 janvier 2007 17:09, Axel Thimm a ?crit : > > On Mon, Jan 08, 2007 at 11:03:54AM -0500, Fernando Nasser wrote: > > >> Axel, 1.10 wins over 1.09. Why do you need an Epoch in this case? > > > > Sorry, I meant 1.1 vs 1.09. > > Then the best practice would be to write 1.1 1.10 You mean writing instead of 1.1 the version 1.10? Even if this would save the day for this package there are other worse examples coming from the perl world mostly, e.g. 1.00001 vs 1.0000000009 to exaggerate a bit. perl itself had some awkward versioning like the above. > (I hope this is documented somewhere). You mean the "remove all left-padding zeros" stuff? Perhaps it is by now, maybe in online book by E. Johnson (or better said the draft of it), but in general it is usually easier to browse through in rpmvercmp's sources. There's where one can also find that (technically) epochs are treated like versions for a couple of years now. [Previously they were really restricted to integers, who knows why this was changed, obviously there is a distro somewhere in need of non-integer epochs, or this is one of the unneeded extensions rpm got over the years w/o anyone realy needing it] > Tought of course it would be better if upstream used a fixed digit > number, but some developpers have been known to take this suggestion > as a pretext to rant on Red Hat in general, and rpm in particular. Yep, upstream sometimes isn't glad to get well-meant recommendations for how to version their babies, not even if it's being emphasized that non-rpm packaging systems would benefit, too. But it feels like the number of such adversaries is going down. -- 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 bugs.michael at gmx.net Mon Jan 8 17:06:15 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 8 Jan 2007 18:06:15 +0100 Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <200701081137.22573.jkeating@redhat.com> References: <20070106121318.GD6654@neu.nirvana> <200701081106.00395.jkeating@redhat.com> <20070108173742.afbbaf73.bugs.michael@gmx.net> <200701081137.22573.jkeating@redhat.com> Message-ID: <20070108180615.a5a35aca.bugs.michael@gmx.net> On Mon, 8 Jan 2007 11:37:22 -0500, Jesse Keating wrote: > On Monday 08 January 2007 11:37, Michael Schwendt wrote: > > No. You add the Epoch to the package, not the API. > > > > ? foo-1.2-1.i386.rpm ?provides ?foo(api) = 1.2 > > ? foo-2.0-1.i386.rpm ?provides ?foo(api) = 2.0 > > > > Rollback: > > > > ? foo-1:1.2-1.i386.rpm ?provides ?foo(api) = 1.2 > > ? ? ? ^^ > > > > The Epoch at the level of RPM version comparison achieves that the > > rollback works flawlessly. > > > > Perl modules work this way today, since their module version (in automatic > > "Provides") is independent from the package EVR. > > Ah. So then all that would be left is rebuilding anything that required > foo(api) 2.0, that is anything that was built against the bunk package, which > is a problem we would have either way. foo(api) = %{version}%{?patchlevel} for BuildRequires, +foo(abi) plus the automatic SONAME dependencies for binary rpms. From mattdm at mattdm.org Mon Jan 8 17:08:10 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 8 Jan 2007 12:08:10 -0500 Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <51755.192.54.193.51.1168274230.squirrel@rousalka.dyndns.org> References: <20070106121318.GD6654@neu.nirvana> <45A25834.7090008@redhat.com> <20070108161533.ad9b5d98.bugs.michael@gmx.net> <45A2645F.6050300@redhat.com> <20070108154927.GA18545@neu.nirvana> <45A26B6A.50802@redhat.com> <20070108160929.GC18545@neu.nirvana> <51755.192.54.193.51.1168274230.squirrel@rousalka.dyndns.org> Message-ID: <20070108170810.GA7161@jadzia.bu.edu> On Mon, Jan 08, 2007 at 05:37:10PM +0100, Nicolas Mailhot wrote: > > Sorry, I meant 1.1 vs 1.09. > Then the best practice would be to write 1.1 1.10 (I hope this is > documented somewhere). Tought of course it would be better if upstream I'm not sure that's best practice at all -- version numbers should match upstream version numbers as closely as possible. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From bugs.michael at gmx.net Mon Jan 8 17:22:35 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 8 Jan 2007 18:22:35 +0100 Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <51755.192.54.193.51.1168274230.squirrel@rousalka.dyndns.org> References: <20070106121318.GD6654@neu.nirvana> <45A25834.7090008@redhat.com> <20070108161533.ad9b5d98.bugs.michael@gmx.net> <45A2645F.6050300@redhat.com> <20070108154927.GA18545@neu.nirvana> <45A26B6A.50802@redhat.com> <20070108160929.GC18545@neu.nirvana> <51755.192.54.193.51.1168274230.squirrel@rousalka.dyndns.org> Message-ID: <20070108182235.7f0e00e7.bugs.michael@gmx.net> On Mon, 8 Jan 2007 17:37:10 +0100 (CET), Nicolas Mailhot wrote: > > Le Lun 8 janvier 2007 17:09, Axel Thimm a ?crit : > > On Mon, Jan 08, 2007 at 11:03:54AM -0500, Fernando Nasser wrote: > > >> Axel, 1.10 wins over 1.09. Why do you need an Epoch in this case? > > > > Sorry, I meant 1.1 vs 1.09. > > Then the best practice would be to write 1.1 1.10 (I hope this is > documented somewhere). Tought of course it would be better if upstream > used a fixed digit number, but some developpers have been known to take > this suggestion as a pretext to rant on Red Hat in general, and rpm in > particular. Rollback with Epoch bump and an incompatible versioning scheme chosen by upstream are two different problems. Upstream developers can be educated as soon as they increment their numbers in bad ways. Don't assume a worst case. And even if they were stubborn enough to stick to an incompatible versioning scheme that breaks RPM version comparison, "Provides" could work around the incompatible increase (e.g. with 1.09 => "1.1 = 1.10") or even be deleted to break dependencies deliberately: foo-devel-1.09-1.i386.rpm provides foo(api) = 1.09 upgrade attempt: foo-devel-1.1-1.i386.rpm ... ooops! 1.1 < 1.09 ... now what? Anything which does BR foo(api) >= 1.09 would fail already. Epoch bump makes RPM upgrade possible at least, foo-devel-1:1.1-1.i386.rpm and what to provide? A possibly fragile foo(api) = 1.10 where 1.1=1.10? Or maybe a new API like foo(api.2) = 1.1? The same is not possible with the fully automatic %name = E:VR Provides. From nicolas.mailhot at laposte.net Mon Jan 8 17:48:37 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 08 Jan 2007 18:48:37 +0100 Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <20070108170810.GA7161@jadzia.bu.edu> References: <20070106121318.GD6654@neu.nirvana> <45A25834.7090008@redhat.com> <20070108161533.ad9b5d98.bugs.michael@gmx.net> <45A2645F.6050300@redhat.com> <20070108154927.GA18545@neu.nirvana> <45A26B6A.50802@redhat.com> <20070108160929.GC18545@neu.nirvana> <51755.192.54.193.51.1168274230.squirrel@rousalka.dyndns.org> <20070108170810.GA7161@jadzia.bu.edu> Message-ID: <1168278517.12415.2.camel@rousalka.dyndns.org> Le lundi 08 janvier 2007 ? 12:08 -0500, Matthew Miller a ?crit : > On Mon, Jan 08, 2007 at 05:37:10PM +0100, Nicolas Mailhot wrote: > > > Sorry, I meant 1.1 vs 1.09. > > Then the best practice would be to write 1.1 1.10 (I hope this is > > documented somewhere). Tought of course it would be better if upstream > > I'm not sure that's best practice at all -- version numbers should match > upstream version numbers as closely as possible. In the perl case versions are numbers so 1.1 = 1.10 Though some perl authors rejoice in skipping the last 0 to make Red Hat users suffer (speaking from painful experience) -- 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 Axel.Thimm at ATrpms.net Mon Jan 8 17:59:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 8 Jan 2007 18:59:13 +0100 Subject: [Fedora-packaging] Re: Guidelines and epochs In-Reply-To: <1168278517.12415.2.camel@rousalka.dyndns.org> References: <20070106121318.GD6654@neu.nirvana> <45A25834.7090008@redhat.com> <20070108161533.ad9b5d98.bugs.michael@gmx.net> <45A2645F.6050300@redhat.com> <20070108154927.GA18545@neu.nirvana> <45A26B6A.50802@redhat.com> <20070108160929.GC18545@neu.nirvana> <51755.192.54.193.51.1168274230.squirrel@rousalka.dyndns.org> <20070108170810.GA7161@jadzia.bu.edu> <1168278517.12415.2.camel@rousalka.dyndns.org> Message-ID: <20070108175913.GG18545@neu.nirvana> On Mon, Jan 08, 2007 at 06:48:37PM +0100, Nicolas Mailhot wrote: > Though some perl authors rejoice in skipping the last 0 to make Red Hat > users suffer (speaking from painful experience) We should ban perl and perl-modules in return to balance the suffering ;) -- 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 Jan 10 14:02:15 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 10 Jan 2007 15:02:15 +0100 Subject: [Fedora-packaging] fonts packaging guidelines, or advices? Message-ID: <20070110140215.GA2664@free.fr> Hello, I think it could be helpful to have some guidelines regarding fonts. I guess people specialized in fonts packaging are allready following more or less formal rules, but I have felt the need for guidelines when I package something and it has fonts within, or when there is a need for some fonts in a package. A font SIG or something similar than what is found at Packaging/Perl could be enough, since the lack may be more about a lack of information regarding font packaging than about a lack of formal rules, although I think that some advice could be best practices and then guidelines. What would be interesting in my opinion would be: - advices on when to package fonts and when not to package them - advice on acceptable font uses, depending on the font (I guess that bitmap fonts, truetype and Type? fonts shouldn't be used for the same tasks) - when to do subpackages - advice on fonts installation location (to my knowledge there is nothing on that subject in the FHS), depending on the font. - scriptlets for all the kind of fonts (truetype, Type? and bitmap) with more explanations about the scriptlets than what is today. An explanation on what subsystem begins aware of which font after which scriptlet is run would be a must in my opinion. - explanation on how to avoid messing with fonts provided in other packages Something along what is done for rpath, for example could be very usefull in my opinion, especially now that all the core package containing fonts are to be reviewed. It may be possible that even more coordination that packaging best practices are needed, to avoid messing with others fonts, I don't know the underlying technology enough, but some mail exchanges on (if I recall well on the fedora-devel-list) makes me think that way. Guidelines would certainly be a good start. -- Pat From rdieter at math.unl.edu Wed Jan 10 17:09:47 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 10 Jan 2007 11:09:47 -0600 Subject: [Fedora-packaging] interesting rpm-devel thread wrt libtool/.la file policy Message-ID: <45A51DDB.2050503@math.unl.edu> http://lists.dulug.duke.edu/pipermail/rpm-devel/2007-January/002011.html -- Rex From tibbs at math.uh.edu Wed Jan 10 21:35:12 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 10 Jan 2007 15:35:12 -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: >>>>> "TC" == Tom 'spot' Callaway writes: TC> I drafted a proposal for when it is ok to use Conflicts: (almost TC> never): http://fedoraproject.org/wiki/PackagingDrafts/Conflicts I just wanted to remind folks that FESCo would really like for us to finish up guidelines for conflicts (and Conflicts:) soon. Not much has happened to the draft since it was presented. The discussion I actually recall revolved around the suggestions in the "Conflicting Files" section: man pages should probably go into different "sections" (like Coin2-devel and Inventor-devel) instead of being renamed. I recall objection to using "alternatives" for conflicting binaries. There's probably plenty I don't recall, however. We really should try to finish this up and present it to the various committees next week. - J< From jkeating at redhat.com Wed Jan 10 21:53:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 10 Jan 2007 16:53:41 -0500 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: References: <1165339581.20269.249.camel@localhost.localdomain> Message-ID: <200701101653.41770.jkeating@redhat.com> On Wednesday 10 January 2007 16:35, Jason L Tibbitts III wrote: > I just wanted to remind folks that FESCo would really like for us to > finish up guidelines for conflicts (and Conflicts:) soon. ?Not much > has happened to the draft since it was presented. > > The discussion I actually recall revolved around the suggestions in > the "Conflicting Files" section: > > ?man pages should probably go into different "sections" (like > ?Coin2-devel and Inventor-devel) instead of being renamed. > > ?I recall objection to using "alternatives" for conflicting binaries. > > There's probably plenty I don't recall, however. ?We really should try > to finish this up and present it to the various committees next week. What about the situation where Foo conflicts with bar <= 1.0, but Foo doesn't require bar to run? A Requires: bar > 1.0 doesn't work here, can a conflicts be used in this case? Is this an acceptable situation for the list at the bottom of the page? -- 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 jkeating at redhat.com Wed Jan 10 21:55:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 10 Jan 2007 16:55:04 -0500 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <200701101653.41770.jkeating@redhat.com> References: <1165339581.20269.249.camel@localhost.localdomain> <200701101653.41770.jkeating@redhat.com> Message-ID: <200701101655.04911.jkeating@redhat.com> On Wednesday 10 January 2007 16:53, Jesse Keating wrote: > On Wednesday 10 January 2007 16:35, Jason L Tibbitts III wrote: > > I just wanted to remind folks that FESCo would really like for us to > > finish up guidelines for conflicts (and Conflicts:) soon. ?Not much > > has happened to the draft since it was presented. > > > > The discussion I actually recall revolved around the suggestions in > > the "Conflicting Files" section: > > > > ?man pages should probably go into different "sections" (like > > ?Coin2-devel and Inventor-devel) instead of being renamed. > > > > ?I recall objection to using "alternatives" for conflicting binaries. > > > > There's probably plenty I don't recall, however. ?We really should try > > to finish this up and present it to the various committees next week. > > What about the situation where Foo conflicts with bar <= 1.0, but Foo > doesn't require bar to run? A Requires: bar > 1.0 doesn't work here, can a > conflicts be used in this case? Is this an acceptable situation for the > list at the bottom of the page? Also, this draft seems to be missing a clear "Problem this is trying to solve" statement, which goes a long way to getting people to understand/comment on 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 bugs.michael at gmx.net Wed Jan 10 23:00:06 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 11 Jan 2007 00:00:06 +0100 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <200701101653.41770.jkeating@redhat.com> References: <1165339581.20269.249.camel@localhost.localdomain> <200701101653.41770.jkeating@redhat.com> Message-ID: <20070111000006.3b625d60.bugs.michael@gmx.net> On Wed, 10 Jan 2007 16:53:41 -0500, Jesse Keating wrote: > What about the situation where Foo conflicts with bar <= 1.0, but Foo doesn't > require bar to run? A Requires: bar > 1.0 doesn't work here, can a conflicts > be used in this case? Is this an acceptable situation for the list at the > bottom of the page? It depends on two questions: Does the distribution release include a conflicting pair of foo and bar? If after a fresh install, foo and bar are not installed. Does a "yum install foo bar" work? (In your example. is bar <= 1.0?) Is there an upgrade path for either one? That means the conflict must not make an upgrade from a previous dist release impossible. As in telling the user that there is a conflict, and when the user tries to exclude one of the packages, it is pulled back in by the dependency chain and leads to a "WTF?" scenario. E.g. installed is foo, and the dist upgrade wants to update foo + install a conflicting version of bar, or vice versa. From notting at redhat.com Thu Jan 11 04:57:53 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 10 Jan 2007 23:57:53 -0500 Subject: [Fedora-packaging] Conflicts Draft Proposal In-Reply-To: <200701101653.41770.jkeating@redhat.com> References: <1165339581.20269.249.camel@localhost.localdomain> <200701101653.41770.jkeating@redhat.com> Message-ID: <20070111045752.GB2102@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > What about the situation where Foo conflicts with bar <= 1.0, but Foo doesn't > require bar to run? A Requires: bar > 1.0 doesn't work here, can a conflicts > be used in this case? Is this an acceptable situation for the list at the > bottom of the page? So, my usual pile of examples would be: kernel: Conflicts: ipw2200-firmware < 2.4 i.e., if you're using this kernel with ipw2200, you need at least that level of firmware. initscripts: Conflicts: xorg-x11 (essentially, with xorg-not-in-/usr Conflicts: kernel < 2.6.12 (requires at least that new of a kernel) and so on. Bill From fnasser at redhat.com Thu Jan 11 22:49:39 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 11 Jan 2007 17:49:39 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals Message-ID: <45A6BF03.2000303@redhat.com> Hi all, At Jesse's request, I took a look at the Wiki page in http://fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming "Naming Conventions for Packages Adapted from JPackage" Of course, some time has passed and things have already evolved, so I will try and update the text. Please comment and lets see how we should update the Wiki page. 1) Problem Space "Many Java programs are first packaged by the [WWW] jpackage project. In essence, the Fedora packages have two upstreams: The upstream project itself and the jpackage project's spec file and patches. Fedora imports a package from jpackage and makes changes to enable native AOT compilation via gcj and bugfixes that have not been merged into either of the upstreams." > Well, The last sentence is no longer true. The AOT compilation bits were propagated upstream, so all the Java team has to do now is to import the upstram package as is and build. We still need to make any changes to the code to circumvent GCJ shortcomes, but these are so rare nowadays that almost all packages build without any changes at all. > As a consequence, fixes have been made on the usptream version, which is them re-imported, and we've been also reimporting when fixes are applied upstream comming from the other JPackage-based distros or from direct JPackage users feedback. "Presently, Core's jpackage-based packages have reflected the package origin within the package Release: 1jpp_2fc In this scheme, the 1jpp is the upstream jpackage release, _ is a separator, and 2fc is the Fedora release. (Note, this scheme is not currently as defined as the Fedora Naming Guidelines. So there are some practices above the base standard that would need to change.) This scheme has two expressed goals:" > OK, here we have made much progress: a. The "_" character has been removed and replaced by a '.' b. The "fc" string has been removed c. All FC6 packages have been rebuilt to comply with a and b above d. An initial agreement has been reached to also compatibilize the pre-release cases, with JPackage adopting a Fedora-like order. > Summary: It all comes down now to the remaining ".NNjpp" in the release which indicates the upstream version that was last imported (sync point you could call it). In the case of the goals, I think the original ones in the week were not correct in the first place. Lets try again: " 1. Allow for upgrading between the Fedora and JPackage repositories so that upgrade paths similar to the following works: * java-foo-1.0-1jpp_2fc [Fedora Release] java-foo-1.0-2jpp [Updated JPackage Release] java-foo-1.0-2jpp_3fc [Updated Fedora Release rebased against the new JPackage] 3. A third expressed goal that conflicts with 1. is to upgrade Fedora packages only with Fedora packages and jpackage packages with jpackage packages." > These two goals can be made into a single one, lets say: "flexible upgrade paths". > There is no conflict whatsoever -- we currently do all these: a. Both Fedora and JPackage (what is stated in 1, i.e., newest release globally) by leaving all repos enabled (both fedora-core and jpackage) b. Fedora only by disabling the jpackage.repo c. JPackage only by using --exclude=*jpp* --excluce=eclipse* when upgrading from fedora-core.repo and enabling only the jpackage.repo for the Java packages update (people play with --enablerepo for that management) "2. Allow users and packagers to tell what JPackage release the java package was based against." > This is very important to us (Java team). We can quickly identify if the version we have already has a fix or not, among other things. I will have to add a goal that was not stated in the initial Wiki, lets call it 4: "4. Allow the switching of Java stacks as a whole" > This is currently accomplished by using regular expressions based on the *jpp* and eclipse* patterns. > This is useful for development so we can try sets of packages built with a different compiler for instance, without having to change all spec files to bump releases, and to revert the system to the original state afterwards. We use this a lot. > There are also users that want to switch the collection of Java packages to use a set compiled with a proprietary JDK for instance (maybe a different version of Java), or something provided by the software vendor of some major component they bought. OK, now the Wiki page states: "Which naming guideline is chosen depends in large part on whether these are judged to be worthwhile and attainable goals." > Which I think is correct. Discussion of the goals "Goal #1 If JPackage were truly an upstream then we wouldn't want users to upgrade Fedora Packages with JPackage. We have bugfixes, local changes, and other patches that we add to packages to make them work better on Fedora. Having users upgrade between upstream and our packages is not a goal with any other upstream. gbenson states this [WWW] here although he phrases it in the specifics of Fedora/JPackage instead of the general Fedora/Upstream." > We don't do anything to make packages run better on Fedora. We do pre-compilation, which does help in the startup time. But there is no real harm in revert to a bytecode-only package to get an upstream fix until it shows up in pre-compiled form in a Fedora update. "There could be times when the jpackage naming is not compliant in the name, version, or release fields. When this happens, we would not be able to attain this goal. For instance: cryptix-asn1-20011119-4jpp_2fc.1.1.src.rpm. The version field must be changed before importing otherwise the final release of cryptix-asn1-1.0 will not upgrade the package." > That was a wrongly versioned package from an older JPackage release. The maintainer was informed and the problem was fixed. It is now cryptix-3.2.0-9jpp. In general, we have had no problems in getting this kind of things fixed. I think this comment can be removed. "Goal #3 This is not truly implementable via the package release tag. Separating the native libraries into a subpackage might have some bearing on this." > Yes it is implementable, as shown above. "Goal #2 Users shouldn't need this information. The Fedora Package may have more fixes than the JPackage one. It may be synced with more upstream bugfixes. It may contain snapshots of JPackage work that haven't hit the repositories yet because JPackage is working on a new major release. If the package works without bugs then the end user is happy." > Putting a set of compatible packages together is a major endeavor. The Java team, as well as the folks from Mandriva and Suse have been basically polishing the sets that have been created upstream. > Also, we make the fixes/changes upstream first, then import. This way we benefit from feedback from people (both packages and Java users) who know deeply some of these Java software libraries. > Again: updating paths are optional, and it is up to the user to choose. The current naming only allows that to be done if so desired, which would be otherwise not possible. "Developers can use this information. But they aren't going to be staring at the package name most of the time. When they checkout from cvs, they'll have a spec file, not an RPM so the filename is no help. They have to look inside the spec file at which point it's just as easy to put the information in the %description, a Provides, or a comment. Using a Provides makes it queryable from the rpm command line as well." > The way we do now is by "rpm -qa | grep jpp" and variations. Or similar pattern usage in the repos. We don't need to look inside the spec file to know that the base for that release was a specific upstream release. > Using things like "Provides" for things that are not their original goal would be abusing that feature, and the information for that is used by depsolvers and such. We should stay away from that. In a lesser degree, maintaining a release in the description is not convenient and error prone, and does not address the other goals anyway. The Wiki page then has some proposals, which I would prefer to discuss each one separately once we agree on the goals. Regards to all, Fernando From jkeating at redhat.com Fri Jan 12 03:30:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 11 Jan 2007 22:30:34 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <45A6BF03.2000303@redhat.com> References: <45A6BF03.2000303@redhat.com> Message-ID: <200701112230.35156.jkeating@redhat.com> On Thursday 11 January 2007 17:49, Fernando Nasser wrote: > Discussion of the goals > > "Goal #1 > > If JPackage were truly an upstream then we wouldn't want users to > upgrade Fedora Packages with JPackage. We have bugfixes, local changes, > and other patches that we add to packages to make them work better on > Fedora. Having users upgrade between upstream and our packages is not a > goal with any other upstream. gbenson states this [WWW] here although he > phrases it in the specifics of Fedora/JPackage instead of the general > Fedora/Upstream." > > > ?> We don't do anything to make packages run better on Fedora. ?We do > pre-compilation, which does help in the startup time. ?But there is no > real harm in revert to a bytecode-only package to get an upstream fix > until it shows up in pre-compiled form in a Fedora update. > > > > "There could be times when the jpackage naming is not compliant in the > name, version, or release fields. When this happens, we would not be > able to attain this goal. For instance: > cryptix-asn1-20011119-4jpp_2fc.1.1.src.rpm. The version field must be > changed before importing otherwise the final release of cryptix-asn1-1.0 > will not upgrade the package." > > ?> That was a wrongly versioned package from an older JPackage release. > ? The maintainer was informed and the problem was fixed. ?It is now > cryptix-3.2.0-9jpp. ?In general, we have had no problems in getting this > kind of things fixed. ?I think this comment can be removed. > > > "Goal #3 > > This is not truly implementable via the package release tag. > > Separating the native libraries into a subpackage might have some > bearing on this." > > ?> Yes it is implementable, as shown above. > > > "Goal #2 > > Users shouldn't need this information. The Fedora Package may have more > fixes than the JPackage one. It may be synced with more upstream > bugfixes. It may contain snapshots of JPackage work that haven't hit the > repositories yet because JPackage is working on a new major release. If > the package works without bugs then the end user is happy." > > ?> Putting a set of compatible packages together is a major endeavor. > The Java team, as well as the folks from Mandriva and Suse have been > basically polishing the sets that have been created upstream. > > ?> Also, we make the fixes/changes upstream first, then import. ?This > way we benefit from feedback from people (both packages and Java users) > who know deeply some of these Java software libraries. What about cases where we need to rebuild the package internally for a mass rebuild, a java change or whatnot? Especially if it doesn't line up with a rebuild upstream, do we just have to convince jpackage to do a spurious rebuild? Otherwise, we're going to bump and build within our CVS, then next time you import an srpm from upstream, you'll stomp on any changes we've made. -- 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 a.badger at gmail.com Fri Jan 12 04:25:05 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 11 Jan 2007 20:25:05 -0800 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <45A6BF03.2000303@redhat.com> References: <45A6BF03.2000303@redhat.com> Message-ID: <1168575905.4545.113.camel@localhost.localdomain> On Thu, 2007-01-11 at 17:49 -0500, Fernando Nasser wrote: > 1) Problem Space > > "Many Java programs are first packaged by the [WWW] jpackage project. In > essence, the Fedora packages have two upstreams: The upstream project > itself and the jpackage project's spec file and patches. Fedora imports > a package from jpackage and makes changes to enable native AOT > compilation via gcj and bugfixes that have not been merged into either > of the upstreams." > > > Well, The last sentence is no longer true. The AOT compilation bits > were propagated upstream, so all the Java team has to do now is to > import the upstram package as is and build. We still need to make any > changes to the code to circumvent GCJ shortcomes, but these are so rare > nowadays that almost all packages build without any changes at all. > Sounds good. > > As a consequence, fixes have been made on the usptream version, which > is them re-imported, and we've been also reimporting when fixes are > applied upstream comming from the other JPackage-based distros or from > direct JPackage users feedback. > Sounds like a good deal. > > > "Presently, Core's jpackage-based packages have reflected the package > origin within the package Release: 1jpp_2fc In this scheme, the 1jpp is > the upstream jpackage release, _ is a separator, and 2fc is the Fedora > release. (Note, this scheme is not currently as defined as the Fedora > Naming Guidelines. So there are some practices above the base standard > that would need to change.) This scheme has two expressed goals:" > > > OK, here we have made much progress: > > a. The "_" character has been removed and replaced by a '.' > > b. The "fc" string has been removed > > c. All FC6 packages have been rebuilt to comply with a and b above > Reading this it looks like the packages are now namedSo name-numericversion-1jpp upstream and name-numericversion-1jpp.2 by Fedora. Is that correct? > d. An initial agreement has been reached to also compatibilize the > pre-release cases, with JPackage adopting a Fedora-like order. > Do you have a link to this documentation? I found this: http://www.jpackage.org/cgi-bin/viewvc.cgi/*checkout*/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?root=jpackage&content-type=text%2Fhtml Which doesn't cover versioning and this: http://www.jpackage.org/jpppolicy.php which says it's the old version and indeed, has the old versioning information. > > Summary: It all comes down now to the remaining ".NNjpp" in the > release which indicates the upstream version that was last imported > (sync point you could call it). > > > In the case of the goals, I think the original ones in the week were not > correct in the first place. Lets try again: > > " 1. Allow for upgrading between the Fedora and JPackage repositories > so that upgrade paths similar to the following works: > * > > java-foo-1.0-1jpp_2fc [Fedora Release] > java-foo-1.0-2jpp [Updated JPackage Release] > java-foo-1.0-2jpp_3fc [Updated Fedora Release rebased > against the new JPackage] > > 3. A third expressed goal that conflicts with 1. is to upgrade > Fedora packages only with Fedora packages and jpackage packages with > jpackage packages." > > > > These two goals can be made into a single one, lets say: "flexible > upgrade paths". > > > There is no conflict whatsoever -- we currently do all these: > > a. Both Fedora and JPackage (what is stated in 1, i.e., newest release > globally) by leaving all repos enabled (both fedora-core and jpackage) > > b. Fedora only by disabling the jpackage.repo > > c. JPackage only by using --exclude=*jpp* --excluce=eclipse* when > upgrading from fedora-core.repo and enabling only the jpackage.repo for > the Java packages update (people play with --enablerepo for that management) > You're not understanding Goal #3. The goal is to have a mixture of Fedora and JPackage packages installed on the system. Running "yum update" will update to the latest version of the software from the repository which the current version comes from. Your (b) and (c) are for the case where you want to draw your java packages from either Fedora or JPackage, not both. Goal #3 could probably be realized with commandline switches if Fedora did not include jpp in the name: yum update --disablerepo=jpackage --exclude='*jpp*'; yum update --enablerepo=jpackage '*jpp*' > > > "2. Allow users and packagers to tell what JPackage release the > java package was based against." > > > > This is very important to us (Java team). We can quickly identify if > the version we have already has a fix or not, among other things. > Can you give a developer use case? We tried to imagine a use case for developers and what we came up with was looking in cvs for the package. At that point, there is no rpm package so there is no release tag. Giving us a few use cases will help to see what will and won't work. > > I will have to add a goal that was not stated in the initial Wiki, lets > call it 4: > > "4. Allow the switching of Java stacks as a whole" > > > This is currently accomplished by using regular expressions based on > the *jpp* and eclipse* patterns. > Again, a use case would be nice. I'm imagining switching between the jpackage java stack and the Fedora java stack and don't see how *jpp* would help here. Unless you mean it makes it easy for you to select all the java packages on the system and replace them with something else? That strikes me as a misuse of the release tag -- 1) Not all java packages will have the jpp name as not all java packages will come to us through jpackage. 2) If we do this for java, why not for python, perl, php, etc? > > This is useful for development so we can try sets of packages built > with a different compiler for instance, without having to change all > spec files to bump releases, and to revert the system to the original > state afterwards. We use this a lot. > > > There are also users that want to switch the collection of Java > packages to use a set compiled with a proprietary JDK for instance > (maybe a different version of Java), or something provided by the > software vendor of some major component they bought. > You're going to have to post the commands you use to achieve these things as I'm having problems understanding how you're doing this based on the release tag. > > > OK, now the Wiki page states: > > "Which naming guideline is chosen depends in large part on whether these > are judged to be worthwhile and attainable goals." > > > Which I think is correct. > > > > > Discussion of the goals > > "Goal #1 > > If JPackage were truly an upstream then we wouldn't want users to > upgrade Fedora Packages with JPackage. We have bugfixes, local changes, > and other patches that we add to packages to make them work better on > Fedora. Having users upgrade between upstream and our packages is not a > goal with any other upstream. gbenson states this [WWW] here although he > phrases it in the specifics of Fedora/JPackage instead of the general > Fedora/Upstream." > > > > We don't do anything to make packages run better on Fedora. We do > pre-compilation, which does help in the startup time. But there is no > real harm in revert to a bytecode-only package to get an upstream fix > until it shows up in pre-compiled form in a Fedora update. > This may be true in the RH-Fedora java group but it won't be true in the Fedora-community java space unless the mandate from the FTC is to get packages approved in jpackage before getting them into Fedora. Not everything happens upstream. Not every upstream agrees with the downstream. Not every upstream has the same time frame for updates as downstream. We will carry local patches and changes at some point. > > > "There could be times when the jpackage naming is not compliant in the > name, version, or release fields. When this happens, we would not be > able to attain this goal. For instance: > cryptix-asn1-20011119-4jpp_2fc.1.1.src.rpm. The version field must be > changed before importing otherwise the final release of cryptix-asn1-1.0 > will not upgrade the package." > > > That was a wrongly versioned package from an older JPackage release. > The maintainer was informed and the problem was fixed. It is now > cryptix-3.2.0-9jpp. In general, we have had no problems in getting this > kind of things fixed. I think this comment can be removed. > No. cryptix-asn1 is an example. It doesn't matter if the specific package has been fixed. The question's contained here are: 1) What are jpackage's naming guidelines so we can see how they mesh with our names? 2) If there's a bug with the jpackage naming what will we do until it's fixed? 3) Do we want to force our packagers and reviewers to learn two sets of guidelines, one for jpackage, and one for Fedora? > > "Goal #3 > > This is not truly implementable via the package release tag. > > Separating the native libraries into a subpackage might have some > bearing on this." > > > Yes it is implementable, as shown above. You're right. Remove the jpp from Fedora package release tags and we should be able to do this :-) Seriously, the goal is to have "yum update" just work, so even with jpp removed, we can't achieve this. > > "Goal #2 > > Users shouldn't need this information. The Fedora Package may have more > fixes than the JPackage one. It may be synced with more upstream > bugfixes. It may contain snapshots of JPackage work that haven't hit the > repositories yet because JPackage is working on a new major release. If > the package works without bugs then the end user is happy." > > > Putting a set of compatible packages together is a major endeavor. > The Java team, as well as the folks from Mandriva and Suse have been > basically polishing the sets that have been created upstream. > Ain't that the truth! We have to do this for the entire distro. That's a bit besides the point. > > Also, we make the fixes/changes upstream first, then import. This > way we benefit from feedback from people (both packages and Java users) > who know deeply some of these Java software libraries. > This is where we have divergence. You claim that all fixes go upstream first. I claim that 1) this won't continue to be the case (all fixes) and 2) it may not be desirable. Example: There's a showstopper bug in a java package just before F7 is spun. The jpackage maintainer doesn't think it's a showstopper or would rather wait for upstream to fix it before committing a patch. We aren't going to hold F7 for it so we have to fix it locally. Example: jpackage upgrades to a beta version of a component while we want to stay on the stable release or vice versa. > > Again: updating paths are optional, and it is up to the user to > choose. The current naming only allows that to be done if so desired, > which would be otherwise not possible. > Not true. Jesse Keating proposed a naming scheme which would work equally well. > > > "Developers can use this information. But they aren't going to be > staring at the package name most of the time. When they checkout from > cvs, they'll have a spec file, not an RPM so the filename is no help. > They have to look inside the spec file at which point it's just as easy > to put the information in the %description, a Provides, or a comment. > Using a Provides makes it queryable from the rpm command line as well." > > > > The way we do now is by "rpm -qa | grep jpp" and variations. Or > similar pattern usage in the repos. We don't need to look inside the > spec file to know that the base for that release was a specific upstream > release. > What are you looking for inside the package repos? What is your rpm -qa |grep jpp used for? The comment above was from the projected usage case of a developer needing to look at a package in the cvs repository to decide what version a package was built against. In that case, you would need to look inside the spec. Help us understand what you're doing so we can see where the other proposals fail. > > Using things like "Provides" for things that are not their original > goal would be abusing that feature, and the information for that is used > by depsolvers and such. We should stay away from that. In a lesser > degree, maintaining a release in the description is not convenient and > error prone, and does not address the other goals anyway. There's all manner of odd things in Provides. Provides: jpackage(foo) = 1.0-1jpp Would fit right in :-) -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 Fri Jan 12 10:21:32 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 12 Jan 2007 11:21:32 +0100 (CET) Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals Message-ID: <4001.192.54.193.51.1168597292.squirrel@rousalka.dyndns.org> Le Ven 12 janvier 2007 05:25, Toshio Kuratomi a ?crit : > Not every upstream agrees with the > downstream. Not every upstream has the same time frame for updates as > downstream. We will carry local patches and changes at some point. Fernando for example is part of the jpackage commiters. He can get fixes upstream fast (as long as they're actual fixes, not quick hacks that break other java packages). The number of jpackage commiters is small, they trust each other, you don't have the long Fedora procedures designed to get occasional packagers in line. Fedora won't have to wait for JPP, most often JPP will have to wait for changes to propagate @fedora Regards, -- Nicolas Mailhot From fnasser at redhat.com Fri Jan 12 15:38:44 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 12 Jan 2007 10:38:44 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <200701112230.35156.jkeating@redhat.com> References: <45A6BF03.2000303@redhat.com> <200701112230.35156.jkeating@redhat.com> Message-ID: <45A7AB84.2090808@redhat.com> Jesse Keating wrote: > > What about cases where we need to rebuild the package internally for a mass > rebuild, a java change or whatnot? Especially if it doesn't line up with a > rebuild upstream, do we just have to convince jpackage to do a spurious > rebuild? Why? We have our release number. We already do this now: ......3jpp.1 in FC6 with a rebuild becomes .....3jpp.2 and the scripts do this automatically using the jpp as delimeter. > Otherwise, we're going to bump and build within our CVS, then next > time you import an srpm from upstream, you'll stomp on any changes we've > made. > We have been doing this for a few years now, it was never any problem. Now that the spec files are the same upstream we do an import and spend 1 minute or 2 with vimdiff to merge changelog entries and adjust the release tag. It is been very easy for us (Java team) and we are very happy with this process. From jkeating at redhat.com Fri Jan 12 15:49:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 12 Jan 2007 10:49:11 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part =?iso-8859-1?q?1=09Goals?= In-Reply-To: <45A7AB84.2090808@redhat.com> References: <45A6BF03.2000303@redhat.com> <200701112230.35156.jkeating@redhat.com> <45A7AB84.2090808@redhat.com> Message-ID: <200701121049.11980.jkeating@redhat.com> On Friday 12 January 2007 10:38, Fernando Nasser wrote: > We have been doing this for a few years now, it was never any problem. > Now that the spec files are the same upstream we do an import and spend > 1 minute or 2 with vimdiff to merge changelog entries and adjust the > release tag. > > It is been very easy for us (Java team) and we are very happy with this > process. So you aren't using cvs-import.sh to just import the srpm from upstream? If you are, that stomps on changes and replaces things. The only time you'd get a conflict is if the same lines changed differently, but there could be a NEW changelog entry in the Fedora CVS that doesn't exist upstream, upstream has a new line that doesn't exist in Fedora, once cvs-import.sh is done, only the upstream changelog entry will remain, the one in Fedora will be erased. -- 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 fnasser at redhat.com Fri Jan 12 16:42:55 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 12 Jan 2007 11:42:55 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <1168575905.4545.113.camel@localhost.localdomain> References: <45A6BF03.2000303@redhat.com> <1168575905.4545.113.camel@localhost.localdomain> Message-ID: <45A7BA8F.9020909@redhat.com> Hi Toshio, Toshio Kuratomi wrote: > On Thu, 2007-01-11 at 17:49 -0500, Fernando Nasser wrote: >> 1) Problem Space >> >> "Many Java programs are first packaged by the [WWW] jpackage project. In >> essence, the Fedora packages have two upstreams: The upstream project >> itself and the jpackage project's spec file and patches. Fedora imports >> a package from jpackage and makes changes to enable native AOT >> compilation via gcj and bugfixes that have not been merged into either >> of the upstreams." >> >> > Well, The last sentence is no longer true. The AOT compilation bits >> were propagated upstream, so all the Java team has to do now is to >> import the upstram package as is and build. We still need to make any >> changes to the code to circumvent GCJ shortcomes, but these are so rare >> nowadays that almost all packages build without any changes at all. >> > Sounds good. > >> > As a consequence, fixes have been made on the usptream version, which >> is them re-imported, and we've been also reimporting when fixes are >> applied upstream comming from the other JPackage-based distros or from >> direct JPackage users feedback. >> > Sounds like a good deal. > >> >> "Presently, Core's jpackage-based packages have reflected the package >> origin within the package Release: 1jpp_2fc In this scheme, the 1jpp is >> the upstream jpackage release, _ is a separator, and 2fc is the Fedora >> release. (Note, this scheme is not currently as defined as the Fedora >> Naming Guidelines. So there are some practices above the base standard >> that would need to change.) This scheme has two expressed goals:" >> >> > OK, here we have made much progress: >> >> a. The "_" character has been removed and replaced by a '.' >> >> b. The "fc" string has been removed >> >> c. All FC6 packages have been rebuilt to comply with a and b above >> > Reading this it looks like the packages are now namedSo > name-numericversion-1jpp upstream and name-numericversion-1jpp.2 by > Fedora. Is that correct? > Yes, we were able to do this without breaking any of our scripts or processes and it is much more clean (no extraneous or superfluous characters). >> d. An initial agreement has been reached to also compatibilize the >> pre-release cases, with JPackage adopting a Fedora-like order. >> > Do you have a link to this documentation? I found this: > > http://www.jpackage.org/cgi-bin/viewvc.cgi/*checkout*/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?root=jpackage&content-type=text%2Fhtml > Which doesn't cover versioning and this: > http://www.jpackage.org/jpppolicy.php > which says it's the old version and indeed, has the old versioning > information. > Yes, you are right. As you see, it says 1.5 there. That was for JPP 1.5, and JPackage is releasing JPP 1.7 soon (it is release candidate now). The idea is that as soon as we figure out how we are going to handle the imports into Fedora a "Guidelines" link will be added with updated recommendations. There is a couple of things that must be known first: (a) what is the decision on that thread on Epoch and how that affects the Java packages (they currently always specify the Epoch) (b) the exact syntax for the pre-release tags so that is compatible with Fedora and still incorporates the 'jpp' string. One "de facto" procedure that is already used is that Jpackage maintainers refer people to the Fedora guidelines for any case that is not explicitly covered by some local rule. And the main reason for any local rule is to make sure the other distros that are based on JPackage are also OK with it (Mandriva, Suse...). >> > Summary: It all comes down now to the remaining ".NNjpp" in the >> release which indicates the upstream version that was last imported >> (sync point you could call it). >> >> >> In the case of the goals, I think the original ones in the week were not >> correct in the first place. Lets try again: >> >> " 1. Allow for upgrading between the Fedora and JPackage repositories >> so that upgrade paths similar to the following works: >> * >> >> java-foo-1.0-1jpp_2fc [Fedora Release] >> java-foo-1.0-2jpp [Updated JPackage Release] >> java-foo-1.0-2jpp_3fc [Updated Fedora Release rebased >> against the new JPackage] >> >> 3. A third expressed goal that conflicts with 1. is to upgrade >> Fedora packages only with Fedora packages and jpackage packages with >> jpackage packages." >> >> >> > These two goals can be made into a single one, lets say: "flexible >> upgrade paths". >> >> > There is no conflict whatsoever -- we currently do all these: >> >> a. Both Fedora and JPackage (what is stated in 1, i.e., newest release >> globally) by leaving all repos enabled (both fedora-core and jpackage) >> >> b. Fedora only by disabling the jpackage.repo >> >> c. JPackage only by using --exclude=*jpp* --excluce=eclipse* when >> upgrading from fedora-core.repo and enabling only the jpackage.repo for >> the Java packages update (people play with --enablerepo for that management) >> > You're not understanding Goal #3. The goal is to have a mixture of > Fedora and JPackage packages installed on the system. Running "yum > update" will update to the latest version of the software from the > repository which the current version comes from. Your (b) and (c) are > for the case where you want to draw your java packages from either > Fedora or JPackage, not both. > You mean, if a package is from Fedora, you update it with only another Fedora package and if it came from JPackage only with another JPackage one? Yes, perhaps someone may want that (I never encountered that situation, but I think it may be useful). That is a letter (d) though. (a) has no restriction where a package comes from, the newest one is what is wanted, no matter from where. BTW, I am sure it can be scripted currently with "*jpp$" used to identify what is JPackage. We must be careful with what we define for pre-release tags for that to continue to work though. > Goal #3 could probably be realized with commandline switches if Fedora > did not include jpp in the name: yum update --disablerepo=jpackage > --exclude='*jpp*'; yum update --enablerepo=jpackage '*jpp*' > Yes, that would work. It is only my letter (d) case though. >> >> "2. Allow users and packagers to tell what JPackage release the >> java package was based against." >> >> >> > This is very important to us (Java team). We can quickly identify if >> the version we have already has a fix or not, among other things. >> > Can you give a developer use case? We tried to imagine a use case for > developers and what we came up with was looking in cvs for the package. > At that point, there is no rpm package so there is no release tag. > Giving us a few use cases will help to see what will and won't work. > I'd like the other Java team members to comment on this. I only have a share of the packages to maintain. That is how I control my packages but I'd rather other people give testmony. Deepak? Vivek? Matthew? Permaine? ... >> I will have to add a goal that was not stated in the initial Wiki, lets >> call it 4: >> >> "4. Allow the switching of Java stacks as a whole" >> >> > This is currently accomplished by using regular expressions based on >> the *jpp* and eclipse* patterns. >> > Again, a use case would be nice. I'm imagining switching between the > jpackage java stack and the Fedora java stack and don't see how *jpp* > would help here. > > Unless you mean it makes it easy for you to select all the java packages > on the system and replace them with something else? That strikes me as > a misuse of the release tag -- 1) Not all java packages will have the > jpp name as not all java packages will come to us through jpackage. 2) > If we do this for java, why not for python, perl, php, etc? > Several things in this paragraph. 1) Except for the eclipse package, which removed the 'jpp' tag to conform to the guidelines and is now maintained (the version we use) locally, all Java packages have the 'jpp' string and all come from JPackage. As the system of packaging Java we use is the JPackage system, we contribute all our packages upstream and import them. As long as someone is willing to maintain a package there is no restrictions. This helps us with solving any issues with other Java libraries need by that piece, Java-related packaging issues and so one on a community of Java developers and packagers. 2) Our Java packages (Fedora has a subset, we actually deal with almost 300) have a very complex graph-like relationship among them, creating what people have bee calling a "ecosystem" that is mostly independent, just requiring a JVM to be present. I don't know about python, perl, php etc., I can only comment on Java. 0) There is also the question of using the release tag for that identification purpose. There are several considerations: (i) there are other uses for that string, so as if it is there why not use it (ii) Some other strings in the release identify things as well, for instance, anything marked with %{dist} tells a package has a variant for that distribution; that would also be a similar abuse (iii) some of the proposals suggested even the Provides tag; that would be a serious abuse, it is used by one of the most basic mechanisms of RPM; the release tag markings like %{dist} or jpp are innocuous (iv) RPM and you have no adequate mechanisms at the moment that are so handy, visible and easy to use at the moment. P.S.: We should try and suggest enhancements to the new RPM and to yum (perhaps even contributing patches) to allow this kind of functionality in the future without the need of using the release tag. For instance, I'd like to see easy ways to retrieve, filter on, etc. on tags like Group, both for RPM and Yum. >> > This is useful for development so we can try sets of packages built >> with a different compiler for instance, without having to change all >> spec files to bump releases, and to revert the system to the original >> state afterwards. We use this a lot. >> >> > There are also users that want to switch the collection of Java >> packages to use a set compiled with a proprietary JDK for instance >> (maybe a different version of Java), or something provided by the >> software vendor of some major component they bought. >> > You're going to have to post the commands you use to achieve these > things as I'm having problems understanding how you're doing this based > on the release tag. > I've already posted the yum ones. The above is just a piping of rpm -qa thorugh grep and things like xargs. The regular expresiions given to grep are the key here. >> >> OK, now the Wiki page states: >> >> "Which naming guideline is chosen depends in large part on whether these >> are judged to be worthwhile and attainable goals." >> >> > Which I think is correct. >> >> >> >> >> Discussion of the goals >> >> "Goal #1 >> >> If JPackage were truly an upstream then we wouldn't want users to >> upgrade Fedora Packages with JPackage. We have bugfixes, local changes, >> and other patches that we add to packages to make them work better on >> Fedora. Having users upgrade between upstream and our packages is not a >> goal with any other upstream. gbenson states this [WWW] here although he >> phrases it in the specifics of Fedora/JPackage instead of the general >> Fedora/Upstream." >> >> >> > We don't do anything to make packages run better on Fedora. We do >> pre-compilation, which does help in the startup time. But there is no >> real harm in revert to a bytecode-only package to get an upstream fix >> until it shows up in pre-compiled form in a Fedora update. >> > This may be true in the RH-Fedora java group but it won't be true in the > Fedora-community java space unless the mandate from the FTC is to get > packages approved in jpackage before getting them into Fedora. Not > everything happens upstream. Not every upstream agrees with the > downstream. Not every upstream has the same time frame for updates as > downstream. We will carry local patches and changes at some point. > IMO that should be a recommendation (no mandate -- too many mandates already). As the system that allows the proper Java interoperation of all these things is done upstream, people should try and get their contributions there first. This is the same as wanting a new Perl module and not going through that Perl modules community first. Remember, there may be (we hope there will be) a large Fedora Java community in the future. But a Fedora+other distros comunnity will always be larger than that (just set theory), and the larger the community the better the software/package produced. >> >> "There could be times when the jpackage naming is not compliant in the >> name, version, or release fields. When this happens, we would not be >> able to attain this goal. For instance: >> cryptix-asn1-20011119-4jpp_2fc.1.1.src.rpm. The version field must be >> changed before importing otherwise the final release of cryptix-asn1-1.0 >> will not upgrade the package." >> >> > That was a wrongly versioned package from an older JPackage release. >> The maintainer was informed and the problem was fixed. It is now >> cryptix-3.2.0-9jpp. In general, we have had no problems in getting this >> kind of things fixed. I think this comment can be removed. >> > No. cryptix-asn1 is an example. It doesn't matter if the specific > package has been fixed. I disagree. That is not representative and was a unique mistake made by an individual on a certain date. That would never be propagated into Fedora as it would be detected during the import. The upstream community would be notified and would have fixed it quickly (which was exactly what happened). > The question's contained here are: > 1) What are jpackage's naming guidelines so we can see how they mesh > with our names? No different from Fedora, RHEL or any other package distribution. Actually, people have been referred to the Fedora guidelines lately. > 2) If there's a bug with the jpackage naming what will we do until it's > fixed? The time to fix that is negligible, As the Java team is maintaining the packages upstream, they have commit access so it is very easy to fix these things. > 3) Do we want to force our packagers and reviewers to learn two sets of > guidelines, one for jpackage, and one for Fedora? > There is no conflicting guidelines at the moment that we are aware of, except for the release tag and the pre-release tags that is being worked out. Maybe we will have something else depending on that Epoch thread, but not at the moment. As I said before, except for some Java-specific things that are not covered in generic guidelines, people have been refered to the Fedora guidelines ad so far this has not raised any complaints from the other distros. >> "Goal #3 >> >> This is not truly implementable via the package release tag. >> >> Separating the native libraries into a subpackage might have some >> bearing on this." >> >> > Yes it is implementable, as shown above. > > You're right. Remove the jpp from Fedora package release tags and we > should be able to do this :-) Seriously, the goal is to have "yum > update" just work, so even with jpp removed, we can't achieve this. > We were talking about two different goals. This one yes, but the (a) in my list is not. I deam that more important than this one (my letter (d) now) that I haven't see anyone use yet (although I recognize it may be useful). >> "Goal #2 >> >> Users shouldn't need this information. The Fedora Package may have more >> fixes than the JPackage one. It may be synced with more upstream >> bugfixes. It may contain snapshots of JPackage work that haven't hit the >> repositories yet because JPackage is working on a new major release. If >> the package works without bugs then the end user is happy." >> >> > Putting a set of compatible packages together is a major endeavor. >> The Java team, as well as the folks from Mandriva and Suse have been >> basically polishing the sets that have been created upstream. >> > Ain't that the truth! We have to do this for the entire distro. That's > a bit besides the point. > It is not you who are having to deal with all these Java packages, so please don't speak for us. We have already a heavy load of work and can't handle the results of a fork. >> > Also, we make the fixes/changes upstream first, then import. This >> way we benefit from feedback from people (both packages and Java users) >> who know deeply some of these Java software libraries. >> > This is where we have divergence. You claim that all fixes go upstream > first. I claim that 1) this won't continue to be the case (all fixes) > and 2) it may not be desirable. Example: There's a showstopper bug in > a java package just before F7 is spun. The jpackage maintainer doesn't > think it's a showstopper or would rather wait for upstream to fix it > before committing a patch. We aren't going to hold F7 for it so we have > to fix it locally. Example: jpackage upgrades to a beta version of a > component while we want to stay on the stable release or vice versa. > We do what we do for any software: we add a local change in urgent mode and immediately contact upstream so the fix is incorporated in their next release. If the change gets incorporated into another form that is better than our stop gag fix we correct that in an errata. We've been doing this for things like debuggers, DBMSs, Internet Servers of all sorts for 10+ years. >> > Again: updating paths are optional, and it is up to the user to >> choose. The current naming only allows that to be done if so desired, >> which would be otherwise not possible. >> > Not true. Jesse Keating proposed a naming scheme which would work > equally well. > Lets discuss the goals first. How can we discuss solutions we we havent agreed on the goals? We will examine all the proposed solutions based on the goals we agree upon. >> >> "Developers can use this information. But they aren't going to be >> staring at the package name most of the time. When they checkout from >> cvs, they'll have a spec file, not an RPM so the filename is no help. >> They have to look inside the spec file at which point it's just as easy >> to put the information in the %description, a Provides, or a comment. >> Using a Provides makes it queryable from the rpm command line as well." >> >> >> > The way we do now is by "rpm -qa | grep jpp" and variations. Or >> similar pattern usage in the repos. We don't need to look inside the >> spec file to know that the base for that release was a specific upstream >> release. >> > What are you looking for inside the package repos? What is your rpm -qa > |grep jpp used for? The comment above was from the projected usage case > of a developer needing to look at a package in the cvs repository to > decide what version a package was built against. In that case, you > would need to look inside the spec. Help us understand what you're > doing so we can see where the other proposals fail. > If we know what is the base point by looking at the release tag we don't have to look into a file inside cvs just to see that. And it can be done at large with diffs we do between lists of package sets. >> > Using things like "Provides" for things that are not their original >> goal would be abusing that feature, and the information for that is used >> by depsolvers and such. We should stay away from that. In a lesser >> degree, maintaining a release in the description is not convenient and >> error prone, and does not address the other goals anyway. > > There's all manner of odd things in Provides. > Provides: jpackage(foo) = 1.0-1jpp > Would fit right in :-) > So, you rather "abuse" (in you words) the Provides tag? That makes no sense and it does not attain most of the goals above. With changes to future RPM and Yum releases we could do things based on other tags like Group and so one. It is just not available yet. Regards, Fernando From fnasser at redhat.com Fri Jan 12 16:48:12 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 12 Jan 2007 11:48:12 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <200701121049.11980.jkeating@redhat.com> References: <45A6BF03.2000303@redhat.com> <200701112230.35156.jkeating@redhat.com> <45A7AB84.2090808@redhat.com> <200701121049.11980.jkeating@redhat.com> Message-ID: <45A7BBCC.4030507@redhat.com> Jesse Keating wrote: > On Friday 12 January 2007 10:38, Fernando Nasser wrote: >> We have been doing this for a few years now, it was never any problem. >> Now that the spec files are the same upstream we do an import and spend >> 1 minute or 2 with vimdiff to merge changelog entries and adjust the >> release tag. >> >> It is been very easy for us (Java team) and we are very happy with this >> process. > > So you aren't using cvs-import.sh to just import the srpm from upstream? Yes we are. >If > you are, that stomps on changes and replaces things. The only time you'd get > a conflict is if the same lines changed differently, but there could be a NEW > changelog entry in the Fedora CVS that doesn't exist upstream, upstream has a > new line that doesn't exist in Fedora, once cvs-import.sh is done, only the > upstream changelog entry will remain, the one in Fedora will be erased. > Yes, we have the changelog entries added for the respin everything cases, some old entries regarding changes that were made for GCJ compilation when it was not as perfect as it is today, some emergency local fixes doen during release times that were incorporated upstream a few days later. If this is deemed not important we can stopp merging them. We will still add our '.N' release number to the release tag and add a changelog entry saying that we have imported and are rebuilding it with AOT. BTW, so far we had to remove the Vendor and Distribution tags from the upstream spec file too, but that has been removed upstream to make it easier for the distros to import the packages. From jkeating at redhat.com Fri Jan 12 19:03:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 12 Jan 2007 14:03:48 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <45A7BBCC.4030507@redhat.com> References: <45A6BF03.2000303@redhat.com> <200701121049.11980.jkeating@redhat.com> <45A7BBCC.4030507@redhat.com> Message-ID: <200701121403.48575.jkeating@redhat.com> On Friday 12 January 2007 11:48, Fernando Nasser wrote: > Yes, we have the changelog entries added for the respin everything > cases, some old entries regarding changes that were made for GCJ > compilation when it was not as perfect as it is today, some emergency > local fixes doen during release times that were incorporated upstream a > few days later. ?If this is deemed not important we can stopp merging them. > > We will still add our '.N' release number to the release tag and add a > changelog entry saying that we have imported and are rebuilding it with > AOT. > > BTW, so far we had to remove the Vendor and Distribution tags from the > upstream spec file too, but that has been removed upstream to make it > easier for the distros to import the packages. I think adopting a work method that doesn't stomp local changes is very important, including adding an entry about importing from upstream for the build. I still don't like "jpp" being there, however I suppose I can live with it, provided others on the packaging committee can too, and we create a special case for it (ICK). -- 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 fnasser at redhat.com Fri Jan 12 19:43:23 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 12 Jan 2007 14:43:23 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <200701121403.48575.jkeating@redhat.com> References: <45A6BF03.2000303@redhat.com> <200701121049.11980.jkeating@redhat.com> <45A7BBCC.4030507@redhat.com> <200701121403.48575.jkeating@redhat.com> Message-ID: <45A7E4DB.5090102@redhat.com> Jesse Keating wrote: > On Friday 12 January 2007 11:48, Fernando Nasser wrote: >> Yes, we have the changelog entries added for the respin everything >> cases, some old entries regarding changes that were made for GCJ >> compilation when it was not as perfect as it is today, some emergency >> local fixes doen during release times that were incorporated upstream a >> few days later. If this is deemed not important we can stopp merging them. >> >> We will still add our '.N' release number to the release tag and add a >> changelog entry saying that we have imported and are rebuilding it with >> AOT. >> >> BTW, so far we had to remove the Vendor and Distribution tags from the >> upstream spec file too, but that has been removed upstream to make it >> easier for the distros to import the packages. > > I think adopting a work method that doesn't stomp local changes is very > important, including adding an entry about importing from upstream for the > build. > Oh yeah, we are very careful to preserve things that have been added for one reason or the other. That is why we don't blindly import the upstream releases (it could be even scripted). It actually becomes an opportunity to remove some GCJ hack that is no longer necessary, to check if some fix was made locally and not properly incorporated upstream (both packaging and in the software code itself) etc. People that have been doing this seem happy, but again I rather not speak for them. Speak up guys! > I still don't like "jpp" being there, however I suppose I can live with it, > provided others on the packaging committee can too, and we create a special > case for it (ICK). > That would be the ideal scenario at the moment. I believe we will have other more important cleanups to do as we go through the review process. For instance, it was recently proposed that only files into certain directories should be specified as file dependencies. I don't think it become a rule but we can try and restrict to that set if possible. Also, check if all spec files use the proper macros to refer to things like rm always, see if the new rules for Obsoletes work within this set etc. That does not mean that we should not be very attentive to the new RPM project and try to include things there that would make it unnecessary. And once those things are available ask for the proper UI changes in Yum too. I don't think this is the only case where we are circumventing some missing RPM feature that exists either because nobody thought of it or because it is a new need that came to be. Cheers, Fernando From a.badger at gmail.com Fri Jan 12 19:45:50 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 12 Jan 2007 11:45:50 -0800 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <4001.192.54.193.51.1168597292.squirrel@rousalka.dyndns.org> References: <4001.192.54.193.51.1168597292.squirrel@rousalka.dyndns.org> Message-ID: <1168631150.24389.6.camel@localhost.localdomain> On Fri, 2007-01-12 at 11:21 +0100, Nicolas Mailhot wrote: > Le Ven 12 janvier 2007 05:25, Toshio Kuratomi a ?crit : > > > Not every upstream agrees with the > > downstream. Not every upstream has the same time frame for updates as > > downstream. We will carry local patches and changes at some point. > > Fernando for example is part of the jpackage commiters. He can get fixes > upstream fast (as long as they're actual fixes, not quick hacks that break > other java packages). > > The number of jpackage commiters is small, they trust each other, you > don't have the long Fedora procedures designed to get occasional packagers > in line. Fedora won't have to wait for JPP, most often JPP will have to > wait for changes to propagate @fedora But we have a problem in that the jpackage maintainers and the Fedora maintainers won't always be the same. There may be some Fedora maintainers that aren't interested in participating in jpackage at all. If FESCo mandated that all java packages have to go through jpackage before entering Fedora that might address this issue. Is that what we want to propose? -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 Fri Jan 12 20:27:51 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 12 Jan 2007 14:27:51 -0600 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <200701121403.48575.jkeating@redhat.com> References: <45A6BF03.2000303@redhat.com> <200701121049.11980.jkeating@redhat.com> <45A7BBCC.4030507@redhat.com> <200701121403.48575.jkeating@redhat.com> Message-ID: <1168633671.8018.13.camel@localhost.localdomain> On Fri, 2007-01-12 at 14:03 -0500, Jesse Keating wrote: > On Friday 12 January 2007 11:48, Fernando Nasser wrote: > > Yes, we have the changelog entries added for the respin everything > > cases, some old entries regarding changes that were made for GCJ > > compilation when it was not as perfect as it is today, some emergency > > local fixes doen during release times that were incorporated upstream a > > few days later. If this is deemed not important we can stopp merging them. > > > > We will still add our '.N' release number to the release tag and add a > > changelog entry saying that we have imported and are rebuilding it with > > AOT. > > > > BTW, so far we had to remove the Vendor and Distribution tags from the > > upstream spec file too, but that has been removed upstream to make it > > easier for the distros to import the packages. > > I think adopting a work method that doesn't stomp local changes is very > important, including adding an entry about importing from upstream for the > build. > > I still don't like "jpp" being there, however I suppose I can live with it, > provided others on the packaging committee can too, and we create a special > case for it (ICK). I really don't like it. To be blunt, the arguments for keeping it seem to be "Because we waaaaaaaant it." It really doesn't serve a useful purpose. Release should be for tagging the build number of a package, with the exception of the dist tag, which identifies the distribution that a package is built for. "jpp" is irrelevant in both contexts, as these are Fedora packages, in a Fedora repository. ~spot From fnasser at redhat.com Fri Jan 12 20:35:10 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 12 Jan 2007 15:35:10 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <1168631150.24389.6.camel@localhost.localdomain> References: <4001.192.54.193.51.1168597292.squirrel@rousalka.dyndns.org> <1168631150.24389.6.camel@localhost.localdomain> Message-ID: <45A7F0FE.7090901@redhat.com> Toshio Kuratomi wrote: > On Fri, 2007-01-12 at 11:21 +0100, Nicolas Mailhot wrote: >> Le Ven 12 janvier 2007 05:25, Toshio Kuratomi a ?crit : >> >>> Not every upstream agrees with the >>> downstream. Not every upstream has the same time frame for updates as >>> downstream. We will carry local patches and changes at some point. >> Fernando for example is part of the jpackage commiters. He can get fixes >> upstream fast (as long as they're actual fixes, not quick hacks that break >> other java packages). >> >> The number of jpackage commiters is small, they trust each other, you >> don't have the long Fedora procedures designed to get occasional packagers >> in line. Fedora won't have to wait for JPP, most often JPP will have to >> wait for changes to propagate @fedora > > But we have a problem in that the jpackage maintainers and the Fedora > maintainers won't always be the same. There may be some Fedora > maintainers that aren't interested in participating in jpackage at all. > > If FESCo mandated that all java packages have to go through jpackage > before entering Fedora that might address this issue. Is that what we > want to propose? > Do we really have to mandate that? I'd rather let people use good judgment on that, there are already incentives to do it that way. A suggestion/recommendation perhaps? As any Java package has to inter-operate (most probably) with the already existing ones, it will be a JPackage-compatible package anyway. Most people will do it upstream to get help on specific Java issues and discuss it with other people who deal with Java-specific packaging issues. For the few cases that the developer just want to contribute directly to Fedora, people from the Java team can just do the reverse import and propagate it upstream. That way it get reviewed for Java-specific things, gets extra testing and we can always use the feedback or even the upstream fixes and file in Fedora Bugzilla (so the maintainer can incorporate them). BTW, our Bugzilla and the JPackage Bugzilla repos are already linked. But I agree that is much easier to just contribute the package there, incorporate any Java specific suggestions and ask for an import into Fedora. From fnasser at redhat.com Fri Jan 12 20:42:53 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 12 Jan 2007 15:42:53 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <1168633671.8018.13.camel@localhost.localdomain> References: <45A6BF03.2000303@redhat.com> <200701121049.11980.jkeating@redhat.com> <45A7BBCC.4030507@redhat.com> <200701121403.48575.jkeating@redhat.com> <1168633671.8018.13.camel@localhost.localdomain> Message-ID: <45A7F2CD.6040300@redhat.com> Tom 'spot' Callaway wrote: > On Fri, 2007-01-12 at 14:03 -0500, Jesse Keating wrote: >> On Friday 12 January 2007 11:48, Fernando Nasser wrote: >>> Yes, we have the changelog entries added for the respin everything >>> cases, some old entries regarding changes that were made for GCJ >>> compilation when it was not as perfect as it is today, some emergency >>> local fixes doen during release times that were incorporated upstream a >>> few days later. If this is deemed not important we can stopp merging them. >>> >>> We will still add our '.N' release number to the release tag and add a >>> changelog entry saying that we have imported and are rebuilding it with >>> AOT. >>> >>> BTW, so far we had to remove the Vendor and Distribution tags from the >>> upstream spec file too, but that has been removed upstream to make it >>> easier for the distros to import the packages. >> I think adopting a work method that doesn't stomp local changes is very >> important, including adding an entry about importing from upstream for the >> build. >> >> I still don't like "jpp" being there, however I suppose I can live with it, >> provided others on the packaging committee can too, and we create a special >> case for it (ICK). > > I really don't like it. To be blunt, the arguments for keeping it seem > to be "Because we waaaaaaaant it." > That is not fair. Since the old thread people have been explaining why they need certain features. That is how the original goals were created in the first place, based on these discussions. > It really doesn't serve a useful purpose. Release should be for tagging > the build number of a package, with the exception of the dist tag, which > identifies the distribution that a package is built for. "jpp" is > irrelevant in both contexts, as these are Fedora packages, in a Fedora > repository. > The jpp is very similar to the dist tag, it serves an identification purpose. The dist tag tells that that package is a variation of the same release in other o.s. releases, while the jpp versions tells that package is a variation of that jpp release. From mwringe at redhat.com Fri Jan 12 20:55:35 2007 From: mwringe at redhat.com (Matt Wringe) Date: Fri, 12 Jan 2007 15:55:35 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <1168633671.8018.13.camel@localhost.localdomain> References: <45A6BF03.2000303@redhat.com> <200701121049.11980.jkeating@redhat.com> <45A7BBCC.4030507@redhat.com> <200701121403.48575.jkeating@redhat.com> <1168633671.8018.13.camel@localhost.localdomain> Message-ID: <1168635335.28959.240.camel@toque.toronto.redhat.com> On Fri, 2007-01-12 at 14:27 -0600, Tom 'spot' Callaway wrote: > On Fri, 2007-01-12 at 14:03 -0500, Jesse Keating wrote: > > On Friday 12 January 2007 11:48, Fernando Nasser wrote: > > > Yes, we have the changelog entries added for the respin everything > > > cases, some old entries regarding changes that were made for GCJ > > > compilation when it was not as perfect as it is today, some emergency > > > local fixes doen during release times that were incorporated upstream a > > > few days later. If this is deemed not important we can stopp merging them. > > > > > > We will still add our '.N' release number to the release tag and add a > > > changelog entry saying that we have imported and are rebuilding it with > > > AOT. > > > > > > BTW, so far we had to remove the Vendor and Distribution tags from the > > > upstream spec file too, but that has been removed upstream to make it > > > easier for the distros to import the packages. > > > > I think adopting a work method that doesn't stomp local changes is very > > important, including adding an entry about importing from upstream for the > > build. > > > > I still don't like "jpp" being there, however I suppose I can live with it, > > provided others on the packaging committee can too, and we create a special > > case for it (ICK). > > I really don't like it. To be blunt, the arguments for keeping it seem > to be "Because we waaaaaaaant it." > > It really doesn't serve a useful purpose. Release should be for tagging > the build number of a package, with the exception of the dist tag, which > identifies the distribution that a package is built for. "jpp" is > irrelevant in both contexts, as these are Fedora packages, in a Fedora > repository. I would have to disagree, these are not Fedora packages in a Fedora repository, but rather jpp packages in a Fedora repository. This is exactly the distinction we want to make by including the 'jpp'. From tcallawa at redhat.com Fri Jan 12 20:58:46 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 12 Jan 2007 14:58:46 -0600 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <1168635335.28959.240.camel@toque.toronto.redhat.com> References: <45A6BF03.2000303@redhat.com> <200701121049.11980.jkeating@redhat.com> <45A7BBCC.4030507@redhat.com> <200701121403.48575.jkeating@redhat.com> <1168633671.8018.13.camel@localhost.localdomain> <1168635335.28959.240.camel@toque.toronto.redhat.com> Message-ID: <1168635526.8018.19.camel@localhost.localdomain> On Fri, 2007-01-12 at 15:55 -0500, Matt Wringe wrote: > I would have to disagree, these are not Fedora packages in a Fedora > repository, but rather jpp packages in a Fedora repository. This is > exactly the distinction we want to make by including the 'jpp'. I think this is a point on which I would firmly disagree. If it is part of Fedora, then it is a Fedora package. ~spot From pcheung at redhat.com Fri Jan 12 20:57:05 2007 From: pcheung at redhat.com (Permaine Cheung) Date: Fri, 12 Jan 2007 15:57:05 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <1168633671.8018.13.camel@localhost.localdomain> References: <45A6BF03.2000303@redhat.com> <200701121049.11980.jkeating@redhat.com> <45A7BBCC.4030507@redhat.com> <200701121403.48575.jkeating@redhat.com> <1168633671.8018.13.camel@localhost.localdomain> Message-ID: <45A7F621.5090602@redhat.com> Suppose we have a packaging issue (e.g. file not placed in a proper location) in java-foo-1.0-1jpp, which it's fixed in java-foo-1.0-2jpp, without the jpp release info, we won't be able to tell if that affects our java-foo package or not. If the jpp version is not kept in the package name, then we may have to spend more time on investigating problems arised from other packages depending on java-foo-1.0-1jpp. On the other hand, if we know our package is 1jpp version behind, we could have tried updating java-foo in the first place and solve the problem faster. Permaine Tom 'spot' Callaway wrote: >On Fri, 2007-01-12 at 14:03 -0500, Jesse Keating wrote: > > >>On Friday 12 January 2007 11:48, Fernando Nasser wrote: >> >> >>>Yes, we have the changelog entries added for the respin everything >>>cases, some old entries regarding changes that were made for GCJ >>>compilation when it was not as perfect as it is today, some emergency >>>local fixes doen during release times that were incorporated upstream a >>>few days later. If this is deemed not important we can stopp merging them. >>> >>>We will still add our '.N' release number to the release tag and add a >>>changelog entry saying that we have imported and are rebuilding it with >>>AOT. >>> >>>BTW, so far we had to remove the Vendor and Distribution tags from the >>>upstream spec file too, but that has been removed upstream to make it >>>easier for the distros to import the packages. >>> >>> >>I think adopting a work method that doesn't stomp local changes is very >>important, including adding an entry about importing from upstream for the >>build. >> >>I still don't like "jpp" being there, however I suppose I can live with it, >>provided others on the packaging committee can too, and we create a special >>case for it (ICK). >> >> > >I really don't like it. To be blunt, the arguments for keeping it seem >to be "Because we waaaaaaaant it." > >It really doesn't serve a useful purpose. Release should be for tagging >the build number of a package, with the exception of the dist tag, which >identifies the distribution that a package is built for. "jpp" is >irrelevant in both contexts, as these are Fedora packages, in a Fedora >repository. > >~spot > >-- >Fedora-packaging mailing list >Fedora-packaging at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-packaging > > From tcallawa at redhat.com Fri Jan 12 22:01:36 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 12 Jan 2007 16:01:36 -0600 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <45A7F621.5090602@redhat.com> References: <45A6BF03.2000303@redhat.com> <200701121049.11980.jkeating@redhat.com> <45A7BBCC.4030507@redhat.com> <200701121403.48575.jkeating@redhat.com> <1168633671.8018.13.camel@localhost.localdomain> <45A7F621.5090602@redhat.com> Message-ID: <1168639296.8018.33.camel@localhost.localdomain> On Fri, 2007-01-12 at 15:57 -0500, Permaine Cheung wrote: > Suppose we have a packaging issue (e.g. file not placed in a proper > location) in java-foo-1.0-1jpp, which it's fixed in java-foo-1.0-2jpp, > without the jpp release info, we won't be able to tell if that affects > our java-foo package or not. If the jpp version is not kept in the > package name, then we may have to spend more time on investigating > problems arised from other packages depending on java-foo-1.0-1jpp. On > the other hand, if we know our package is 1jpp version behind, we could > have tried updating java-foo in the first place and solve the problem > faster. To be fair, since jpp only updates release by integer increments (1, 2, 3, etc) and fedora permits subreleases (1.1, 1.2), you could simply look at the release field to determine ordering and hierarchy. Say you have java-foo-1.0-1.1 in Fedora, and you fix a bug in java-foo-1.0-2jpp, then java-foo-1.0-2jpp is newer, and you know the Fedora package (1.0-1.1) is derived from the 1jpp release. As Fedora makes changes (as needed), they only bump the subrevision (1.2, 1.3, so on). I've spoken to Fernando, and he pointed out some uses for the jpp tag which had not previously been raised (or at least, I missed them, and I don't see them listed in Toshio's document): The Red Hat Java folks are also using the jpp tag to help manage merging packages from JPackage into Fedora. It makes it much easier for them to key off that tag for mass rebuilds, set manipulation, selecting update patterns, etc. This is something that would fall under grouping functionality, they're trying to work around limitations in our packaging infrastructure that exist today. If we had grouping functionality, then they really wouldn't need the jpp tag. They could use that functionality to do their tasks instead of relying on the tag. So, here is my thought process: Long term: Do package grouping/categories in a sane manner, something not embedded in each package. When we have achieved that, drop the jpp tags from these packages. Short term: Recognize that the Fedora java packages are really a repo within a repo (imports from jpp). A big part of this is adhering to the versioning scheme that I described above, where jpp only does integer releases (1, 2, 3), and the Fedora packages derived from those JPP packages add a subrelease (1.1, 2.1, 3.1). This way, when we have the grouping issues managed, we can drop the jpp tag and still have clean upgrades between repos and a clear hierarchy (this Fedora package came from that jpp package). The Fedora packages would only ever increment the subrelease. This is permitted by the current guidelines. Given that we cannot solve the grouping issues currently, I think now we can make a special exception for the jpp packages (and ONLY the jpp packages), where they can continue to use the jpp tag in Fedora until we solve the grouping problem. When we have a workable alternative, then we will drop the jpp tag from use in Fedora. Thoughts? ~spot From jkeating at redhat.com Fri Jan 12 22:04:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 12 Jan 2007 17:04:43 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash =?iso-8859-1?q?--=09part_1?= Goals In-Reply-To: <1168639296.8018.33.camel@localhost.localdomain> References: <45A6BF03.2000303@redhat.com> <45A7F621.5090602@redhat.com> <1168639296.8018.33.camel@localhost.localdomain> Message-ID: <200701121704.43387.jkeating@redhat.com> On Friday 12 January 2007 17:01, Tom 'spot' Callaway wrote: > Given that we cannot solve the grouping issues currently, I think now we > can make a special exception for the jpp packages (and ONLY the jpp > packages), where they can continue to use the jpp tag in Fedora until we > solve the grouping problem. When we have a workable alternative, then we > will drop the jpp tag from use in Fedora. > > Thoughts? I still don't like special cases, but I can live with this, so long as actual attempts at fixing this long term are being made. -- 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 a.badger at gmail.com Fri Jan 12 22:15:50 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 12 Jan 2007 14:15:50 -0800 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <45A7F621.5090602@redhat.com> References: <45A6BF03.2000303@redhat.com> <200701121049.11980.jkeating@redhat.com> <45A7BBCC.4030507@redhat.com> <200701121403.48575.jkeating@redhat.com> <1168633671.8018.13.camel@localhost.localdomain> <45A7F621.5090602@redhat.com> Message-ID: <1168640150.24970.31.camel@localhost.localdomain> On Fri, 2007-01-12 at 15:57 -0500, Permaine Cheung wrote: > Suppose we have a packaging issue (e.g. file not placed in a proper > location) in java-foo-1.0-1jpp, which it's fixed in java-foo-1.0-2jpp, > without the jpp release info, we won't be able to tell if that affects > our java-foo package or not. If the jpp version is not kept in the > package name, then we may have to spend more time on investigating > problems arised from other packages depending on java-foo-1.0-1jpp. On > the other hand, if we know our package is 1jpp version behind, we could > have tried updating java-foo in the first place and solve the problem > faster. There's no reason to have the jpp in there for this, though. Jesse Keating's proposal allows you to do this within the current guidelines: %{jppversion+1}.%{?dist}.y where jppversion = the numeric portion of the jpp tag, dist is the fedora dist tag and y is any minor release bumping you have to do because the jpp package needed to be updated with something else. You then know that recovering the jpp number from the fedora version is: 6.fc6 => 5jpp If you don't actually care about interleaving updates between Fedora and jpackage, you can even have: 5.fc6 => 5jpp -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 fnasser at redhat.com Fri Jan 12 22:18:23 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 12 Jan 2007 17:18:23 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <200701121704.43387.jkeating@redhat.com> References: <45A6BF03.2000303@redhat.com> <45A7F621.5090602@redhat.com> <1168639296.8018.33.camel@localhost.localdomain> <200701121704.43387.jkeating@redhat.com> Message-ID: <45A8092F.1020208@redhat.com> Jesse Keating wrote: > On Friday 12 January 2007 17:01, Tom 'spot' Callaway wrote: >> Given that we cannot solve the grouping issues currently, I think now we >> can make a special exception for the jpp packages (and ONLY the jpp >> packages), where they can continue to use the jpp tag in Fedora until we >> solve the grouping problem. When we have a workable alternative, then we >> will drop the jpp tag from use in Fedora. >> >> Thoughts? > > I still don't like special cases, but I can live with this, so long as actual > attempts at fixing this long term are being made. > Oh, I totally agree with that. I am advocating that the 'jpp' letters stay there only out of necessity, will be really pleased of getting rid of them when a more clean mechanism becomes available. Tom and I have been thinking about how this will work when the new goups functionality is in place and it appears to both of us that will be more than enough to attain all the goals. In the long run, a Njpp upstream version will just become N.1 in Fedora when imported. We will always know what the last sync point was and the groups mechanism will take care of the rest. P.S.: We need some command line additions to both rpm and yum. The rpm one will probably be available as it makes sense to expose the new group functionality (besides programatically). We may have to contribute patches to yum ourselves though, which we may need for other reasons anyway. From a.badger at gmail.com Fri Jan 12 22:25:12 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 12 Jan 2007 14:25:12 -0800 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <1168635526.8018.19.camel@localhost.localdomain> References: <45A6BF03.2000303@redhat.com> <200701121049.11980.jkeating@redhat.com> <45A7BBCC.4030507@redhat.com> <200701121403.48575.jkeating@redhat.com> <1168633671.8018.13.camel@localhost.localdomain> <1168635335.28959.240.camel@toque.toronto.redhat.com> <1168635526.8018.19.camel@localhost.localdomain> Message-ID: <1168640713.24970.37.camel@localhost.localdomain> On Fri, 2007-01-12 at 14:58 -0600, Tom 'spot' Callaway wrote: > On Fri, 2007-01-12 at 15:55 -0500, Matt Wringe wrote: > > > I would have to disagree, these are not Fedora packages in a Fedora > > repository, but rather jpp packages in a Fedora repository. This is > > exactly the distinction we want to make by including the 'jpp'. > > I think this is a point on which I would firmly disagree. If it is part > of Fedora, then it is a Fedora package. > +1 I want to address the issues you guys have trying to make it easy to sync packages between jpackage and Fedora but the idea that a package in our repository is actually a jpackage package is just plain wrong. jpackage is a cross-distro repository, Fedora is a distro. The goals are different. The requirements of each are different. The packages can largely be the same, but once in a while there will be things that require local customization. We don't just ship upstream jpackage. We value add and integrate them with Fedora specifics where appropriate. -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 Fri Jan 12 22:44:21 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 12 Jan 2007 14:44:21 -0800 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <45A8092F.1020208@redhat.com> References: <45A6BF03.2000303@redhat.com> <45A7F621.5090602@redhat.com> <1168639296.8018.33.camel@localhost.localdomain> <200701121704.43387.jkeating@redhat.com> <45A8092F.1020208@redhat.com> Message-ID: <1168641861.24970.48.camel@localhost.localdomain> On Fri, 2007-01-12 at 17:18 -0500, Fernando Nasser wrote: > Jesse Keating wrote: > > On Friday 12 January 2007 17:01, Tom 'spot' Callaway wrote: > >> Given that we cannot solve the grouping issues currently, I think now we > >> can make a special exception for the jpp packages (and ONLY the jpp > >> packages), where they can continue to use the jpp tag in Fedora until we > >> solve the grouping problem. When we have a workable alternative, then we > >> will drop the jpp tag from use in Fedora. > >> > >> Thoughts? > > > > I still don't like special cases, but I can live with this, so long as actual > > attempts at fixing this long term are being made. > > > > Oh, I totally agree with that. I am advocating that the 'jpp' letters > stay there only out of necessity, will be really pleased of getting rid > of them when a more clean mechanism becomes available. > > Tom and I have been thinking about how this will work when the new goups > functionality is in place and it appears to both of us that will be more > than enough to attain all the goals. > > In the long run, a Njpp upstream version will just become N.1 in Fedora > when imported. We will always know what the last sync point was and the > groups mechanism will take care of the rest. > > P.S.: We need some command line additions to both rpm and yum. The rpm > one will probably be available as it makes sense to expose the new group > functionality (besides programatically). We may have to contribute > patches to yum ourselves though, which we may need for other reasons anyway. I like the sound of this as long as we agree on what the goals are for grouping. What functionality do you need to enable? What commandline switches do you need yum and rpm to provide? Rpm doesn't figure into the long-term grouping strategy at all so everything will probably be done at a higher level. -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 vivekl at redhat.com Sat Jan 13 02:45:39 2007 From: vivekl at redhat.com (Vivek Lakshmanan) Date: Fri, 12 Jan 2007 21:45:39 -0500 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <1168639296.8018.33.camel@localhost.localdomain> References: <45A6BF03.2000303@redhat.com> <200701121049.11980.jkeating@redhat.com> <45A7BBCC.4030507@redhat.com> <200701121403.48575.jkeating@redhat.com> <1168633671.8018.13.camel@localhost.localdomain> <45A7F621.5090602@redhat.com> <1168639296.8018.33.camel@localhost.localdomain> Message-ID: <1168656339.2562.5.camel@topcat.toronto.redhat.com> On Fri, 2007-01-12 at 16:01 -0600, Tom 'spot' Callaway wrote: > Given that we cannot solve the grouping issues currently, I think now we > can make a special exception for the jpp packages (and ONLY the jpp > packages), where they can continue to use the jpp tag in Fedora until we > solve the grouping problem. When we have a workable alternative, then we > will drop the jpp tag from use in Fedora. > I think this is an excellent compromise. Has something been set in motion regarding grouping already? If so, a link or two would be much appreciated... Thanks, Vivek From a.badger at gmail.com Sat Jan 13 10:11:16 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 13 Jan 2007 02:11:16 -0800 Subject: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals In-Reply-To: <1168656339.2562.5.camel@topcat.toronto.redhat.com> References: <45A6BF03.2000303@redhat.com> <200701121049.11980.jkeating@redhat.com> <45A7BBCC.4030507@redhat.com> <200701121403.48575.jkeating@redhat.com> <1168633671.8018.13.camel@localhost.localdomain> <45A7F621.5090602@redhat.com> <1168639296.8018.33.camel@localhost.localdomain> <1168656339.2562.5.camel@topcat.toronto.redhat.com> Message-ID: <1168683077.24970.59.camel@localhost.localdomain> On Fri, 2007-01-12 at 21:45 -0500, Vivek Lakshmanan wrote: > On Fri, 2007-01-12 at 16:01 -0600, Tom 'spot' Callaway wrote: > > Given that we cannot solve the grouping issues currently, I think now we > > can make a special exception for the jpp packages (and ONLY the jpp > > packages), where they can continue to use the jpp tag in Fedora until we > > solve the grouping problem. When we have a workable alternative, then we > > will drop the jpp tag from use in Fedora. > > > I think this is an excellent compromise. Has something been set in > motion regarding grouping already? If so, a link or two would be much > appreciated... > There's this extremely uncooked page on the wiki: http://www.fedoraproject.org/wiki/Extras/SIGs/Comps/PackageGroupEnhancements It's mostly a summary of one thread that occurred a few months back. The basics are that the we want to deprecate the Group tag in the spec file but need to replace it with something. comps.xml can replace some uses of the Group tag but jeremy thinks that the design of comps won't lend itself to replacing Groups. An alternate format was put forth by Nicolas Mailhot which separated out categories and groups - Packagers can tag their packages with a variety of categories. Release creators can create a profile with groups that select categories and individual packages. I'm currently working on the package db and am planning on adding the ability to store category information in there. (It's not in the current db schema. If someone wants to work on adding it contact me.) Most tools aren't going to want to talk to the package db in order to retrieve this information, though, so at some point we'll have to decide how to pull the information out of the database for tools like yum to consume (a comps file, Nicolas's file format, etc.) -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 gauret at free.fr Sun Jan 14 10:03:01 2007 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 14 Jan 2007 11:03:01 +0100 Subject: [Fedora-packaging] Desktop files: "Application" category Message-ID: Hey there, A few months ago, desktop files packaging was discussed on fedora-extras-list: https://www.redhat.com/archives/fedora-extras-list/2006-October/msg00723.html This mail makes me think the Application category is deprecated, but on the official Packaging Guidelines page : http://fedoraproject.org/wiki/Packaging/Guidelines#desktop the sample still has the Application Category. So, should we add this category, even if it is not listed as a standard category in the spec ? (http://standards.freedesktop.org/menu-spec/latest/apa.html) Thanks, Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr L'exp?rience est quelquechose que l'on acquiert juste apr?s en avoir eu besoin. From gauret at free.fr Sun Jan 14 12:41:38 2007 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 14 Jan 2007 13:41:38 +0100 Subject: [Fedora-packaging] Re: Desktop files: "Application" category References: Message-ID: > This mail makes me think the Application category is deprecated, but on > the official Packaging Guidelines page : > http://fedoraproject.org/wiki/Packaging/Guidelines#desktop > the sample still has the Application Category. It seems that desktop-file-validate as of desktop-file-utils-0.12 in fc7 does not consider "Application" valid any more. $ desktop-file-validate /usr/share/applications/fedora- blobby.desktop /usr/share/applications/fedora-blobby.desktop: warning: The 'Application' category is not defined by the desktop entry specification. Please use one of "AudioVideo", "Audio", "Video", "Development", "Education", "Game", "Graphics", "Network", "Office", "Settings", "System", "Utility" instead (see bug 222547) The wiki page should be fixed then. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Les hommes perdent la sant? pour gagner de l'argent et, apr?s, d?pensent cet argent pour r?cup?rer la sant?." -- Dala? Lama From rdieter at math.unl.edu Sun Jan 14 13:55:46 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 14 Jan 2007 07:55:46 -0600 Subject: [Fedora-packaging] Re: Desktop files: "Application" category In-Reply-To: References: Message-ID: <45AA3662.1010703@math.unl.edu> Aurelien Bompard wrote: >> This mail makes me think the Application category is deprecated, but on >> the official Packaging Guidelines page : >> http://fedoraproject.org/wiki/Packaging/Guidelines#desktop >> the sample still has the Application Category. > > It seems that desktop-file-validate as of desktop-file-utils-0.12 in fc7 > does not consider "Application" valid any more. Right, it is deprecated and should no longer be used. -- Rex From rdieter at math.unl.edu Sun Jan 14 15:00:15 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 14 Jan 2007 09:00:15 -0600 Subject: [Fedora-packaging] Re: Desktop files: "Application" category In-Reply-To: References: Message-ID: <45AA457F.1090204@math.unl.edu> Aurelien Bompard wrote: >> This mail makes me think the Application category is deprecated, but on >> the official Packaging Guidelines page : >> http://fedoraproject.org/wiki/Packaging/Guidelines#desktop >> the sample still has the Application Category. > > It seems that desktop-file-validate as of desktop-file-utils-0.12 in fc7 > does not consider "Application" valid any more. Here's the authoritative list of Categories: http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-0.9.8.html#recognized-keys OK, I had promised a .desktop file guideline update/proposal, we can throw in a reference to this too. In the meantime, we had previously agreed that Applications was to no longer be used, I'll go remove it from the Guidelines (that was an oversight). -- Rex From rc040203 at freenet.de Tue Jan 16 15:29:12 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 16 Jan 2007 16:29:12 +0100 Subject: [Fedora-packaging] Missing todays meeting Message-ID: <1168961352.17228.14.camel@mccallum.corsepiu.local> Hi, Due to other obligations, I'll probably be missing today's FPC meeting. Ralf From tcallawa at redhat.com Tue Jan 16 19:45:58 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 16 Jan 2007 13:45:58 -0600 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 Message-ID: <1168976758.22112.11.camel@localhost.localdomain> As discussed in today's FPC meeting, I've made some changes to the Conflicts Draft Proposal to document some acceptable cases, add some additional valid file name conflict workarounds, and fix the wording here and there. FPC Members: Please vote on this draft via email, so we can get this in place well before the Core/Extras merge. As I wrote the draft, I vote +1. ;) http://fedoraproject.org/wiki/PackagingDrafts/Conflicts Thanks, ~spot From rdieter at math.unl.edu Tue Jan 16 20:18:58 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 16 Jan 2007 14:18:58 -0600 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: <1168976758.22112.11.camel@localhost.localdomain> References: <1168976758.22112.11.camel@localhost.localdomain> Message-ID: <45AD3332.7040509@math.unl.edu> Tom 'spot' Callaway wrote: > As discussed in today's FPC meeting, I've made some changes to the > Conflicts Draft Proposal to document some acceptable cases, add some > additional valid file name conflict workarounds, and fix the wording > here and there. > > FPC Members: Please vote on this draft via email, so we can get this in > place well before the Core/Extras merge. As I wrote the draft, I vote > +1. ;) > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts +1 -- Rex From jkeating at redhat.com Tue Jan 16 20:40:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 16 Jan 2007 15:40:21 -0500 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: <1168976758.22112.11.camel@localhost.localdomain> References: <1168976758.22112.11.camel@localhost.localdomain> Message-ID: <200701161540.21813.jkeating@redhat.com> On Tuesday 16 January 2007 14:45, Tom 'spot' Callaway wrote: > As discussed in today's FPC meeting, I've made some changes to the > Conflicts Draft Proposal to document some acceptable cases, add some > additional valid file name conflict workarounds, and fix the wording > here and there. > > FPC Members: Please vote on this draft via email, so we can get this in > place well before the Core/Extras merge. As I wrote the draft, I vote > +1. ;) > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts It was brought up that since RHEL is based on Fedora releases, and RHEL does crazy things like support RHEL3 to RHEL5 upgrades, it is reasonable to have conflicts information in a Fedora package that dates a little farther back than the latest supported Fedora release, since we're trying to use these packages and guidelines for RHEL 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 tibbs at math.uh.edu Tue Jan 16 20:48:04 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Jan 2007 14:48:04 -0600 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: <1168976758.22112.11.camel@localhost.localdomain> References: <1168976758.22112.11.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom 'spot' Callaway writes: TC> http://fedoraproject.org/wiki/PackagingDrafts/Conflicts A few comments: I don't think that we should allow any implicit package conflicts. Do we need to make a hard rule that unresolvable conflicts must at least be explicit? In other words, should it be a bug when any packages conflict without explicitly using Conflicts:? And should the newer one conflict with the older one, or should they both be fixed to explicitly conflict with each other? Do we need to note under "Optional Functionality" that the Conflicts: should go away when the package being conflicted with is in the repository and the oldest possible version in a particular distro release is new enough not to conflict? This would get rid of many of the conflicts that glibc has. Additionally, do we need to add something to indicate that glibc's versioned conflict with glibc-devel should instead be done with a versioned requirement in glibc-devel? I guess the general wards against Conflicts: cover this case, but a specific note may be of use. - J< From rdieter at math.unl.edu Tue Jan 16 20:49:36 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 16 Jan 2007 14:49:36 -0600 Subject: [Fedora-packaging] DesktopFiles proposal Message-ID: <45AD3A60.9070602@math.unl.edu> http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles Motivations for updating the existing guideline: * reference desktop-entry-spec, including adding a SHOULD/MUST to comply with it. * Make it clear usage of desktop-file-install is not mandatory, but only required if you need to manually manipulate apps' .desktop file or to install a previously lacking one. * update examples: mention --add-category/--remove-category modify an already-installed .desktop file (e.g. moving it from %_datadir/applnk// to %{_datadir}/applications ) From tibbs at math.uh.edu Tue Jan 16 20:50:00 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Jan 2007 14:50:00 -0600 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: References: <1168976758.22112.11.camel@localhost.localdomain> Message-ID: >>>>> "JLT" == Jason L Tibbitts writes: JLT> I don't think that we should allow any implicit package JLT> Do we need to note under "Optional Functionality" that the JLT> Conflicts: should go away when the package being conflicted with JLT> is in the repository and the oldest possible version in a JLT> particular distro release is new enough not to conflict? This JLT> would get rid of many of the conflicts that glibc has. Umm, you know, it helps to hit reload so you're actually reading the correct version. - J< From tibbs at math.uh.edu Tue Jan 16 20:54:28 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Jan 2007 14:54:28 -0600 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: <200701161540.21813.jkeating@redhat.com> References: <1168976758.22112.11.camel@localhost.localdomain> <200701161540.21813.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> It was brought up that since RHEL is based on Fedora releases, and JK> RHEL does crazy things like support RHEL3 to RHEL5 upgrades, it is JK> reasonable to have conflicts information in a Fedora package that JK> dates a little farther back than the latest supported Fedora JK> release, since we're trying to use these packages and guidelines JK> for RHEL too. Does the upgrade case really matter, though? After all, we're talking about packages in the distro (Fedora or RHEL) and if you upgrade then you shouldn't have any in-distro packages older than what is in the distro you've just updated to. So packages needn't conflict with anything older than what's in the current distro release. Or is there some problem in ordering of upgrades here? - J< From tcallawa at redhat.com Tue Jan 16 21:00:09 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 16 Jan 2007 15:00:09 -0600 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: <200701161540.21813.jkeating@redhat.com> References: <1168976758.22112.11.camel@localhost.localdomain> <200701161540.21813.jkeating@redhat.com> Message-ID: <1168981209.22112.15.camel@localhost.localdomain> On Tue, 2007-01-16 at 15:40 -0500, Jesse Keating wrote: > On Tuesday 16 January 2007 14:45, Tom 'spot' Callaway wrote: > > As discussed in today's FPC meeting, I've made some changes to the > > Conflicts Draft Proposal to document some acceptable cases, add some > > additional valid file name conflict workarounds, and fix the wording > > here and there. > > > > FPC Members: Please vote on this draft via email, so we can get this in > > place well before the Core/Extras merge. As I wrote the draft, I vote > > +1. ;) > > > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > > It was brought up that since RHEL is based on Fedora releases, and RHEL does > crazy things like support RHEL3 to RHEL5 upgrades, it is reasonable to have > conflicts information in a Fedora package that dates a little farther back > than the latest supported Fedora release, since we're trying to use these > packages and guidelines for RHEL too. No, actually, RHEL doesn't support v3 -> v5 upgrades afaik. At least, RHEL has never previously supported upgrades across more than one major release. ~spot From jkeating at redhat.com Tue Jan 16 21:05:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 16 Jan 2007 16:05:01 -0500 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: <1168981209.22112.15.camel@localhost.localdomain> References: <1168976758.22112.11.camel@localhost.localdomain> <200701161540.21813.jkeating@redhat.com> <1168981209.22112.15.camel@localhost.localdomain> Message-ID: <200701161605.01603.jkeating@redhat.com> On Tuesday 16 January 2007 16:00, Tom 'spot' Callaway wrote: > No, actually, RHEL doesn't support v3 -> v5 upgrades afaik. At least, > RHEL has never previously supported upgrades across more than one major > release. Hrm, I'm getting conflicting information from those over the wall. However even still, RHEL4 -> RHEL5 is a pretty big jump, that's FC3~ -> FC6 to think about. I just think we could widen our horizon a bit on how long to keep a (valid) conflict in the spec file. -- 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 tcallawa at redhat.com Tue Jan 16 21:03:44 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 16 Jan 2007 15:03:44 -0600 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: References: <1168976758.22112.11.camel@localhost.localdomain> Message-ID: <1168981424.22112.19.camel@localhost.localdomain> On Tue, 2007-01-16 at 14:48 -0600, Jason L Tibbitts III wrote: > >>>>> "TC" == Tom 'spot' Callaway writes: > > TC> http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > > A few comments: > > I don't think that we should allow any implicit package conflicts. Do > we need to make a hard rule that unresolvable conflicts must at least > be explicit? In other words, should it be a bug when any packages > conflict without explicitly using Conflicts:? And should the newer > one conflict with the older one, or should they both be fixed to > explicitly conflict with each other? People have been filing bugs against my packages when they (accidentally) implicitly conflict with other packages in the repository. Given that it stops yum cold, I don't think we need to state that this is a bug (it obviously is). :) > Additionally, do we need to add something to indicate that glibc's > versioned conflict with glibc-devel should instead be done with a > versioned requirement in glibc-devel? I guess the general wards > against Conflicts: cover this case, but a specific note may be of use. Ehh, this is already against the guidelines (foo-devel needs to have a versioned requirement for foo) and when that is in place the Conflicts is totally unnecessary. I can spell it out if people want that. ~spot From tcallawa at redhat.com Tue Jan 16 21:14:48 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 16 Jan 2007 15:14:48 -0600 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: <200701161605.01603.jkeating@redhat.com> References: <1168976758.22112.11.camel@localhost.localdomain> <200701161540.21813.jkeating@redhat.com> <1168981209.22112.15.camel@localhost.localdomain> <200701161605.01603.jkeating@redhat.com> Message-ID: <1168982088.22112.22.camel@localhost.localdomain> On Tue, 2007-01-16 at 16:05 -0500, Jesse Keating wrote: > On Tuesday 16 January 2007 16:00, Tom 'spot' Callaway wrote: > > No, actually, RHEL doesn't support v3 -> v5 upgrades afaik. At least, > > RHEL has never previously supported upgrades across more than one major > > release. > > Hrm, I'm getting conflicting information from those over the wall. > > However even still, RHEL4 -> RHEL5 is a pretty big jump, that's FC3~ -> FC6 to > think about. I just think we could widen our horizon a bit on how long to > keep a (valid) conflict in the spec file. I don't think it would be a problem if the packager rationalized it with: # Needed for RHEL 4 -> RHEL 5 upgrade ~spot From Axel.Thimm at ATrpms.net Tue Jan 16 20:35:59 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 16 Jan 2007 21:35:59 +0100 Subject: [Fedora-packaging] Re: Conflicts Draft Proposal Round 2 In-Reply-To: <45AD3332.7040509@math.unl.edu> References: <1168976758.22112.11.camel@localhost.localdomain> <45AD3332.7040509@math.unl.edu> Message-ID: <20070116203559.GJ12544@neu.nirvana> On Tue, Jan 16, 2007 at 02:18:58PM -0600, Rex Dieter wrote: > Tom 'spot' Callaway wrote: > >As discussed in today's FPC meeting, I've made some changes to the > >Conflicts Draft Proposal to document some acceptable cases, add some > >additional valid file name conflict workarounds, and fix the wording > >here and there. > > > >FPC Members: Please vote on this draft via email, so we can get this in > >place well before the Core/Extras merge. As I wrote the draft, I vote > >+1. ;) > > > >http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > > +1 +1 (I can't imagine an example for the compat exemption, though, but there is obviously some precedent - perhaps it makes sense to bring it as an 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 Axel.Thimm at ATrpms.net Tue Jan 16 20:31:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 16 Jan 2007 21:31:08 +0100 Subject: [Fedora-packaging] Re: Missing todays meeting In-Reply-To: <1168961352.17228.14.camel@mccallum.corsepiu.local> References: <1168961352.17228.14.camel@mccallum.corsepiu.local> Message-ID: <20070116203108.GI12544@neu.nirvana> On Tue, Jan 16, 2007 at 04:29:12PM +0100, Ralf Corsepius wrote: > Due to other obligations, I'll probably be missing today's FPC meeting. Me, too, sorry for the late note. -- 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 Jan 16 23:57:39 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 16 Jan 2007 15:57:39 -0800 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: References: <1168976758.22112.11.camel@localhost.localdomain> Message-ID: <1168991859.3392.8.camel@localhost.localdomain> On Tue, 2007-01-16 at 14:48 -0600, Jason L Tibbitts III wrote: > >>>>> "TC" == Tom 'spot' Callaway writes: > > TC> http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > > A few comments: > > I don't think that we should allow any implicit package conflicts. Do > we need to make a hard rule that unresolvable conflicts must at least > be explicit? In other words, should it be a bug when any packages > conflict without explicitly using Conflicts:? And should the newer > one conflict with the older one, or should they both be fixed to > explicitly conflict with each other? I think implicit Conflicts should be disallowed. This is marginally related to the comment requirement (it isn't as clear to have a comment hanging out at a random place in the spec file as it is to have it attached to a Conflicts tag.) It also lets people know through rpm metadata that the issue has been looked at. Both packages should conflict as that lets both packagers correspond with their upstreams about the Conflict. It could be that the old package is the one that either should or has an upstream willing to, rename its files. -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 dlutter at redhat.com Wed Jan 17 03:29:09 2007 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 16 Jan 2007 19:29:09 -0800 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: <1168976758.22112.11.camel@localhost.localdomain> References: <1168976758.22112.11.camel@localhost.localdomain> Message-ID: <1169004549.2932.12.camel@localhost.localdomain> On Tue, 2007-01-16 at 13:45 -0600, Tom 'spot' Callaway wrote: > As discussed in today's FPC meeting, I've made some changes to the > Conflicts Draft Proposal to document some acceptable cases, add some > additional valid file name conflict workarounds, and fix the wording > here and there. > > FPC Members: Please vote on this draft via email, so we can get this in > place well before the Core/Extras merge. As I wrote the draft, I vote > +1. ;) > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts +1 David From rc040203 at freenet.de Wed Jan 17 04:10:06 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 17 Jan 2007 05:10:06 +0100 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: <1168976758.22112.11.camel@localhost.localdomain> References: <1168976758.22112.11.camel@localhost.localdomain> Message-ID: <1169007006.17228.53.camel@mccallum.corsepiu.local> On Tue, 2007-01-16 at 13:45 -0600, Tom 'spot' Callaway wrote: > As discussed in today's FPC meeting, I've made some changes to the > Conflicts Draft Proposal to document some acceptable cases, add some > additional valid file name conflict workarounds, and fix the wording > here and there. > > FPC Members: Please vote on this draft via email, so we can get this in > place well before the Core/Extras merge. As I wrote the draft, I vote > +1. ;) > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts This example is doesn't make sense: * Move the man pages into different sections in each package (e.g. man1/myapi.1.gz and man3/myapi.3.gz) man1 and man3 serve different purposes[1], therefore moving man-pages from man1 to man3 is not applicable nor advisable. +1 with the sentence above removed. Ralf [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREMANMANUALPAGES From tcallawa at redhat.com Wed Jan 17 04:59:52 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 16 Jan 2007 22:59:52 -0600 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: <1169007006.17228.53.camel@mccallum.corsepiu.local> References: <1168976758.22112.11.camel@localhost.localdomain> <1169007006.17228.53.camel@mccallum.corsepiu.local> Message-ID: <1169009992.22112.47.camel@localhost.localdomain> On Wed, 2007-01-17 at 05:10 +0100, Ralf Corsepius wrote: > On Tue, 2007-01-16 at 13:45 -0600, Tom 'spot' Callaway wrote: > > As discussed in today's FPC meeting, I've made some changes to the > > Conflicts Draft Proposal to document some acceptable cases, add some > > additional valid file name conflict workarounds, and fix the wording > > here and there. > > > > FPC Members: Please vote on this draft via email, so we can get this in > > place well before the Core/Extras merge. As I wrote the draft, I vote > > +1. ;) > > > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > > This example is doesn't make sense: > > > * Move the man pages into different sections in each package (e.g. > man1/myapi.1.gz and man3/myapi.3.gz) > > > man1 and man3 serve different purposes[1], therefore moving man-pages > from man1 to man3 is not applicable nor advisable. > > > +1 with the sentence above removed. Good point. Sentence removed. ~spot From rdieter at math.unl.edu Wed Jan 17 14:25:09 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 17 Jan 2007 08:25:09 -0600 Subject: [Fedora-packaging] LibtoolArchives, v0.3 Message-ID: <45AE31C5.5080602@math.unl.edu> http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives Motivation (AFAICT) The intent of the original guideline was to avoid problematic libtool archives1, those used in linking, not necessarily those used for loadable modules, plugins, etc... While .la files outside of $LD_LIBRARY_PATH SHOULD be ok to omit, (AFAIK) keeping them causes no harm either, so shouldn't be a MUST to remove. Problem is, there are quite a few software packages that require .la files for proper function (including some kde bits, though this is being worked on). Comments? -- Rex From enrico.scholz at informatik.tu-chemnitz.de Wed Jan 17 14:39:39 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 17 Jan 2007 15:39:39 +0100 Subject: [Fedora-packaging] LibtoolArchives, v0.3 In-Reply-To: <45AE31C5.5080602@math.unl.edu> (Rex Dieter's message of "Wed, 17 Jan 2007 08:25:09 -0600") References: <45AE31C5.5080602@math.unl.edu> Message-ID: <87wt3l7m50.fsf@fc5.bigo.ensc.de> rdieter at math.unl.edu (Rex Dieter) writes: > http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives > ... > Comments? | MUST: If .la libtool archives in $LD_LIBRARY_PATH2 cannot be excluded, | they MUST be included in -devel (with associated .so symlink). is wrong... it should be | MUST: If .la libtool archives in $LD_LIBRARY_PATH cannot be excluded, | they MUST be included in main-package but NOT in -devel. Enrico From rdieter at math.unl.edu Wed Jan 17 14:43:12 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 17 Jan 2007 08:43:12 -0600 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 References: <45AE31C5.5080602@math.unl.edu> <87wt3l7m50.fsf@fc5.bigo.ensc.de> Message-ID: Enrico Scholz wrote: > rdieter at math.unl.edu (Rex Dieter) writes: > >> http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives >> ... >> Comments? > > | MUST: If .la libtool archives in $LD_LIBRARY_PATH2 cannot be excluded, > | they MUST be included in -devel (with associated .so symlink). > > is wrong... it should be > > | MUST: If .la libtool archives in $LD_LIBRARY_PATH cannot be excluded, > | they MUST be included in main-package but NOT in -devel. Huh? .la libtool archives in LD_LIBRARY_PATH are those used for *linking*, so why not -devel? -- Rex From rdieter at math.unl.edu Wed Jan 17 14:49:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 17 Jan 2007 08:49:55 -0600 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: References: <45AE31C5.5080602@math.unl.edu> <87wt3l7m50.fsf@fc5.bigo.ensc.de> Message-ID: <45AE3793.9070107@math.unl.edu> Rex Dieter wrote: > Enrico Scholz wrote: > >> rdieter at math.unl.edu (Rex Dieter) writes: >> >>> http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives >>> ... >>> Comments? >> | MUST: If .la libtool archives in $LD_LIBRARY_PATH2 cannot be excluded, >> | they MUST be included in -devel (with associated .so symlink). >> >> is wrong... it should be >> >> | MUST: If .la libtool archives in $LD_LIBRARY_PATH cannot be excluded, >> | they MUST be included in main-package but NOT in -devel. > > Huh? .la libtool archives in LD_LIBRARY_PATH are those used for *linking*, > so why not -devel? I suppose a case could still exist where .la files are needed for runtime (though I can't think of any, now that kde is fixable), so we could reword this to leave it to the packager's discretion. -- Rex From enrico.scholz at informatik.tu-chemnitz.de Wed Jan 17 15:12:00 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 17 Jan 2007 16:12:00 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: (Rex Dieter's message of "Wed, 17 Jan 2007 08:43:12 -0600") References: <45AE31C5.5080602@math.unl.edu> <87wt3l7m50.fsf@fc5.bigo.ensc.de> Message-ID: <87sle97kn3.fsf@fc5.bigo.ensc.de> rdieter at math.unl.edu (Rex Dieter) writes: >>> http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives >>> ... >>> Comments? >> >> | MUST: If .la libtool archives in $LD_LIBRARY_PATH2 cannot be excluded, >> | they MUST be included in -devel (with associated .so symlink). >> >> is wrong... it should be >> >> | MUST: If .la libtool archives in $LD_LIBRARY_PATH cannot be excluded, >> | they MUST be included in main-package but NOT in -devel. > > Huh? .la libtool archives in LD_LIBRARY_PATH are those used for *linking*, > so why not -devel? E.g. /usr/lib/kde3/kded_kdeprintd.la contains | dependency_libs=' ... /usr/lib/libkio.la ... ' --> /usr/lib/libkio.la is needed at runtime and must be in a main package. Saying that packager has to decide on a case-by-case base does not help; e.g. when he ships 'libfoo.la' in -devel, a year later somebody else might create a module with "dependency_libs='/usr/lib/libfoo.la'" which would require 'libfoo.la' to be in a main-package. A rule like | MUST: a .la libtool archive MUST NOT list other .la archives in its | 'dependency_libs' list might be a solution, but I am not sure if this rule is complete. Enrico From rdieter at math.unl.edu Wed Jan 17 15:17:15 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 17 Jan 2007 09:17:15 -0600 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <87sle97kn3.fsf@fc5.bigo.ensc.de> References: <45AE31C5.5080602@math.unl.edu> <87wt3l7m50.fsf@fc5.bigo.ensc.de> <87sle97kn3.fsf@fc5.bigo.ensc.de> Message-ID: <45AE3DFB.7060406@math.unl.edu> Enrico Scholz wrote: >> Huh? .la libtool archives in LD_LIBRARY_PATH are those used for *linking*, >> so why not -devel? > > E.g. /usr/lib/kde3/kded_kdeprintd.la contains > > | dependency_libs=' ... /usr/lib/libkio.la ... ' > > --> /usr/lib/libkio.la is needed at runtime and must be in a main > package. Not necessarily. Just because something is listed as a dependency_lib, and it is missing, does not make loading it fail. (Try it, or trust me, *I* have, for kde bits anyway). Besides, did you miss my comment in the proposal that kde is fixable to not require .la files at runtime *at all*? (: > Saying that packager has to decide on a case-by-case base does not help; It's better than the status-quo of saying .la files MUST (always) be omitted. -- Rex From Axel.Thimm at ATrpms.net Wed Jan 17 15:27:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 17 Jan 2007 16:27:36 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <45AE31C5.5080602@math.unl.edu> References: <45AE31C5.5080602@math.unl.edu> Message-ID: <20070117152736.GJ26437@neu.nirvana> On Wed, Jan 17, 2007 at 08:25:09AM -0600, Rex Dieter wrote: > http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives > > Motivation > (AFAICT) The intent of the original guideline was to avoid problematic > libtool archives1, those used in linking, not necessarily those used for > loadable modules, plugins, etc... > > While .la files outside of $LD_LIBRARY_PATH SHOULD be ok to omit, > (AFAIK) keeping them causes no harm either, so shouldn't be a MUST to > remove. Problem is, there are quite a few software packages that require > .la files for proper function (including some kde bits, though this is > being worked on). > > > Comments? > > -- Rex > I think we should fix that upstream, we know the authors are willing to fix it, but they asked for some use case to demonstrate the problem. The biggest problem *.la inclusing/exclusion have cost are endless recurring discussions on working around the current state of affairs (deleting all, keeping all, deleting some, deleting some more, and still being surprised when kde or something else will pick up non-devel *.la functionality 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 Wed Jan 17 15:56:44 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 17 Jan 2007 09:56:44 -0600 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <20070117152736.GJ26437@neu.nirvana> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> Message-ID: <45AE473C.7050105@math.unl.edu> Axel Thimm wrote: > I think we should fix that upstream, we know the authors are willing > to fix it, but they asked for some use case to demonstrate the > problem. By upstream here, you mean libtool upstream, I assume. Yes, basically, they want someone else to fix it for them and write test-cases, which I doubt anyone here has time to do (me anyway). ): > The biggest problem *.la inclusing/exclusion have cost are endless > recurring discussions on working around the current state of affairs > (deleting all, keeping all, deleting some, deleting some more, and > still being surprised when kde or something else will pick up > non-devel *.la functionality etc.). AFAIK, the only unknown up to this point was kde, which I've found it is fixable (runtime, at least). I'm aware of no other cases where .la files are required for runtime function. -- Rex From enrico.scholz at informatik.tu-chemnitz.de Wed Jan 17 15:58:55 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 17 Jan 2007 16:58:55 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <45AE3DFB.7060406@math.unl.edu> (Rex Dieter's message of "Wed, 17 Jan 2007 09:17:15 -0600") References: <45AE31C5.5080602@math.unl.edu> <87wt3l7m50.fsf@fc5.bigo.ensc.de> <87sle97kn3.fsf@fc5.bigo.ensc.de> <45AE3DFB.7060406@math.unl.edu> Message-ID: <87odox7igw.fsf@fc5.bigo.ensc.de> rdieter at math.unl.edu (Rex Dieter) writes: >>> Huh? .la libtool archives in LD_LIBRARY_PATH are those used for *linking*, >>> so why not -devel? >> E.g. /usr/lib/kde3/kded_kdeprintd.la contains >> | dependency_libs=' ... /usr/lib/libkio.la ... ' >> --> /usr/lib/libkio.la is needed at runtime and must be in a main >> package. > > Not necessarily. Just because something is listed as a > dependency_lib, and it is missing, does not make loading it fail. > (Try it, or trust me, *I* have, for kde bits anyway). The decision whether loading fails or succeeds depends on the module, not the library. Your .la packaging proposal applies to the library ("MUST be included in -devel ") and because the use-cases of libraries can usually not be predicted you have to assume that loading will fail when listed .la files are not available. > Besides, did you miss my comment in the proposal that kde is fixable > to not require .la files at runtime *at all*? (: Current KDE is just a handy real-world example; I do not have time to search for example where loading requires dependency_libs instead of ELF's NEEDED entries. >> Saying that packager has to decide on a case-by-case base does not help; > > It's better than the status-quo of saying .la files MUST (always) be > omitted. Your proposal is not better: it will make reviewers cry when .la files are in main instead of -devel. IMO, a rule like ".la files MUST be always omitted, unless the package does not work else" is better than ".la files MUST be always in -devel". First rule can be checked by the packager/reviewer at review-request time. Latter rule might trigger problems years later with completely independent packages. Enrico From rdieter at math.unl.edu Wed Jan 17 16:04:28 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 17 Jan 2007 10:04:28 -0600 Subject: [Fedora-packaging] Re: Re: LibtoolArchives, v0.3 References: <45AE31C5.5080602@math.unl.edu> <87wt3l7m50.fsf@fc5.bigo.ensc.de> <87sle97kn3.fsf@fc5.bigo.ensc.de> <45AE3DFB.7060406@math.unl.edu> <87odox7igw.fsf@fc5.bigo.ensc.de> Message-ID: Enrico Scholz wrote: > rdieter at math.unl.edu (Rex Dieter) writes: > >>>> Huh? .la libtool archives in LD_LIBRARY_PATH are those used for >>>> *linking*, so why not -devel? >>> E.g. /usr/lib/kde3/kded_kdeprintd.la contains >>> | dependency_libs=' ... /usr/lib/libkio.la ... ' >>> --> /usr/lib/libkio.la is needed at runtime and must be in a main >>> package. >> >> Not necessarily. Just because something is listed as a >> dependency_lib, and it is missing, does not make loading it fail. >> (Try it, or trust me, *I* have, for kde bits anyway). > > The decision whether loading fails or succeeds depends on the module, > not the library. I'd argue that any such module is thus broken by design, since it includes undefined symbols, and should be fixed. >>> Saying that packager has to decide on a case-by-case base does not help; >> >> It's better than the status-quo of saying .la files MUST (always) be >> omitted. > > Your proposal is not better: it will make reviewers cry when .la files > are in main instead of -devel. I'm willing to compromise to include these bits in main (and not -devel) if that's what it takes to gain your support/vote. -- Rex From Axel.Thimm at ATrpms.net Wed Jan 17 16:06:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 17 Jan 2007 17:06:28 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <45AE473C.7050105@math.unl.edu> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> Message-ID: <20070117160628.GK26437@neu.nirvana> On Wed, Jan 17, 2007 at 09:56:44AM -0600, Rex Dieter wrote: > AFAIK, the only unknown up to this point was kde, which I've found it is > fixable (runtime, at least). I'm aware of no other cases where .la > files are required for runtime function. That's the main issue: Issuing packaging guidelines per package (groups) is wrong, some day some other package (group) will suddenly require the same handling and we're busted again. Or something different will come up, after all removing *.la diles is not an upstream action, but ours. E.g. what we're doing is papering over some issues we are creating and praying for not being caught by the next one. Makes me think whether what we think was fixed (a couple of dependencies less) was worth while, or whether we're just killing ourselves for being overzealous (which is not meant against Rex in any way, he's just trying to provide the best solution for the given situation). My proposal is to allow *.la files to live and kindly divert people crying too loud about it to assist upstream in fixing the issues. Don't forget that there are already patches for dealing with 95% of our issues available. -- 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 tcallawa at redhat.com Wed Jan 17 16:09:49 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 17 Jan 2007 10:09:49 -0600 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <20070117160628.GK26437@neu.nirvana> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> Message-ID: <1169050189.20121.1.camel@localhost.localdomain> On Wed, 2007-01-17 at 17:06 +0100, Axel Thimm wrote: > O > My proposal is to allow *.la files to live and kindly divert people > crying too loud about it to assist upstream in fixing the > issues. Don't forget that there are already patches for dealing with > 95% of our issues available. I'm really not trying to rehash this thread, but the original reason for nuking .la files was the nasty tendency they had of creating bogus (?) dependency spirals of doom. Am I wrong in remembering that? If I'm not wrong, has this been solved somehow? If this is indeed still the case, why would we want to bring them back? ~spot From rdieter at math.unl.edu Wed Jan 17 16:36:36 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 17 Jan 2007 10:36:36 -0600 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <1169050189.20121.1.camel@localhost.localdomain> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> Message-ID: <45AE5094.7000808@math.unl.edu> Tom 'spot' Callaway wrote: > On Wed, 2007-01-17 at 17:06 +0100, Axel Thimm wrote: >> O >> My proposal is to allow *.la files to live and kindly divert people >> crying too loud about it to assist upstream in fixing the >> issues. Don't forget that there are already patches for dealing with >> 95% of our issues available. > > I'm really not trying to rehash this thread, but the original reason for > nuking .la files was the nasty tendency they had of creating bogus (?) > dependency spirals of doom. Am I wrong in remembering that? If I'm not > wrong, has this been solved somehow? Nope, still an unsolved problem. > If this is indeed still the case, why would we want to bring them back? We we're not, the proposal is only changing the "MUST omit" to "SHOULD omit". Some packages (still) require .la files for linking (kde *cough*), I'm just hoping to codify that by saying when/if .la files are required, they SHOULD/MUST go in -devel. Maybe we just need to let bygones be bygones and leave the guideline as-is, and simply make exceptions (kdelibs, etc...) on a case-by-case basis. -- Rex From bugs.michael at gmx.net Wed Jan 17 17:04:06 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 17 Jan 2007 18:04:06 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <45AE5094.7000808@math.unl.edu> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <45AE5094.7000808@math.unl.edu> Message-ID: <20070117180406.46b2a2ee.bugs.michael@gmx.net> On Wed, 17 Jan 2007 10:36:36 -0600, Rex Dieter wrote: > > I'm really not trying to rehash this thread, but the original reason for > > nuking .la files was the nasty tendency they had of creating bogus (?) > > dependency spirals of doom. Am I wrong in remembering that? If I'm not > > wrong, has this been solved somehow? > > Nope, still an unsolved problem. Plus: creating compat-* packages becomes much more difficult whenever there are dependencies between .la files (such as the infamous absolute paths). On the contrary, properly named and versioned .so files can coexist nicely. From tcallawa at redhat.com Wed Jan 17 17:05:53 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 17 Jan 2007 11:05:53 -0600 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <45AE5094.7000808@math.unl.edu> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <45AE5094.7000808@math.unl.edu> Message-ID: <1169053553.20121.6.camel@localhost.localdomain> On Wed, 2007-01-17 at 10:36 -0600, Rex Dieter wrote: > Tom 'spot' Callaway wrote: > > On Wed, 2007-01-17 at 17:06 +0100, Axel Thimm wrote: > >> O > >> My proposal is to allow *.la files to live and kindly divert people > >> crying too loud about it to assist upstream in fixing the > >> issues. Don't forget that there are already patches for dealing with > >> 95% of our issues available. > > > > I'm really not trying to rehash this thread, but the original reason for > > nuking .la files was the nasty tendency they had of creating bogus (?) > > dependency spirals of doom. Am I wrong in remembering that? If I'm not > > wrong, has this been solved somehow? > > Nope, still an unsolved problem. > > > If this is indeed still the case, why would we want to bring them back? > > We we're not, the proposal is only changing the "MUST omit" to "SHOULD > omit". > > Some packages (still) require .la files for linking (kde *cough*), I'm > just hoping to codify that by saying when/if .la files are required, > they SHOULD/MUST go in -devel. > > Maybe we just need to let bygones be bygones and leave the guideline > as-is, and simply make exceptions (kdelibs, etc...) on a case-by-case basis. Well, then, I think I'm of the opinion that anything requiring .la files is a bug. I'd rather leave the guidelines as is, and consider any exception cases when all other technical options to resolve the bug have been exhausted. Opening this door, even just a teeny crack, will let bad packages slide right through. ~spot From rdieter at math.unl.edu Wed Jan 17 17:12:14 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 17 Jan 2007 11:12:14 -0600 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <1169053553.20121.6.camel@localhost.localdomain> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <45AE5094.7000808@math.unl.edu> <1169053553.20121.6.camel@localhost.localdomain> Message-ID: <45AE58EE.5060405@math.unl.edu> Tom 'spot' Callaway wrote: > Opening this door, even just a teeny crack, will let bad packages slide > right through. Agreed. I withdraw the proposal. -- Rex From notting at redhat.com Wed Jan 17 16:25:27 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 17 Jan 2007 11:25:27 -0500 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <45AE473C.7050105@math.unl.edu> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> Message-ID: <20070117162527.GB8563@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > AFAIK, the only unknown up to this point was kde, which I've found it is > fixable (runtime, at least). I'm aware of no other cases where .la > files are required for runtime function. gnucash has its own custom module system built on top of libltdl; it is very unhappy without them. It's probably hackable to work, but as there's already a branch on the trunk that ports it all to gmodule, I'm not that interested in looking at it outside of possibly backporting that branch. Bill From fnasser at redhat.com Wed Jan 17 21:23:49 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 17 Jan 2007 16:23:49 -0500 Subject: [Fedora-packaging] Java naming scheme Message-ID: <45AE93E5.8030900@redhat.com> Hi, I will try to summarize the findings so far. 1) We seem to agree that we want to make the following transformation on the release fields : 3jpp -> 3.1 in Fedora This will satisfy all our upgrade paths, as: 4.1 > 4jpp > 3.1 > 3jpp so one can always have the latest fixes. 2) Some would be agreeable to leaving the 'jpp' in there as a temporary measure, as what we really want is some Groups (or Categories) functionality that is not yet available. So, temporarely, 3jpp -> 3jpp.1 3) What do we need to get rid of the 'jpp' a) Query for the set of Java packages The rpm -qg (or rpm -q --group) command currently does not accept patterns If we could do 'rpm -qg "Java*"' we could add "Java/" to all "Group:" tags of all Java packages and that would work. I am trying to create a patch for that (which would be RPM patch #37 in Fedora) but I am encountering some difficulties as it is the first time I am looking at the rpm source code and I have been working with Java rather than C in the last years. P.S.: We would need a similar query functionality when Categories replace Groups. b) yum has already some group functionality (groupinstall, groupupdate, groupremove, groupinfo) that is based on an XML file that is kept in the repository. But the option --exclude only acts on file names, we need a --groupexclude. We already have a "Java" group, with only 2 packages on it: # yum groupinfo Java Loading "installonlyn" plugin Setting up Group Process Setting up repositories Group: Java Description: Support for running programs written in the Java programming language. Mandatory Packages: libgcj java-1.4.2-gcj-compat We could just make sure all Java packages are in the Java group to make use of the yum group functionality. We just need the --groupexclude. I will try and create a patch to add a '--groupexclude' as soon as I finish with the rpm one. P.S.: If we could get the fixes for 3a and 3b we could get rid of the 'jpp' immediately. Anyone that could help me with those? Fernando From Axel.Thimm at ATrpms.net Wed Jan 17 23:15:10 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 18 Jan 2007 00:15:10 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <1169050189.20121.1.camel@localhost.localdomain> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> Message-ID: <20070117231510.GE9816@neu.nirvana> On Wed, Jan 17, 2007 at 10:09:49AM -0600, Tom 'spot' Callaway wrote: > On Wed, 2007-01-17 at 17:06 +0100, Axel Thimm wrote: > > O > > My proposal is to allow *.la files to live and kindly divert people > > crying too loud about it to assist upstream in fixing the > > issues. Don't forget that there are already patches for dealing with > > 95% of our issues available. > > I'm really not trying to rehash this thread, but the original reason for > nuking .la files was the nasty tendency they had of creating bogus (?) > dependency spirals of doom. Am I wrong in remembering that? If I'm not > wrong, has this been solved somehow? Well, when I tried to hit the edge of the wedge into this back in October I asked | Revisting the root of evil. What exactly is wrong with not removing | all *.la files? There were tons of answers only not really on-topic for that question. I still think that the possible issues were overmagnified and the pain of carrying them outweighs the pain we've already have to go through. I also wonder how we manged to live with them previously and why other distributions haven't been eaten by the spiral of doom. So let me ask again: What's really that bad about including the current *.la files into devel by default (unless really needed in main packages) other than a couple more dependencies between *-devel packages and how bad are these "bloated" devel interdependencies? I'd really like to see people fix the issue upstream than trying to engineer the output (again: there are already patches obviously working for several cases, there is no need to rewrite libtool from scratch). Any statement on omitting which *.la files had to be revised a couple of months later, which is in the nature of working against upstream conventions. -- 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 Wed Jan 17 23:23:33 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 18 Jan 2007 00:23:33 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <20070117231510.GE9816@neu.nirvana> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <20070117231510.GE9816@neu.nirvana> Message-ID: <20070117232333.GG9816@neu.nirvana> On Thu, Jan 18, 2007 at 12:15:10AM +0100, Axel Thimm wrote: > [on keeping *.la files] > I still think that the possible issues were overmagnified > and the pain of carrying them outweighs the pain we've already have to > go through. Well, I meant the other way around, but I know you guessed that already ;) -- 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 bugs.michael at gmx.net Thu Jan 18 00:10:56 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 18 Jan 2007 01:10:56 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <20070117231510.GE9816@neu.nirvana> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <20070117231510.GE9816@neu.nirvana> Message-ID: <20070118011056.70cbe25c.bugs.michael@gmx.net> On Thu, 18 Jan 2007 00:15:10 +0100, Axel Thimm wrote: > So let me ask again: What's really that bad about including the > current *.la files into devel by default (unless really needed in main > packages) other than a couple more dependencies between *-devel > packages and how bad are these "bloated" devel interdependencies? Unfortunately, the "couple of more dependencies" is visible in the BuildRequires tree, too. It results in pretty much the opposite of trying to eliminate superfluous and redundant BR. You will find that packagers will be confronted again and again with missing BR which are only needed because of direct dependencies between .la files or changes within the libtool dep-chain. Stuff that comes and goes as packages in the chain change. Even worse than the "bloat" is when upstream developers modify their software, so that the .la dep-chain is changed, too (e.g. by adding or removing inter-library dependencies or by inserting bugs into the .la templates). IIRC, bugzilla has quite some tales to tell about such breakage. From Axel.Thimm at ATrpms.net Thu Jan 18 00:08:57 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 18 Jan 2007 01:08:57 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <20070118011056.70cbe25c.bugs.michael@gmx.net> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <20070117231510.GE9816@neu.nirvana> <20070118011056.70cbe25c.bugs.michael@gmx.net> Message-ID: <20070118000857.GH9816@neu.nirvana> On Thu, Jan 18, 2007 at 01:10:56AM +0100, Michael Schwendt wrote: > On Thu, 18 Jan 2007 00:15:10 +0100, Axel Thimm wrote: > > > So let me ask again: What's really that bad about including the > > current *.la files into devel by default (unless really needed in main > > packages) other than a couple more dependencies between *-devel > > packages and how bad are these "bloated" devel interdependencies? > > Unfortunately, the "couple of more dependencies" is visible in the > BuildRequires tree, too. Yes, that's what *-devel packages are about. > It results in pretty much the opposite of trying to eliminate > superfluous and redundant BR. You will find that packagers will be > confronted again and again with missing BR which are only needed > because of direct dependencies between .la files or changes within > the libtool dep-chain. And? One BR perhaps (!) too much for one *.la file. -- 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 Thu Jan 18 00:52:52 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 18 Jan 2007 01:52:52 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <20070117231510.GE9816@neu.nirvana> (Axel Thimm's message of "Thu, 18 Jan 2007 00:15:10 +0100") References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <20070117231510.GE9816@neu.nirvana> Message-ID: <87bqkxm9zv.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: > So let me ask again: What's really that bad about including the > current *.la files into devel by default (unless really needed in > main packages) Again: it depends on the (more or less) legitimated module whether .la files (of listed dependency_libs) are required at runtime. Therefore, .la files MUST be in main (when they are packaged at all). Enrico From bugs.michael at gmx.net Thu Jan 18 01:04:11 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 18 Jan 2007 02:04:11 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <20070118000857.GH9816@neu.nirvana> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <20070117231510.GE9816@neu.nirvana> <20070118011056.70cbe25c.bugs.michael@gmx.net> <20070118000857.GH9816@neu.nirvana> Message-ID: <20070118020411.326c72c9.bugs.michael@gmx.net> On Thu, 18 Jan 2007 01:08:57 +0100, Axel Thimm wrote: > On Thu, Jan 18, 2007 at 01:10:56AM +0100, Michael Schwendt wrote: > > On Thu, 18 Jan 2007 00:15:10 +0100, Axel Thimm wrote: > > > > > So let me ask again: What's really that bad about including the > > > current *.la files into devel by default (unless really needed in main > > > packages) other than a couple more dependencies between *-devel > > > packages and how bad are these "bloated" devel interdependencies? > > > > Unfortunately, the "couple of more dependencies" is visible in the > > BuildRequires tree, too. > > Yes, that's what *-devel packages are about. Dependencies of *-devel packages are about providing all the stuff that is needed for an API (including any technical requirements for details like linking). You seem to favour the "bloat" that increases maintenance requirements for packagers and software developers. What happens with .la dependencies is that they extend the API and make the linking more difficult (by pulling in many more libraries as if the goal were static linking). E.g. the API user of libA-devel suddenly needs libB-devel although libA's API is independent from libB's. In a different scenario, the libA-devel user suddenly needs an additional libF-devel, because libB started using libF. You end up with wrong binary dependencies, The user of libD-devel may need both extra packages, and when either one is updated without breaking the ABI, a rebuild of the tree may be needed only to fix orphaned .la dependencies, e.g. /usr/lib/libF.la in /usr/lib/libB.la, or changes in .la deps in general. > > It results in pretty much the opposite of trying to eliminate > > superfluous and redundant BR. You will find that packagers will be > > confronted again and again with missing BR which are only needed > > because of direct dependencies between .la files or changes within > > the libtool dep-chain. > > And? One BR perhaps (!) too much for one *.la file. They are _wrong_ BR and wrong R even if you insist on barking up the tree to get leaf packagers to add the bloat in their packages before you would be able to rebuild your package fine without starting to use ugly work-arounds. From Axel.Thimm at ATrpms.net Thu Jan 18 00:56:05 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 18 Jan 2007 01:56:05 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <87bqkxm9zv.fsf@kosh.bigo.ensc.de> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <20070117231510.GE9816@neu.nirvana> <87bqkxm9zv.fsf@kosh.bigo.ensc.de> Message-ID: <20070118005605.GI9816@neu.nirvana> On Thu, Jan 18, 2007 at 01:52:52AM +0100, Enrico Scholz wrote: > Axel.Thimm at ATrpms.net (Axel Thimm) writes: > > > So let me ask again: What's really that bad about including the > > current *.la files into devel by default (unless really needed in ^^^^^^^^^^^^^^^^^^^^^^^ > > main packages) ^^^^^^^^^^^^^ > > Again: it depends on the (more or less) legitimated module whether .la > files (of listed dependency_libs) are required at runtime. Therefore, > .la files MUST be in main (when they are packaged at all). > > > > Enrico > -- 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 Thu Jan 18 00:57:10 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 18 Jan 2007 01:57:10 +0100 Subject: [Fedora-packaging] Re: Re: LibtoolArchives, v0.3 References: <45AE31C5.5080602@math.unl.edu> <87wt3l7m50.fsf@fc5.bigo.ensc.de> <87sle97kn3.fsf@fc5.bigo.ensc.de> <45AE3DFB.7060406@math.unl.edu> <87odox7igw.fsf@fc5.bigo.ensc.de> Message-ID: <874pqpm9sp.fsf@kosh.bigo.ensc.de> rdieter at math.unl.edu (Rex Dieter) writes: >> The decision whether loading fails or succeeds depends on the module, >> not the library. > > I'd argue that any such module is thus broken by design, since it includes > undefined symbols, and should be fixed. Why? It's one of libtool's features that dep-loading can be done by .la files. Why should a module be broken when it uses such a feature? > I'm willing to compromise to include these bits in main (and not -devel) if > that's what it takes to gain your support/vote. Current rule (avoid .la whenever possible) is best solution. Perhaps the MUST can be weakened a little bit by allowing substantiated exceptions. Enrico From Axel.Thimm at ATrpms.net Thu Jan 18 01:04:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 18 Jan 2007 02:04:47 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <20070118020411.326c72c9.bugs.michael@gmx.net> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <20070117231510.GE9816@neu.nirvana> <20070118011056.70cbe25c.bugs.michael@gmx.net> <20070118000857.GH9816@neu.nirvana> <20070118020411.326c72c9.bugs.michael@gmx.net> Message-ID: <20070118010447.GJ9816@neu.nirvana> On Thu, Jan 18, 2007 at 02:04:11AM +0100, Michael Schwendt wrote: > On Thu, 18 Jan 2007 01:08:57 +0100, Axel Thimm wrote: > > > On Thu, Jan 18, 2007 at 01:10:56AM +0100, Michael Schwendt wrote: > > > On Thu, 18 Jan 2007 00:15:10 +0100, Axel Thimm wrote: > > > > > > > So let me ask again: What's really that bad about including the > > > > current *.la files into devel by default (unless really needed in main > > > > packages) other than a couple more dependencies between *-devel > > > > packages and how bad are these "bloated" devel interdependencies? > You seem to favour the "bloat" that increases maintenance > requirements for packagers and software developers. No, I don't favour "bloat"ing, you often seem to assume strange things about people you communicate with. > > > It results in pretty much the opposite of trying to eliminate > > > superfluous and redundant BR. You will find that packagers will > > > be confronted again and again with missing BR which are only > > > needed because of direct dependencies between .la files or > > > changes within the libtool dep-chain. > > > > And? One BR perhaps (!) too much for one *.la file. > > They are _wrong_ BR and wrong R even if you insist on barking up the tree > to get leaf packagers to add the bloat in their packages before you would > be able to rebuild your package fine without starting to use ugly work-arounds. The ugly workarounds are what we're doing with selectively nuking *.la files depening on the wind direction. Patches to untangle build and runtime dependencies from libtools are already available and used by other distribuitions and upstream authors are more than willing to understand what your issues are and fix it in libtool proper, so please put the efforts there instead of rebreaking the distro on every single kde change. Not to mention that kde is just one user of the runtime *.la there may be others now and in the future. Let's not waste ourselves on ugly workarounds and keep *.la files until libtool does better. The few "bloated" build dependencies that force our build servers to waste ten seconds more per package build are not really worth it. And again: There are patches fixing most of it already, even tested in the field by other distros since *years*. -- 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 bugs.michael at gmx.net Thu Jan 18 01:45:57 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 18 Jan 2007 02:45:57 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <20070118010447.GJ9816@neu.nirvana> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <20070117231510.GE9816@neu.nirvana> <20070118011056.70cbe25c.bugs.michael@gmx.net> <20070118000857.GH9816@neu.nirvana> <20070118020411.326c72c9.bugs.michael@gmx.net> <20070118010447.GJ9816@neu.nirvana> Message-ID: <20070118024557.99af70dc.bugs.michael@gmx.net> On Thu, 18 Jan 2007 02:04:47 +0100, Axel Thimm wrote: > No, I don't favour "bloat"ing, you often seem to assume strange things > about people you communicate with. It's just you, Axel. It's triggered by your strange replies. ;) I try to explain the problem to you and in return only get something like "Yes, that's what *-devel packages are about" which tells me you are not serious. > > > > It results in pretty much the opposite of trying to eliminate > > > > superfluous and redundant BR. You will find that packagers will > > > > be confronted again and again with missing BR which are only > > > > needed because of direct dependencies between .la files or > > > > changes within the libtool dep-chain. > > > > > > And? One BR perhaps (!) too much for one *.la file. > > > > They are _wrong_ BR and wrong R even if you insist on barking up the tree > > to get leaf packagers to add the bloat in their packages before you would > > be able to rebuild your package fine without starting to use ugly work-arounds. > > The ugly workarounds are what we're doing with selectively nuking *.la > files depening on the wind direction. Patches to untangle build and > runtime dependencies from libtools are already available and used by > other distribuitions and upstream authors are more than willing to > understand what your issues are and fix it in libtool proper, so > please put the efforts there instead of rebreaking the distro on every > single kde change. Not to mention that kde is just one user of the > runtime *.la there may be others now and in the future. As much as I support upstream changes, it is beyond my motivation to be the one to take the lead here. I have not even seen any solutions other than killing .la files except where the used ltdl doesn't understand .so files. Btw, see e.g. KDE's missing response: http://bugs.kde.org/show_bug.cgi?id=93359 Very disappointing. > Let's not waste ourselves on ugly workarounds and keep *.la files > until libtool does better. The few "bloated" build dependencies that > force our build servers to waste ten seconds more per package build > are not really worth it. And again: There are patches fixing most of > it already, even tested in the field by other distros since *years*. Once more, the bloat also affects the linking and hence the *binary* dependencies. From Axel.Thimm at ATrpms.net Thu Jan 18 01:48:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 18 Jan 2007 02:48:47 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <20070118024557.99af70dc.bugs.michael@gmx.net> References: <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <20070117231510.GE9816@neu.nirvana> <20070118011056.70cbe25c.bugs.michael@gmx.net> <20070118000857.GH9816@neu.nirvana> <20070118020411.326c72c9.bugs.michael@gmx.net> <20070118010447.GJ9816@neu.nirvana> <20070118024557.99af70dc.bugs.michael@gmx.net> Message-ID: <20070118014847.GA18552@neu.nirvana> On Thu, Jan 18, 2007 at 02:45:57AM +0100, Michael Schwendt wrote: > On Thu, 18 Jan 2007 02:04:47 +0100, Axel Thimm wrote: > > > No, I don't favour "bloat"ing, you often seem to assume strange > > things about people you communicate with. > > It's just you, Axel. It's triggered by your strange replies. ;) I > try to explain the problem to you and in return only get something > like "Yes, that's what *-devel packages are about" which tells me > you are not serious. You're now getting personal, watch the line. And I do know for a fact that it's not "just me". > As much as I support upstream changes, it is beyond my motivation to > be the one to take the lead here. But it is your motivation obviously to head towards the opposite direction. > I have not even seen any solutions other than killing .la files > except where the used ltdl doesn't understand .so files. Maybe because your toolbox at home only has a hammer? How many times did I mention in this thread that there are working patches even used for quite some time in other distros? -- 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 bugs.michael at gmx.net Thu Jan 18 02:39:47 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 18 Jan 2007 03:39:47 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <20070118014847.GA18552@neu.nirvana> References: <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <20070117231510.GE9816@neu.nirvana> <20070118011056.70cbe25c.bugs.michael@gmx.net> <20070118000857.GH9816@neu.nirvana> <20070118020411.326c72c9.bugs.michael@gmx.net> <20070118010447.GJ9816@neu.nirvana> <20070118024557.99af70dc.bugs.michael@gmx.net> <20070118014847.GA18552@neu.nirvana> Message-ID: <20070118033947.aedf6ead.bugs.michael@gmx.net> On Thu, 18 Jan 2007 02:48:47 +0100, Axel Thimm wrote: > > As much as I support upstream changes, it is beyond my motivation to > > be the one to take the lead here. > > But it is your motivation obviously to head towards the opposite > direction. You often seem to assume strange things about people you communicate with. Oh, wait, that was a quote from your previous mail! Actually, the "opposite direction" is what you propose, i.e. to bring back the .la problems before an alternative solution is implemented. > > I have not even seen any solutions other than killing .la files > > except where the used ltdl doesn't understand .so files. > > Maybe because your toolbox at home only has a hammer? Lame metaphors are an effective way to kill communication. > How many times did I mention in this thread that there are working > patches even used for quite some time in other distros? Why don't you collect them and present them for review? But to do you a favour, let's return to a previous message. Quoting Axel: My proposal is to allow *.la files to live and kindly divert people crying too loud about it to assist upstream in fixing the issues. Don't forget that there are already patches for dealing with 95% of our issues available. Clever! First you prepare the road with phrases like "people crying too loud" before you try to subvert established packaging techniques: So let me ask again: What's really that bad about including the current *.la files into devel by default (unless really needed in main packages) other than a couple more dependencies between *-devel packages and how bad are these "bloated" devel interdependencies? I wish you would have the courage to explain what the benefits of bringing back .la files would be before a solution is supported upstream. What are the "95% of our issues" and how do the patches avoid them? From rdieter at math.unl.edu Thu Jan 18 02:56:18 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 17 Jan 2007 20:56:18 -0600 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <20070118024557.99af70dc.bugs.michael@gmx.net> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <20070117231510.GE9816@neu.nirvana> <20070118011056.70cbe25c.bugs.michael@gmx.net> <20070118000857.GH9816@neu.nirvana> <20070118020411.326c72c9.bugs.michael@gmx.net> <20070118010447.GJ9816@neu.nirvana> <20070118024557.99af70dc.bugs.michael@gmx.net> Message-ID: <45AEE1D2.3090508@math.unl.edu> Michael Schwendt wrote: > On Thu, 18 Jan 2007 02:04:47 +0100, Axel Thimm wrote: > As much as I support upstream changes, it is beyond my motivation to be > the one to take the lead here. I have not even seen any solutions other > than killing .la files except where the used ltdl doesn't understand .so > files. > > Btw, see e.g. KDE's missing response: > http://bugs.kde.org/show_bug.cgi?id=93359 > Very disappointing. Or worse, WONTFIX: http://bugs.kde.org/139445 -- Rex From Axel.Thimm at ATrpms.net Thu Jan 18 02:51:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 18 Jan 2007 03:51:36 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <20070118033947.aedf6ead.bugs.michael@gmx.net> References: <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <20070117231510.GE9816@neu.nirvana> <20070118011056.70cbe25c.bugs.michael@gmx.net> <20070118000857.GH9816@neu.nirvana> <20070118020411.326c72c9.bugs.michael@gmx.net> <20070118010447.GJ9816@neu.nirvana> <20070118024557.99af70dc.bugs.michael@gmx.net> <20070118014847.GA18552@neu.nirvana> <20070118033947.aedf6ead.bugs.michael@gmx.net> Message-ID: <20070118025136.GA19555@neu.nirvana> On Thu, Jan 18, 2007 at 02:48:47AM +0100, Axel Thimm wrote: > You're now getting personal, watch the line. On Thu, Jan 18, 2007 at 03:39:47AM +0100, Michael Schwendt wrote: > You often seem to assume strange things about people you communicate with. > Oh, wait, that was a quote from your previous mail! > Lame metaphors are an effective way to kill communication. > Clever! First you prepare the road with phrases like "people crying too > loud" before you try to subvert established packaging techniques: > I wish you would have the courage to explain what the benefits of bringing > back .la files would be before a solution is supported upstream. What > are the "95% of our issues" and how do the patches avoid them? Funny, when someone tries to hint you the line between etiquette and being insulting you add to your ironic eloquence to make sure you do pass that line and kill the discussion. While you succeeded in this, there are no squealer bonus for you this 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 skvidal at linux.duke.edu Thu Jan 18 04:37:43 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 17 Jan 2007 23:37:43 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <45AE93E5.8030900@redhat.com> References: <45AE93E5.8030900@redhat.com> Message-ID: <1169095063.4377.75.camel@cutter> On Wed, 2007-01-17 at 16:23 -0500, Fernando Nasser wrote: > Hi, > b) yum has already some group functionality (groupinstall, groupupdate, > groupremove, groupinfo) that is based on an XML file that is kept in the > repository. But the option --exclude only acts on file names, we need a > --groupexclude. > > We already have a "Java" group, with only 2 packages on it: > > # yum groupinfo Java > Loading "installonlyn" plugin > Setting up Group Process > Setting up repositories > > Group: Java > Description: Support for running programs written in the Java > programming language. > Mandatory Packages: > libgcj > java-1.4.2-gcj-compat > > We could just make sure all Java packages are in the Java group to make > use of the yum group functionality. > We just need the --groupexclude. > > I will try and create a patch to add a '--groupexclude' as soon as I > finish with the rpm one. why do you need a 'groupexclude' option? I guess I don't understand the use case for it, yet. -sv From a.badger at gmail.com Thu Jan 18 07:02:51 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 17 Jan 2007 23:02:51 -0800 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <45AE93E5.8030900@redhat.com> References: <45AE93E5.8030900@redhat.com> Message-ID: <1169103772.14225.38.camel@localhost.localdomain> On Wed, 2007-01-17 at 16:23 -0500, Fernando Nasser wrote: > 1) We seem to agree that we want to make the following transformation on > the release fields : > > 3jpp -> 3.1 in Fedora > > This will satisfy all our upgrade paths, as: > > 4.1 > 4jpp > 3.1 > 3jpp > > so one can always have the latest fixes. > Spot brought the 3jpp.fc6.1 format to the packaging group which was discussed and agreed as a possible temporary format. Unfortunately, 3jpp.fc6.1 doesn't work for interleaving with jpackage if jpp is removed. So we'll probably have to have another (hopefully short) discussion about using 3jpp.1.fc6 & 3.1.fc6. > > 2) Some would be agreeable to leaving the 'jpp' in there as a temporary > measure, as what we really want is some Groups (or Categories) > functionality that is not yet available. > > So, temporarely, 3jpp -> 3jpp.1 > Yep. > > 3) What do we need to get rid of the 'jpp' > > a) Query for the set of Java packages > > The rpm -qg (or rpm -q --group) command currently does not accept patterns > > If we could do 'rpm -qg "Java*"' we could add "Java/" to all "Group:" > tags of all Java packages and that would work. > > I am trying to create a patch for that (which would be RPM patch #37 in > Fedora) but I am encountering some difficulties as it is the first time > I am looking at the rpm source code and I have been working with Java > rather than C in the last years. > > P.S.: We would need a similar query functionality when Categories > replace Groups. > Although I can't speak for the likelihood of this getting into rpm, it's usefulness is going to be near nil. The distribution is moving away from storing group information in the rpm spec file. These reasons have been articulated by Jeremy Katz and others on fedora-devel many times in the past. There are some pointers to the last discussion here: http://www.fedoraproject.org/wiki/Extras/SIGs/Comps/PackageGroupEnhancements The page has the justification for moving away from the group tag at the top of the page although I think the discussion for that happened in previous discussions (so the threads that are linked will assume that everyone already knows the shortcomings of the Group tag.) Given this, I'd be very hesitant to make group functionality in rpm be one of the criteria to get rid of the jpp naming. > b) yum has already some group functionality (groupinstall, groupupdate, > groupremove, groupinfo) that is based on an XML file that is kept in the > repository. But the option --exclude only acts on file names, we need a > --groupexclude. > > We already have a "Java" group, with only 2 packages on it: > > # yum groupinfo Java > Loading "installonlyn" plugin > Setting up Group Process > Setting up repositories > > Group: Java > Description: Support for running programs written in the Java > programming language. > Mandatory Packages: > libgcj > java-1.4.2-gcj-compat > If I understood spot's summary of your requirements, you want to categorize all the packages you are importing from jpackage. I would point out that the java group would be a poor place to implement that as any java packages which did not come through jpackage could also legitimately be placed in there. > We could just make sure all Java packages are in the Java group to make > use of the yum group functionality. > We just need the --groupexclude. > > I will try and create a patch to add a '--groupexclude' as soon as I > finish with the rpm one. > One controversy with using the yum group functionality for this is that it uses comps.xml to achieve its ends. Jeremy Katz is against using comps.xml to make categories that shouldn't be visible to the installer. skvidal has shown how we could have multiple comps.xml files that yum reads (whereas the installer only reads from one) which addresses a few of Jeremy's concerns. When we go ahead with this we'll have to work out whether we're going to store the information in a comps file or teach yum about a new grouping file format. -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 bugs.michael at gmx.net Thu Jan 18 12:15:52 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 18 Jan 2007 13:15:52 +0100 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <20070118025136.GA19555@neu.nirvana> References: <20070117160628.GK26437@neu.nirvana> <1169050189.20121.1.camel@localhost.localdomain> <20070117231510.GE9816@neu.nirvana> <20070118011056.70cbe25c.bugs.michael@gmx.net> <20070118000857.GH9816@neu.nirvana> <20070118020411.326c72c9.bugs.michael@gmx.net> <20070118010447.GJ9816@neu.nirvana> <20070118024557.99af70dc.bugs.michael@gmx.net> <20070118014847.GA18552@neu.nirvana> <20070118033947.aedf6ead.bugs.michael@gmx.net> <20070118025136.GA19555@neu.nirvana> Message-ID: <20070118131552.84dcadb3.bugs.michael@gmx.net> On Thu, 18 Jan 2007 03:51:36 +0100, Axel Thimm wrote: > Funny, when someone tries to hint you the line between etiquette and > being insulting you add to your ironic eloquence to make sure you do > pass that line and kill the discussion. While you succeeded in this, > there are no squealer bonus for you this time. No further! I've revisited the thread and its development and am taking more drastic action this time. Shortly after this message I'm going to submit my unsubscription request. Enough is enough. From fnasser at redhat.com Thu Jan 18 14:11:17 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 18 Jan 2007 09:11:17 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <1169095063.4377.75.camel@cutter> References: <45AE93E5.8030900@redhat.com> <1169095063.4377.75.camel@cutter> Message-ID: <45AF8005.8020003@redhat.com> seth vidal wrote: > > why do you need a 'groupexclude' option? I guess I don't understand the > use case for it, yet. > For instance, to upgrade one's Fedora system without interfering with the Java stack there. From fnasser at redhat.com Thu Jan 18 14:26:40 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 18 Jan 2007 09:26:40 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <1169103772.14225.38.camel@localhost.localdomain> References: <45AE93E5.8030900@redhat.com> <1169103772.14225.38.camel@localhost.localdomain> Message-ID: <45AF83A0.8090600@redhat.com> Hi Toshio, Toshio Kuratomi wrote: > On Wed, 2007-01-17 at 16:23 -0500, Fernando Nasser wrote: >> 1) We seem to agree that we want to make the following transformation on >> the release fields : >> >> 3jpp -> 3.1 in Fedora >> >> This will satisfy all our upgrade paths, as: >> >> 4.1 > 4jpp > 3.1 > 3jpp >> >> so one can always have the latest fixes. >> > Spot brought the 3jpp.fc6.1 format to the packaging group which was > discussed and agreed as a possible temporary format. Unfortunately, > 3jpp.fc6.1 doesn't work for interleaving with jpackage if jpp is > removed. So we'll probably have to have another (hopefully short) > discussion about using 3jpp.1.fc6 & 3.1.fc6. > Why the %{_dist} is necessary here? Can't we just add the number? I thought we would need the %{_dist} only if we needed to have the same RPM built in two different distro releases and they were release specific (depend on some shared library or something). >> 2) Some would be agreeable to leaving the 'jpp' in there as a temporary >> measure, as what we really want is some Groups (or Categories) >> functionality that is not yet available. >> >> So, temporarely, 3jpp -> 3jpp.1 >> > Yep. > >> 3) What do we need to get rid of the 'jpp' >> >> a) Query for the set of Java packages >> >> The rpm -qg (or rpm -q --group) command currently does not accept patterns >> >> If we could do 'rpm -qg "Java*"' we could add "Java/" to all "Group:" >> tags of all Java packages and that would work. >> >> I am trying to create a patch for that (which would be RPM patch #37 in >> Fedora) but I am encountering some difficulties as it is the first time >> I am looking at the rpm source code and I have been working with Java >> rather than C in the last years. >> >> P.S.: We would need a similar query functionality when Categories >> replace Groups. >> > Although I can't speak for the likelihood of this getting into rpm, it's > usefulness is going to be near nil. The distribution is moving away > from storing group information in the rpm spec file. These reasons have > been articulated by Jeremy Katz and others on fedora-devel many times in > the past. > > There are some pointers to the last discussion here: > http://www.fedoraproject.org/wiki/Extras/SIGs/Comps/PackageGroupEnhancements > > The page has the justification for moving away from the group tag at the > top of the page although I think the discussion for that happened in > previous discussions (so the threads that are linked will assume that > everyone already knows the shortcomings of the Group tag.) > > Given this, I'd be very hesitant to make group functionality in rpm be > one of the criteria to get rid of the jpp naming. > You missed the "P.S." I am creating a patch for Groups because Categories are not there yet, so I can't do anything for it ATM. Once Groups are abandoned in favor of Categories, the functionality available for Groups must be adapted to work with Categories instead. In any case, I am not trying to add any new switch or functionality, just fix an existing one that has an annoying shortcoming ('rpm -q --group' does not take a regexp/glob). >> b) yum has already some group functionality (groupinstall, groupupdate, >> groupremove, groupinfo) that is based on an XML file that is kept in the >> repository. But the option --exclude only acts on file names, we need a >> --groupexclude. >> >> We already have a "Java" group, with only 2 packages on it: >> >> # yum groupinfo Java >> Loading "installonlyn" plugin >> Setting up Group Process >> Setting up repositories >> >> Group: Java >> Description: Support for running programs written in the Java >> programming language. >> Mandatory Packages: >> libgcj >> java-1.4.2-gcj-compat >> > If I understood spot's summary of your requirements, you want to > categorize all the packages you are importing from jpackage. I would > point out that the java group would be a poor place to implement that as > any java packages which did not come through jpackage could also > legitimately be placed in there. > We actually want all Java packages. They are always extremely interrelated, with cascading effects among them, so they need to be treated as a whole. Any Java package should be in there. When categories become available, we can even be fancies and have the Java ones that are from Jpackage also in a specific category (I don't have a use case for that at the moment, but if necessary we could do it). >> We could just make sure all Java packages are in the Java group to make >> use of the yum group functionality. >> We just need the --groupexclude. >> >> I will try and create a patch to add a '--groupexclude' as soon as I >> finish with the rpm one. >> > One controversy with using the yum group functionality for this is that > it uses comps.xml to achieve its ends. Jeremy Katz is against using > comps.xml to make categories that shouldn't be visible to the installer. > skvidal has shown how we could have multiple comps.xml files that yum > reads (whereas the installer only reads from one) which addresses a few > of Jeremy's concerns. When we go ahead with this we'll have to work out > whether we're going to store the information in a comps file or teach > yum about a new grouping file format. > In any case, there will be always something for groupinstall, groupupdate, groupremove, groupinfo and also a --groupexclude to do the selection. Regards, Fernando From rdieter at math.unl.edu Thu Jan 18 14:32:19 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 18 Jan 2007 08:32:19 -0600 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <45AF83A0.8090600@redhat.com> References: <45AE93E5.8030900@redhat.com> <1169103772.14225.38.camel@localhost.localdomain> <45AF83A0.8090600@redhat.com> Message-ID: <45AF84F3.4020609@math.unl.edu> Fernando Nasser wrote: > Hi Toshio, >> Spot brought the 3jpp.fc6.1 format to the packaging group which was >> discussed and agreed as a possible temporary format. Unfortunately, >> 3jpp.fc6.1 doesn't work for interleaving with jpackage if jpp is >> removed. So we'll probably have to have another (hopefully short) >> discussion about using 3jpp.1.fc6 & 3.1.fc6. >> > > Why the %{_dist} is necessary here? Can't we just add the number? Use of %{?dist} is/was/always-has-been optional. (: -- Rex From jkeating at redhat.com Thu Jan 18 15:12:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 Jan 2007 10:12:09 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <45AF83A0.8090600@redhat.com> References: <45AE93E5.8030900@redhat.com> <1169103772.14225.38.camel@localhost.localdomain> <45AF83A0.8090600@redhat.com> Message-ID: <200701181012.12566.jkeating@redhat.com> On Thursday 18 January 2007 09:26, Fernando Nasser wrote: > > Spot brought the 3jpp.fc6.1 format to the packaging group which was > > discussed and agreed as a possible temporary format. ?Unfortunately, > > 3jpp.fc6.1 doesn't work for interleaving with jpackage if jpp is > > removed. ?So we'll probably have to have another (hopefully short) > > discussion about using 3jpp.1.fc6 & 3.1.fc6. > > Why the %{_dist} is necessary here? ?Can't we just add the number? > I thought we would need the %{_dist} only if we needed to have the same > RPM built in two different distro releases and they were release > specific (depend on some shared library or something). Unfortunately it may be necessary for you folks, if we ever have to bump the package in an older release, without becoming NVR higher than the same package in a newer release. If 3jpp is used in both FC6 and F7, and we have to rebuild in FC6 for whatever localized reason, we have to be able to do it in a way that doesn't promote it to be NVR higher than the 3jpp in F7. -- 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 tcallawa at redhat.com Thu Jan 18 15:18:40 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 18 Jan 2007 09:18:40 -0600 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <200701181012.12566.jkeating@redhat.com> References: <45AE93E5.8030900@redhat.com> <1169103772.14225.38.camel@localhost.localdomain> <45AF83A0.8090600@redhat.com> <200701181012.12566.jkeating@redhat.com> Message-ID: <1169133520.30262.30.camel@localhost.localdomain> On Thu, 2007-01-18 at 10:12 -0500, Jesse Keating wrote: > On Thursday 18 January 2007 09:26, Fernando Nasser wrote: > > > Spot brought the 3jpp.fc6.1 format to the packaging group which was > > > discussed and agreed as a possible temporary format. Unfortunately, > > > 3jpp.fc6.1 doesn't work for interleaving with jpackage if jpp is > > > removed. So we'll probably have to have another (hopefully short) > > > discussion about using 3jpp.1.fc6 & 3.1.fc6. > > > > Why the %{_dist} is necessary here? Can't we just add the number? > > I thought we would need the %{_dist} only if we needed to have the same > > RPM built in two different distro releases and they were release > > specific (depend on some shared library or something). > > Unfortunately it may be necessary for you folks, if we ever have to bump the > package in an older release, without becoming NVR higher than the same > package in a newer release. If 3jpp is used in both FC6 and F7, and we have > to rebuild in FC6 for whatever localized reason, we have to be able to do it > in a way that doesn't promote it to be NVR higher than the 3jpp in F7. Well, it turns out I don't think this will be necessary: I started writing this up late on Tuesday: http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage ~spot From jkeating at redhat.com Thu Jan 18 15:29:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 Jan 2007 10:29:02 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <1169133520.30262.30.camel@localhost.localdomain> References: <45AE93E5.8030900@redhat.com> <200701181012.12566.jkeating@redhat.com> <1169133520.30262.30.camel@localhost.localdomain> Message-ID: <200701181029.02882.jkeating@redhat.com> On Thursday 18 January 2007 10:18, Tom 'spot' Callaway wrote: > Well, it turns out I don't think this will be necessary: > > I started writing this up late on Tuesday: > > http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage I don't see how this handles multiple Fedora releases. This works great if you only consider jpackage as one release, and Current Fedora as one release. However we DO have to consider: jpackage-- | - Fedora Current | - Fedora (Current - 1) | - Fedora (Current - 2) Obviously one can't use the same NVR on all three Fedora lines, so something has to be used to differentiate them, and allow for rebuilding something on Current - 1 that isn't built on Fedora Current. (could be something as silly as a buildsystem bug that didn't produce all the packages. Have to bump the nvr to build again) -- 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 tcallawa at redhat.com Thu Jan 18 15:33:58 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 18 Jan 2007 09:33:58 -0600 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <200701181029.02882.jkeating@redhat.com> References: <45AE93E5.8030900@redhat.com> <200701181012.12566.jkeating@redhat.com> <1169133520.30262.30.camel@localhost.localdomain> <200701181029.02882.jkeating@redhat.com> Message-ID: <1169134438.30262.40.camel@localhost.localdomain> On Thu, 2007-01-18 at 10:29 -0500, Jesse Keating wrote: > On Thursday 18 January 2007 10:18, Tom 'spot' Callaway wrote: > > Well, it turns out I don't think this will be necessary: > > > > I started writing this up late on Tuesday: > > > > http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage > > I don't see how this handles multiple Fedora releases. > > This works great if you only consider jpackage as one release, and Current > Fedora as one release. However we DO have to consider: > > jpackage-- > | > - Fedora Current > | > - Fedora (Current - 1) > | > - Fedora (Current - 2) > > Obviously one can't use the same NVR on all three Fedora lines, so something > has to be used to differentiate them, and allow for rebuilding something on > Current - 1 that isn't built on Fedora Current. (could be something as silly > as a buildsystem bug that didn't produce all the packages. Have to bump the > nvr to build again) Hmm, that is a good point. Normally, we'd give the packager the choice of using %{?dist} or bumping the release, but since we're trying to ensure hierarchy, %{?dist} is the only real option. Just appending %{?dist} to the end of the subrelease scheme solves that issue, I'll update the document. ~spot From fnasser at redhat.com Thu Jan 18 15:57:31 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 18 Jan 2007 10:57:31 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <200701181012.12566.jkeating@redhat.com> References: <45AE93E5.8030900@redhat.com> <1169103772.14225.38.camel@localhost.localdomain> <45AF83A0.8090600@redhat.com> <200701181012.12566.jkeating@redhat.com> Message-ID: <45AF98EB.2040701@redhat.com> Jesse Keating wrote: > On Thursday 18 January 2007 09:26, Fernando Nasser wrote: >>> Spot brought the 3jpp.fc6.1 format to the packaging group which was >>> discussed and agreed as a possible temporary format. Unfortunately, >>> 3jpp.fc6.1 doesn't work for interleaving with jpackage if jpp is >>> removed. So we'll probably have to have another (hopefully short) >>> discussion about using 3jpp.1.fc6 & 3.1.fc6. >> Why the %{_dist} is necessary here? Can't we just add the number? >> I thought we would need the %{_dist} only if we needed to have the same >> RPM built in two different distro releases and they were release >> specific (depend on some shared library or something). > > Unfortunately it may be necessary for you folks, if we ever have to bump the > package in an older release, without becoming NVR higher than the same > package in a newer release. If 3jpp is used in both FC6 and F7, and we have > to rebuild in FC6 for whatever localized reason, we have to be able to do it > in a way that doesn't promote it to be NVR higher than the 3jpp in F7. > But isn't the norm that we do this only if such case ever happen? Anyway, I believe the only case we would respin the FC6 one would be if there was a (security?) bug, so we will probably have to respin the FC7 one as well, so it will end up being FC6 +1 anyway. At least this is what has been happening so far. Shouldn't we leave the %{_dist} out and add it only if absolutely necessary for a specific package? From fnasser at redhat.com Thu Jan 18 16:02:33 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 18 Jan 2007 11:02:33 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <200701181029.02882.jkeating@redhat.com> References: <45AE93E5.8030900@redhat.com> <200701181012.12566.jkeating@redhat.com> <1169133520.30262.30.camel@localhost.localdomain> <200701181029.02882.jkeating@redhat.com> Message-ID: <45AF9A19.8070903@redhat.com> Jesse Keating wrote: > On Thursday 18 January 2007 10:18, Tom 'spot' Callaway wrote: >> Well, it turns out I don't think this will be necessary: >> >> I started writing this up late on Tuesday: >> >> http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage > > I don't see how this handles multiple Fedora releases. > > This works great if you only consider jpackage as one release, and Current > Fedora as one release. However we DO have to consider: > > jpackage-- > | > - Fedora Current > | > - Fedora (Current - 1) > | > - Fedora (Current - 2) > > Obviously one can't use the same NVR on all three Fedora lines, so something > has to be used to differentiate them, and allow for rebuilding something on > Current - 1 that isn't built on Fedora Current. (could be something as silly > as a buildsystem bug that didn't produce all the packages. Have to bump the > nvr to build again) > Perhaps this never happens because we always have some updates and we always do a mass rebuild with release bumping for any new Fedora release. Ans as any fix for a Fedora -N is accompanied by it being applied to the subsequent Fedoras -(N -1) until current, that has never happened so far. Anyway, if you guys want the %{_dist} at the end we will add them, I am just not really sure that this situation will ever happen. From jkeating at redhat.com Thu Jan 18 16:04:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 Jan 2007 11:04:40 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <45AF98EB.2040701@redhat.com> References: <45AE93E5.8030900@redhat.com> <200701181012.12566.jkeating@redhat.com> <45AF98EB.2040701@redhat.com> Message-ID: <200701181104.40850.jkeating@redhat.com> On Thursday 18 January 2007 10:57, Fernando Nasser wrote: > But isn't the norm that we do this only if such case ever happen? Without the dist there beforehand, it doesn't help to add it after, as foo.fc6 will be newer than just foo, where foo could have been foo.fc7. > Anyway, I believe the only case we would respin the FC6 one would be if > there was a (security?) bug, so we will probably have to respin the FC7 > one as well, so it will end up being FC6 +1 anyway. ?At least this is > what has been happening so far. That isn't always the case. A bug with the gcj version in FC6 could cause a rebuild, and that bug may not exist in the F7 version of gcj. Or there could have been a buildsystem issue when building 3jpp for all branches, requiring you to rebuild on FC6 branch but not F7 branch. These things do happen, we need to account for them instead of trying to work around them with epochs later. > Shouldn't we leave the %{_dist} out and add it only if absolutely > necessary for a specific package? Again, by the time you realize you need it, its too late, unless you rebuild on ALL branches just to add the dist tag, and then you defeat the purpose. ANY package that is using the same upstream version should probably use the dist tag to avoid non-fun games with adjusting release across branches. -- 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 jkeating at redhat.com Thu Jan 18 16:08:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 Jan 2007 11:08:02 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <45AF9A19.8070903@redhat.com> References: <45AE93E5.8030900@redhat.com> <200701181029.02882.jkeating@redhat.com> <45AF9A19.8070903@redhat.com> Message-ID: <200701181108.02720.jkeating@redhat.com> On Thursday 18 January 2007 11:02, Fernando Nasser wrote: > Perhaps this never happens because we always have some updates and we > always do a mass rebuild with release bumping for any new Fedora release. > > Ans as any fix for a Fedora -N is accompanied by it being applied to the > subsequent Fedoras -(N -1) until current, that has never happened so far. > > Anyway, if you guys want the %{_dist} at the end we will add them, I am > just not really sure that this situation will ever happen. Why wouldn't FC6 users want the latest jpp releases of stuff when rawhide gets them? Are they not suitable for FC6, ever? We shouldn't actively prevent this from happening, especially now that we're opening the doors for more people to participate and take on some of the workload of import/building. -- 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 fnasser at redhat.com Thu Jan 18 16:43:14 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 18 Jan 2007 11:43:14 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <200701181104.40850.jkeating@redhat.com> References: <45AE93E5.8030900@redhat.com> <200701181012.12566.jkeating@redhat.com> <45AF98EB.2040701@redhat.com> <200701181104.40850.jkeating@redhat.com> Message-ID: <45AFA3A2.9060307@redhat.com> Hi Jesse,, Please note that I don't have any problems with using the dist tag, I just want to make sure I understand the situations where it should be used so that I (and others who are followint the thread) know how to use it properly. Jesse Keating wrote: > On Thursday 18 January 2007 10:57, Fernando Nasser wrote: >> But isn't the norm that we do this only if such case ever happen? > > Without the dist there beforehand, it doesn't help to add it after, as foo.fc6 > will be newer than just foo, where foo could have been foo.fc7. > >> Anyway, I believe the only case we would respin the FC6 one would be if >> there was a (security?) bug, so we will probably have to respin the FC7 >> one as well, so it will end up being FC6 +1 anyway. At least this is >> what has been happening so far. > > That isn't always the case. A bug with the gcj version in FC6 could cause a > rebuild, and that bug may not exist in the F7 version of gcj. Or there could > have been a buildsystem issue when building 3jpp for all branches, requiring > you to rebuild on FC6 branch but not F7 branch. These things do happen, we > need to account for them instead of trying to work around them with epochs > later. > But this can happen with any package right? If any package is not upgraded between fc6 and FC7 for instance, it is subject to have to be respun for FC6 and that make it newer than the one in FC7. Lets say ppp was not updated between FC6 and FC7. So we have: FC6 ppp-2.4.4-1 FC7 ppp-2.4.4-2 And if ppp has to be updated in FC6 and not in FC7 we'd be in trouble, right? As we cannot ensure this situation will never happen for any package, ALL packages would have to use dist. Or is it that we only do that if there was no major version updates between FC6 and FC7? As we never do major upgrades in older releases that would take care of it. >> Shouldn't we leave the %{_dist} out and add it only if absolutely >> necessary for a specific package? > > Again, by the time you realize you need it, its too late, unless you rebuild > on ALL branches just to add the dist tag, and then you defeat the purpose. > ANY package that is using the same upstream version should probably use the > dist tag to avoid non-fun games with adjusting release across branches. > I think what I need to understand now is why it affects more packages with an upstream version than the others. You are probably thinking of a specific scenario, what is it? From fnasser at redhat.com Thu Jan 18 16:47:27 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 18 Jan 2007 11:47:27 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <200701181108.02720.jkeating@redhat.com> References: <45AE93E5.8030900@redhat.com> <200701181029.02882.jkeating@redhat.com> <45AF9A19.8070903@redhat.com> <200701181108.02720.jkeating@redhat.com> Message-ID: <45AFA49F.4070608@redhat.com> Jesse Keating wrote: > On Thursday 18 January 2007 11:02, Fernando Nasser wrote: >> Perhaps this never happens because we always have some updates and we >> always do a mass rebuild with release bumping for any new Fedora release. >> >> Ans as any fix for a Fedora -N is accompanied by it being applied to the >> subsequent Fedoras -(N -1) until current, that has never happened so far. >> >> Anyway, if you guys want the %{_dist} at the end we will add them, I am >> just not really sure that this situation will ever happen. > > Why wouldn't FC6 users want the latest jpp releases of stuff when rawhide gets > them? Are they not suitable for FC6, ever? We shouldn't actively prevent > this from happening, especially now that we're opening the doors for more > people to participate and take on some of the workload of import/building. > I most certainly don't want to prevent that. I was under the impression that Rawhide would always have a newer VR, which you are saying that needs the dist tag to be ensured. I've asked the questions about the dist tag in my previous messages. I believe I am not the only one with some questions about it, so the clarifications will be useful for others as well. From jkeating at redhat.com Thu Jan 18 17:02:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 Jan 2007 12:02:39 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <45AFA3A2.9060307@redhat.com> References: <45AE93E5.8030900@redhat.com> <200701181104.40850.jkeating@redhat.com> <45AFA3A2.9060307@redhat.com> Message-ID: <200701181202.39463.jkeating@redhat.com> On Thursday 18 January 2007 11:43, Fernando Nasser wrote: > > Again, by the time you realize you need it, its too late, unless you > > rebuild on ALL branches just to add the dist tag, and then you defeat the > > purpose. ANY package that is using the same upstream version should > > probably use the dist tag to avoid non-fun games with adjusting release > > across branches. > > I think what I need to understand now is why it affects more packages > with an upstream version than the others. ?You are probably thinking of > a specific scenario, what is it? Well, some people try to manage this themselves, by using a release of "6" for FC6 branch, release of "7" for F7 branch. Then if they have to respin on 6, they go from 6 to 6.1 which is still older than 7. grog upstream release 4.1. grog-4.1-6 = FC6 grog-4.1-7 = F7 grog-4.1-6.1 = FC6 respin still older than F7 We still have to do this with disttag too, but then we don't have to have fake release numbers per se. grog-4.1-1%{?dist} Can be used across both branches, giving you: grog-4.1-1.fc6 = FC6 grog-4.1-1.fc7 = F7 One can continually use the same exact spec file for both branches until there comes a time that you actually have to fork one of them, and you'd add a .1 after the dist tag: grog-4.1-1.fc6.1 = FC6 respun grog-4.1-1.fc7 = F7, still NVR newer. When using disttag, you can branch later. When NOT using disttag, you have to branch immediately to ensure that NVRs are not the same and are in proper upgrade order. -- 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 a.badger at gmail.com Thu Jan 18 18:27:17 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 18 Jan 2007 10:27:17 -0800 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <45AF83A0.8090600@redhat.com> References: <45AE93E5.8030900@redhat.com> <1169103772.14225.38.camel@localhost.localdomain> <45AF83A0.8090600@redhat.com> Message-ID: <1169144837.14225.78.camel@localhost.localdomain> On Thu, 2007-01-18 at 09:26 -0500, Fernando Nasser wrote: > Hi Toshio, > > Toshio Kuratomi wrote: > > Spot brought the 3jpp.fc6.1 format to the packaging group which was > > discussed and agreed as a possible temporary format. Unfortunately, > > 3jpp.fc6.1 doesn't work for interleaving with jpackage if jpp is > > removed. So we'll probably have to have another (hopefully short) > > discussion about using 3jpp.1.fc6 & 3.1.fc6. > > > > Why the %{_dist} is necessary here? Can't we just add the number? > I thought we would need the %{_dist} only if we needed to have the same > RPM built in two different distro releases and they were release > specific (depend on some shared library or something). > Jesse seems to be answering this one. > > > >> 3) What do we need to get rid of the 'jpp' > >> > >> a) Query for the set of Java packages > >> > >> The rpm -qg (or rpm -q --group) command currently does not accept patterns > >> > >> If we could do 'rpm -qg "Java*"' we could add "Java/" to all "Group:" > >> tags of all Java packages and that would work. > >> > >> I am trying to create a patch for that (which would be RPM patch #37 in > >> Fedora) but I am encountering some difficulties as it is the first time > >> I am looking at the rpm source code and I have been working with Java > >> rather than C in the last years. > >> > >> P.S.: We would need a similar query functionality when Categories > >> replace Groups. > >> [snip] > > Given this, I'd be very hesitant to make group functionality in rpm be > > one of the criteria to get rid of the jpp naming. > > > > You missed the "P.S." > > I am creating a patch for Groups because Categories are not there yet, > so I can't do anything for it ATM. Once Groups are abandoned in favor > of Categories, the functionality available for Groups must be adapted to > work with Categories instead. > I read that but perhaps one of us is misinterpreting the other. I'm saying the following: 1) Keeping group and category functionality in rpm's spec file is going to be deprecated for Fedora. 2) rpm doesn't have any business reading an external xml file from the repository. Therefore any Group functionality added to rpm now, should be implemented outside of rpm when we get Categories. As long as you're okay with the functionality that you're currently implementing being moved to another tool (for instance, yum or a program in yum-utils) then I'm okay with this. > In any case, I am not trying to add any new switch or functionality, > just fix an existing one that has an annoying shortcoming ('rpm -q > --group' does not take a regexp/glob). > That's fine. Like I say I'm not judging how likely it'll get into rpm, just that the functionality probably needs to live in another tool when we move to categories. > > >> b) yum has already some group functionality (groupinstall, groupupdate, > >> groupremove, groupinfo) that is based on an XML file that is kept in the > >> repository. But the option --exclude only acts on file names, we need a > >> --groupexclude. > >> > >> We already have a "Java" group, with only 2 packages on it: > >> > >> # yum groupinfo Java > >> Loading "installonlyn" plugin > >> Setting up Group Process > >> Setting up repositories > >> > >> Group: Java > >> Description: Support for running programs written in the Java > >> programming language. > >> Mandatory Packages: > >> libgcj > >> java-1.4.2-gcj-compat > >> > > If I understood spot's summary of your requirements, you want to > > categorize all the packages you are importing from jpackage. I would > > point out that the java group would be a poor place to implement that as > > any java packages which did not come through jpackage could also > > legitimately be placed in there. > > > > We actually want all Java packages. They are always extremely > interrelated, with cascading effects among them, so they need to be > treated as a whole. Any Java package should be in there. > Okay. My misunderstanding then. [snip] > >> > > One controversy with using the yum group functionality for this is that > > it uses comps.xml to achieve its ends. Jeremy Katz is against using > > comps.xml to make categories that shouldn't be visible to the installer. > > skvidal has shown how we could have multiple comps.xml files that yum > > reads (whereas the installer only reads from one) which addresses a few > > of Jeremy's concerns. When we go ahead with this we'll have to work out > > whether we're going to store the information in a comps file or teach > > yum about a new grouping file format. > > > > In any case, there will be always something for groupinstall, > groupupdate, groupremove, groupinfo and also a --groupexclude to do the > selection. Yep. Just letting you know if you're doing some hacking in this area to be aware that the backend could change here. And it's early in the process so you can be a part of making this decision as well. -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 dlutter at redhat.com Thu Jan 18 19:14:34 2007 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 18 Jan 2007 11:14:34 -0800 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <45AF8005.8020003@redhat.com> References: <45AE93E5.8030900@redhat.com> <1169095063.4377.75.camel@cutter> <45AF8005.8020003@redhat.com> Message-ID: <1169147675.12189.40.camel@localhost.localdomain> On Thu, 2007-01-18 at 09:11 -0500, Fernando Nasser wrote: > seth vidal wrote: > > > > why do you need a 'groupexclude' option? I guess I don't understand the > > use case for it, yet. > > > > For instance, to upgrade one's Fedora system without interfering with > the Java stack there. What happens to your Java stack at that point ? Will it just stay frozen ? David From fnasser at redhat.com Thu Jan 18 20:51:39 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 18 Jan 2007 15:51:39 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <1169144837.14225.78.camel@localhost.localdomain> References: <45AE93E5.8030900@redhat.com> <1169103772.14225.38.camel@localhost.localdomain> <45AF83A0.8090600@redhat.com> <1169144837.14225.78.camel@localhost.localdomain> Message-ID: <45AFDDDB.7000505@redhat.com> Toshio Kuratomi wrote: (...) >> You missed the "P.S." >> >> I am creating a patch for Groups because Categories are not there yet, >> so I can't do anything for it ATM. Once Groups are abandoned in favor >> of Categories, the functionality available for Groups must be adapted to >> work with Categories instead. >> >> > I read that but perhaps one of us is misinterpreting the other. I'm > saying the following: > 1) Keeping group and category functionality in rpm's spec file is going > to be deprecated for Fedora. > Oh, I thought the Group functionality was being deprecated but we would have a Category one to replace it (where packages could belong to many instead of a single one). So I did misunderstood that. I even thought you wanted to store the Categories in the RPM database. If that was the case it was just a different Query (on Categories instead of Groups, and I would not even need a glob pattern in that case). > 2) rpm doesn't have any business reading an external xml file from the > repository. > > Therefore any Group functionality added to rpm now, should be > implemented outside of rpm when we get Categories. As long as you're > okay with the functionality that you're currently implementing being > moved to another tool (for instance, yum or a program in yum-utils) then > I'm okay with this. > > That is what I haven't understood. It doesn't have to be in rpm at all, anything that produces the list of packages in that Category can be used. >> In any case, I am not trying to add any new switch or functionality, >> just fix an existing one that has an annoying shortcoming ('rpm -q >> --group' does not take a regexp/glob). >> >> > That's fine. Like I say I'm not judging how likely it'll get into rpm, > just that the functionality probably needs to live in another tool when > we move to categories. > It is OK. I was just trying to accelerate things but perhaps it would be wise to wait a little bit, Are we removing the Groups table from the database? > (...) >>> One controversy with using the yum group functionality for this is that >>> it uses comps.xml to achieve its ends. Jeremy Katz is against using >>> comps.xml to make categories that shouldn't be visible to the installer. >>> skvidal has shown how we could have multiple comps.xml files that yum >>> reads (whereas the installer only reads from one) which addresses a few >>> of Jeremy's concerns. When we go ahead with this we'll have to work out >>> whether we're going to store the information in a comps file or teach >>> yum about a new grouping file format. >>> >>> >> In any case, there will be always something for groupinstall, >> groupupdate, groupremove, groupinfo and also a --groupexclude to do the >> selection. >> > > Yep. Just letting you know if you're doing some hacking in this area to > be aware that the backend could change here. And it's early in the > process so you can be a part of making this decision as well. > > Is that wiki page you've pointed us to the only place to watch ATM? http://www.fedoraproject.org/wiki/Extras/SIGs/Comps/PackageGroupEnhancements Regards, Fernando From fnasser at redhat.com Thu Jan 18 22:59:48 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 18 Jan 2007 17:59:48 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <1169147675.12189.40.camel@localhost.localdomain> References: <45AE93E5.8030900@redhat.com> <1169095063.4377.75.camel@cutter> <45AF8005.8020003@redhat.com> <1169147675.12189.40.camel@localhost.localdomain> Message-ID: <45AFFBE4.8010506@redhat.com> David Lutterkort wrote: > On Thu, 2007-01-18 at 09:11 -0500, Fernando Nasser wrote: >> seth vidal wrote: >>> why do you need a 'groupexclude' option? I guess I don't understand the >>> use case for it, yet. >>> >> For instance, to upgrade one's Fedora system without interfering with >> the Java stack there. > > What happens to your Java stack at that point ? Will it just stay > frozen ? > That is the idea, update your Fedora system except for the Java packages, which you can update selectively, from a different repo, from local RPMs etc. From a.badger at gmail.com Thu Jan 18 23:15:28 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 18 Jan 2007 15:15:28 -0800 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <45AFDDDB.7000505@redhat.com> References: <45AE93E5.8030900@redhat.com> <1169103772.14225.38.camel@localhost.localdomain> <45AF83A0.8090600@redhat.com> <1169144837.14225.78.camel@localhost.localdomain> <45AFDDDB.7000505@redhat.com> Message-ID: <1169162128.14225.145.camel@localhost.localdomain> On Thu, 2007-01-18 at 15:51 -0500, Fernando Nasser wrote: > Toshio Kuratomi wrote: > > Therefore any Group functionality added to rpm now, should be > > implemented outside of rpm when we get Categories. As long as you're > > okay with the functionality that you're currently implementing being > > moved to another tool (for instance, yum or a program in yum-utils) then > > I'm okay with this. > > > > > That is what I haven't understood. It doesn't have to be in rpm at all, > anything that produces the list of packages in that Category can be used. > Cool. No objections from me then. > > >> In any case, I am not trying to add any new switch or functionality, > >> just fix an existing one that has an annoying shortcoming ('rpm -q > >> --group' does not take a regexp/glob). > >> > >> > > That's fine. Like I say I'm not judging how likely it'll get into rpm, > > just that the functionality probably needs to live in another tool when > > we move to categories. > > > It is OK. I was just trying to accelerate things but perhaps it would > be wise to wait a little bit, > > Are we removing the Groups table from the database? > The way this is looking is that we'll be making the Group tag optional when building rpms. We'll port our tools to use the external Categories file instead. We'll encourage or help port third party tools (like apt and smart) to to be able to use the external file as well. The group table in the database will still be there but there won't be any guarantees that it holds useful information. > > Yep. Just letting you know if you're doing some hacking in this area to > > be aware that the backend could change here. And it's early in the > > process so you can be a part of making this decision as well. > > > > > Is that wiki page you've pointed us to the only place to watch ATM? > > http://www.fedoraproject.org/wiki/Extras/SIGs/Comps/PackageGroupEnhancements Unfortunately it's the only place on the wiki that has information but there's currently no place that's focusing the efforts. The Packaging Committee and FESCo have discussed dropping the Group tag and have authorized rpm to allow packages without the Group tag, but no change to the Guidelines has been made to allow approving packages without the Group Tag. We want the alternative categorization infrastructure to exist first. The alternative is likely to be enabled via the package db so some effort is going in there. However, the deployment that depsolvers see needs to use a file in the repository rather than an SQL database. This is where using comps.xml or a separate format comes in. This ties into yum as yum will need to work with whatever file format is chosen. -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 skvidal at linux.duke.edu Fri Jan 19 01:05:26 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 18 Jan 2007 20:05:26 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <45AFFBE4.8010506@redhat.com> References: <45AE93E5.8030900@redhat.com> <1169095063.4377.75.camel@cutter> <45AF8005.8020003@redhat.com> <1169147675.12189.40.camel@localhost.localdomain> <45AFFBE4.8010506@redhat.com> Message-ID: <1169168726.4377.105.camel@cutter> On Thu, 2007-01-18 at 17:59 -0500, Fernando Nasser wrote: > David Lutterkort wrote: > > On Thu, 2007-01-18 at 09:11 -0500, Fernando Nasser wrote: > >> seth vidal wrote: > >>> why do you need a 'groupexclude' option? I guess I don't understand the > >>> use case for it, yet. > >>> > >> For instance, to upgrade one's Fedora system without interfering with > >> the Java stack there. > > > > What happens to your Java stack at that point ? Will it just stay > > frozen ? > > > > That is the idea, update your Fedora system except for the Java > packages, which you can update selectively, from a different repo, from > local RPMs etc. > so you want --groupexclude to exclude from the update all packages in that group? Not exclude the group from the list of available groups? -sv From tcallawa at redhat.com Fri Jan 19 01:07:20 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 18 Jan 2007 19:07:20 -0600 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <1169168726.4377.105.camel@cutter> References: <45AE93E5.8030900@redhat.com> <1169095063.4377.75.camel@cutter> <45AF8005.8020003@redhat.com> <1169147675.12189.40.camel@localhost.localdomain> <45AFFBE4.8010506@redhat.com> <1169168726.4377.105.camel@cutter> Message-ID: <1169168840.26750.10.camel@localhost.localdomain> On Thu, 2007-01-18 at 20:05 -0500, seth vidal wrote: > On Thu, 2007-01-18 at 17:59 -0500, Fernando Nasser wrote: > > David Lutterkort wrote: > > > On Thu, 2007-01-18 at 09:11 -0500, Fernando Nasser wrote: > > >> seth vidal wrote: > > >>> why do you need a 'groupexclude' option? I guess I don't understand the > > >>> use case for it, yet. > > >>> > > >> For instance, to upgrade one's Fedora system without interfering with > > >> the Java stack there. > > > > > > What happens to your Java stack at that point ? Will it just stay > > > frozen ? > > > > > > > That is the idea, update your Fedora system except for the Java > > packages, which you can update selectively, from a different repo, from > > local RPMs etc. > > > > so you want --groupexclude to exclude from the update all packages in > that group? Not exclude the group from the list of available groups? Yep. I'm pretty sure that's what he's looking to do. ~spot From a.badger at gmail.com Fri Jan 19 04:48:38 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 18 Jan 2007 20:48:38 -0800 Subject: [Fedora-packaging] Re: LibtoolArchives, v0.3 In-Reply-To: <20070117162527.GB8563@nostromo.devel.redhat.com> References: <45AE31C5.5080602@math.unl.edu> <20070117152736.GJ26437@neu.nirvana> <45AE473C.7050105@math.unl.edu> <20070117162527.GB8563@nostromo.devel.redhat.com> Message-ID: <1169182118.14225.175.camel@localhost.localdomain> On Wed, 2007-01-17 at 11:25 -0500, Bill Nottingham wrote: > Rex Dieter (rdieter at math.unl.edu) said: > > AFAIK, the only unknown up to this point was kde, which I've found it is > > fixable (runtime, at least). I'm aware of no other cases where .la > > files are required for runtime function. > > gnucash has its own custom module system built on top of libltdl; > it is very unhappy without them. It's probably hackable to work, > but as there's already a branch on the trunk that ports it all > to gmodule, I'm not that interested in looking at it outside > of possibly backporting that branch. A quick glance at the source looks like there's less than ten places in gncmodule.c that require changing. But I think that what you're pointing out makes a good general guideline -- we're working to fix these cases upstream. If upstream has a fix but it's in their development branch (gnucash-cvs, kde4) then we could make a specific exception to the guideline for that software with the note that the fix will be in release x.0. The only question would be how long we would be willing to wait for that update rather than backporting/fixing the problem in the current version. -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 mwringe at redhat.com Fri Jan 19 15:38:27 2007 From: mwringe at redhat.com (Matt Wringe) Date: Fri, 19 Jan 2007 10:38:27 -0500 Subject: [Fedora-packaging] Upstream sources that contain binaries Message-ID: <1169221107.32475.19.camel@toque.toronto.redhat.com> Hi, What is the proper way to handle upstream source tars that also contain binary dependencies? This is very common with java packages. Sorry if this is already covered in the guidelines, I couldn't find this case mentioned anywhere. Should the binaries be removed from the source tar and create a new binary-less tar. This method has been used in the past, resulting in new tars with -RHCLEAN added to the end of their names. Or should the tar just be left alone, and have the a script inside the spec scrub out the binaries? According to the Review Guidelines: "The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task." (http://fedoraproject.org/wiki/Packaging/ReviewGuidelines) Thanks, Matt Wringe From fnasser at redhat.com Fri Jan 19 15:45:06 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 19 Jan 2007 10:45:06 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <1169168840.26750.10.camel@localhost.localdomain> References: <45AE93E5.8030900@redhat.com> <1169095063.4377.75.camel@cutter> <45AF8005.8020003@redhat.com> <1169147675.12189.40.camel@localhost.localdomain> <45AFFBE4.8010506@redhat.com> <1169168726.4377.105.camel@cutter> <1169168840.26750.10.camel@localhost.localdomain> Message-ID: <45B0E782.4020604@redhat.com> Tom 'spot' Callaway wrote: > On Thu, 2007-01-18 at 20:05 -0500, seth vidal wrote: >> On Thu, 2007-01-18 at 17:59 -0500, Fernando Nasser wrote: >>> David Lutterkort wrote: >>>> On Thu, 2007-01-18 at 09:11 -0500, Fernando Nasser wrote: >>>>> seth vidal wrote: >>>>>> why do you need a 'groupexclude' option? I guess I don't understand the >>>>>> use case for it, yet. >>>>>> >>>>> For instance, to upgrade one's Fedora system without interfering with >>>>> the Java stack there. >>>> What happens to your Java stack at that point ? Will it just stay >>>> frozen ? >>>> >>> That is the idea, update your Fedora system except for the Java >>> packages, which you can update selectively, from a different repo, from >>> local RPMs etc. >>> >> so you want --groupexclude to exclude from the update all packages in >> that group? Not exclude the group from the list of available groups? > > Yep. I'm pretty sure that's what he's looking to do. > Correct. From tcallawa at redhat.com Fri Jan 19 15:45:46 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 19 Jan 2007 09:45:46 -0600 Subject: [Fedora-packaging] Upstream sources that contain binaries In-Reply-To: <1169221107.32475.19.camel@toque.toronto.redhat.com> References: <1169221107.32475.19.camel@toque.toronto.redhat.com> Message-ID: <1169221546.10730.1.camel@localhost.localdomain> On Fri, 2007-01-19 at 10:38 -0500, Matt Wringe wrote: > Hi, > > What is the proper way to handle upstream source tars that also contain > binary dependencies? This is very common with java packages. > > Sorry if this is already covered in the guidelines, I couldn't find this > case mentioned anywhere. > > Should the binaries be removed from the source tar and create a new > binary-less tar. This method has been used in the past, resulting in new > tars with -RHCLEAN added to the end of their names. > > Or should the tar just be left alone, and have the a script inside the > spec scrub out the binaries? You shouldn't need to alter the tar, unless those binaries are illegal somehow. Have the spec remove the binaries in %setup, immediately after unpacking. The -RHCLEAN cases were when the tarball contained infringing/forbidden items. ~spot From ville.skytta at iki.fi Sun Jan 21 15:03:17 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 21 Jan 2007 17:03:17 +0200 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: <1168976758.22112.11.camel@localhost.localdomain> References: <1168976758.22112.11.camel@localhost.localdomain> Message-ID: <200701211703.17722.ville.skytta@iki.fi> On Tuesday 16 January 2007 21:45, Tom 'spot' Callaway wrote: > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts I still don't think that the suggested way of handling library name conflicts (or more specifically, the ld.so.conf part of it) makes sense. http://www.redhat.com/archives/fedora-packaging/2006-December/msg00060.html From tcallawa at redhat.com Sun Jan 21 15:53:19 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 21 Jan 2007 09:53:19 -0600 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: <200701211703.17722.ville.skytta@iki.fi> References: <1168976758.22112.11.camel@localhost.localdomain> <200701211703.17722.ville.skytta@iki.fi> Message-ID: <1169394799.10857.50.camel@localhost.localdomain> On Sun, 2007-01-21 at 17:03 +0200, Ville Skytt? wrote: > On Tuesday 16 January 2007 21:45, Tom 'spot' Callaway wrote: > > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > > I still don't think that the suggested way of handling library name conflicts > (or more specifically, the ld.so.conf part of it) makes sense. > > http://www.redhat.com/archives/fedora-packaging/2006-December/msg00060.html OK. Do you have any ideas on how we should handle this? This was the only idea I could come up with, but I can see the flaw in it. ~spot From rc040203 at freenet.de Sun Jan 21 17:00:55 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 21 Jan 2007 18:00:55 +0100 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: <1169394799.10857.50.camel@localhost.localdomain> References: <1168976758.22112.11.camel@localhost.localdomain> <200701211703.17722.ville.skytta@iki.fi> <1169394799.10857.50.camel@localhost.localdomain> Message-ID: <1169398855.19080.307.camel@mccallum.corsepiu.local> On Sun, 2007-01-21 at 09:53 -0600, Tom 'spot' Callaway wrote: > On Sun, 2007-01-21 at 17:03 +0200, Ville Skytt? wrote: > > On Tuesday 16 January 2007 21:45, Tom 'spot' Callaway wrote: > > > > > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > > > > I still don't think that the suggested way of handling library name conflicts > > (or more specifically, the ld.so.conf part of it) makes sense. > > > > http://www.redhat.com/archives/fedora-packaging/2006-December/msg00060.html > > > OK. Do you have any ideas on how we should handle this? This was the > only idea I could come up with, but I can see the flaw in it. That's exactly the situation rpath is being designed for. /me ducks and hides. Ralf From fedora at leemhuis.info Sun Jan 21 17:29:37 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 21 Jan 2007 18:29:37 +0100 Subject: [Fedora-packaging] Conflicts Draft Proposal Round 2 In-Reply-To: <1169398855.19080.307.camel@mccallum.corsepiu.local> References: <1168976758.22112.11.camel@localhost.localdomain> <200701211703.17722.ville.skytta@iki.fi> <1169394799.10857.50.camel@localhost.localdomain> <1169398855.19080.307.camel@mccallum.corsepiu.local> Message-ID: <45B3A301.3020308@leemhuis.info> Ralf Corsepius schrieb: > On Sun, 2007-01-21 at 09:53 -0600, Tom 'spot' Callaway wrote: >> On Sun, 2007-01-21 at 17:03 +0200, Ville Skytt? wrote: >>> On Tuesday 16 January 2007 21:45, Tom 'spot' Callaway wrote: >>>> http://fedoraproject.org/wiki/PackagingDrafts/Conflicts >>> I still don't think that the suggested way of handling library name conflicts >>> (or more specifically, the ld.so.conf part of it) makes sense. >>> http://www.redhat.com/archives/fedora-packaging/2006-December/msg00060.html >> OK. Do you have any ideas on how we should handle this? This was the >> only idea I could come up with, but I can see the flaw in it. > That's exactly the situation rpath is being designed for. > /me ducks and hides. Hehe :) I'd suggest we put the upstream developers of affected packages into one small room and leave them there without food until at least one of them agrees to change the name of the conflicting files. /me runs Well, or in a more diplomatic tone: {{{ In case of library name file conflicts the packager should contact upstream of both affected packages and urge them to find a solution that gets the problem solved once and for all as that's better for everyone and solves the problem for all other distributions, too. }}} I'd suggest we put something like that into the proposal and ignore the general problem for now. We can work out solutions for individual problems as we hit them in case upstream is unwilling to cooperate. BTW, does anybody know what is debian doing in such cases? CU thl From dlutter at redhat.com Mon Jan 22 20:02:29 2007 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 22 Jan 2007 20:02:29 +0000 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <1169168726.4377.105.camel@cutter> References: <45AE93E5.8030900@redhat.com> <1169095063.4377.75.camel@cutter> <45AF8005.8020003@redhat.com> <1169147675.12189.40.camel@localhost.localdomain> <45AFFBE4.8010506@redhat.com> <1169168726.4377.105.camel@cutter> Message-ID: <1169496149.3445.48.camel@localhost.localdomain> On Thu, 2007-01-18 at 20:05 -0500, seth vidal wrote: > On Thu, 2007-01-18 at 17:59 -0500, Fernando Nasser wrote: > > David Lutterkort wrote: > > > On Thu, 2007-01-18 at 09:11 -0500, Fernando Nasser wrote: > > >> seth vidal wrote: > > >>> why do you need a 'groupexclude' option? I guess I don't understand the > > >>> use case for it, yet. > > >>> > > >> For instance, to upgrade one's Fedora system without interfering with > > >> the Java stack there. > > > > > > What happens to your Java stack at that point ? Will it just stay > > > frozen ? > > > > > > > That is the idea, update your Fedora system except for the Java > > packages, which you can update selectively, from a different repo, from > > local RPMs etc. > > > > so you want --groupexclude to exclude from the update all packages in > that group? Not exclude the group from the list of available groups? This is starting to be OT for this list, but wouldn't it be better if users could just add groups into the existing mechanisms with a separate notation, similar to kickstart ? I.e., instead of a separate --groupexclude, allow --exclude=@java ? David From skvidal at linux.duke.edu Mon Jan 22 20:14:11 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 22 Jan 2007 15:14:11 -0500 Subject: [Fedora-packaging] Java naming scheme In-Reply-To: <1169496149.3445.48.camel@localhost.localdomain> References: <45AE93E5.8030900@redhat.com> <1169095063.4377.75.camel@cutter> <45AF8005.8020003@redhat.com> <1169147675.12189.40.camel@localhost.localdomain> <45AFFBE4.8010506@redhat.com> <1169168726.4377.105.camel@cutter> <1169496149.3445.48.camel@localhost.localdomain> Message-ID: <1169496851.5309.39.camel@cutter> On Mon, 2007-01-22 at 20:02 +0000, David Lutterkort wrote: > On Thu, 2007-01-18 at 20:05 -0500, seth vidal wrote: > > On Thu, 2007-01-18 at 17:59 -0500, Fernando Nasser wrote: > > > David Lutterkort wrote: > > > > On Thu, 2007-01-18 at 09:11 -0500, Fernando Nasser wrote: > > > >> seth vidal wrote: > > > >>> why do you need a 'groupexclude' option? I guess I don't understand the > > > >>> use case for it, yet. > > > >>> > > > >> For instance, to upgrade one's Fedora system without interfering with > > > >> the Java stack there. > > > > > > > > What happens to your Java stack at that point ? Will it just stay > > > > frozen ? > > > > > > > > > > That is the idea, update your Fedora system except for the Java > > > packages, which you can update selectively, from a different repo, from > > > local RPMs etc. > > > > > > > so you want --groupexclude to exclude from the update all packages in > > that group? Not exclude the group from the list of available groups? > > This is starting to be OT for this list, but wouldn't it be better if > users could just add groups into the existing mechanisms with a separate > notation, similar to kickstart ? I.e., instead of a separate > --groupexclude, allow --exclude=@java ? > I don't terribly like special character delimiters like that. -sv From mclasen at redhat.com Thu Jan 25 13:22:30 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 25 Jan 2007 08:22:30 -0500 Subject: [Fedora-packaging] erroneous provides Message-ID: <1169731350.3289.8.camel@dhcp83-33.boston.redhat.com> Hey, Yesterday I stumbled over an interesting dependency mishap wrt to Inkscape: it is pulling in wxGTK, even though it is not using that toolkit. This was caused by an unintended (automatic) provides in some perl package ( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224238 ). This made me think that it would be a good idea to add an item to the package review to check the list of provides for sanity, much like we have an item to check for unintended directory ownerships. Also, it would be great to do a "duplicate provides" review of the whole repository, but I'm currently at a loss of knowledge about good tools for such a thing. What is the best tool to enumerate the full package/provides matrix for a repository ? Matthias From mclasen at redhat.com Fri Jan 26 06:11:33 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 26 Jan 2007 01:11:33 -0500 Subject: [Fedora-packaging] erroneous provides Message-ID: <1169791893.3376.20.camel@localhost.localdomain> I have looked a bit at the provides in Core, and after a bit of creative repoquery use, came up with the list of duplicate provides below. A bunch of them is intentional, like smtpdaemon, webclient or php_database. The bulk of it is due to non-library DSOs and is probably relatively harmless. Some of them may be real errors, like libmpi.so.0, perl(Class::Struct::Tie_ISA). So it looks like things are in relatively good shape in Core. I haven't completed the same analysis for Core+Extras. A couple of questions come out of this excercise: 1) Why does rpm keep all those non-library DSOs as provides ? Thats blowing up the list of provides significantly, causing a lot of duplicates, and is unlikely to ever be used for ever satisfying a requires, unless it is in error (e.g. see libsvg.so in the list) 2) Is rpm smart enough to disambiguate provides based on the full path, or is a provides for libsvg.so that lives in /usr/lib/compiz/libsvg.so going to be used to satisfy a requires for a shared library with the same name ? I guess this will rarely be a problem, since the shared library requirement will be against something like libsvg.so.4. Matthias Finally, the list: postgresql-contrib: autoinc.so postgresql-test: autoinc.so mod_perl: Base64.so perl: Base64.so samba: cap.so zsh: cap.so aqbanking: csv.so.0 gwenhywfar: csv.so.0 python: datetime.so zsh: datetime.so xen: fsimage.so xen-libs: fsimage.so mailman: hangul.so scim-hangul: hangul.so rhpl: iconv.so ruby-libs: iconv.so scim-bridge-gtk: im-scim-bridge.so scim-bridge-qt: im-scim-bridge.so gnu-crypto-sasl-jdk1.4: java-sasl java-1.4.2-gcj-compat: java-sasl java-1.4.2-gcj-compat: jaxp_parser_impl xerces-j2: jaxp_parser_impl mkinitrd: libbdevid.so.6.0.6 nash: libbdevid.so.6.0.6 lam-libs: libmpi.so.0 openmpi-libs: libmpi.so.0 compiz: libsvg.so librsvg2: libsvg.so perl-DBD-MySQL: mysql.so php-mysql: mysql.so ccid: pcsc-ifd-handler ifd-egate: pcsc-ifd-handler automake15: perl(Class::Struct::Tie_ISA) perl: perl(Class::Struct::Tie_ISA) perl-Carp-Clan: perl(DB) perl: perl(DB) gaim: perl.so xchat: perl.so python: pyexpat.so PyXML: pyexpat.so python: readline.so ruby-libs: readline.so postgresql-contrib: refint.so postgresql-test: refint.so perl-PDL: RNG.so python-numeric: RNG.so postfix: smtpdaemon sendmail: smtpdaemon mod_perl: Socket.so perl: Socket.so perl-Crypt-SSLeay: SSLeay.so perl-Net-SSLeay: SSLeay.so perl-PDL: Storable.so perl: Storable.so python: syslog.so ruby-libs: syslog.so postfix: /usr/bin/mailq sendmail: /usr/bin/mailq postfix: /usr/bin/newaliases sendmail: /usr/bin/newaliases postfix: /usr/bin/rmail sendmail: /usr/bin/rmail postfix: /usr/sbin/sendmail sendmail: /usr/sbin/sendmail mod_perl: Util.so perl: Util.so ImageMagick: xc.so xen: xc.so php-mysql: php_database php-odbc: php_database php-pgsql: php_database selinux-policy-mls: selinux-policy-base selinux-policy-strict: selinux-policy-base selinux-policy-targeted: selinux-policy-base gnome-python2-bonobo: ui.so gnome-python2-gnomeprint: ui.so gnome-python2: ui.so ruby-libs: socket.so scim-libs: socket.so scim: socket.so zsh: socket.so elinks: webclient firefox: webclient lynx: webclient w3m: webclient wget: webclient From pertusus at free.fr Fri Jan 26 10:11:28 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 26 Jan 2007 11:11:28 +0100 Subject: [Fedora-packaging] erroneous provides In-Reply-To: <1169791893.3376.20.camel@localhost.localdomain> References: <1169791893.3376.20.camel@localhost.localdomain> Message-ID: <20070126101128.GA2681@free.fr> On Fri, Jan 26, 2007 at 01:11:33AM -0500, Matthias Clasen wrote: > 1) Why does rpm keep all those non-library DSOs as provides ? Thats > blowing up the list of provides significantly, causing a lot of > duplicates, and is unlikely to ever be used for ever satisfying a > requires, unless it is in error (e.g. see libsvg.so in the list) In /usr/lib/rpm/find-provides the list of files is constructed by using solist=$(echo $filelist | grep "\\.so" | grep -v "^/lib/ld.so" | \ xargs file -L 2>/dev/null | grep "ELF.*shared object" | cut -d: -f1) > 2) Is rpm smart enough to disambiguate provides based on the full path, > or is a provides for libsvg.so that lives in /usr/lib/compiz/libsvg.so > going to be used to satisfy a requires for a shared library with the > same name ? I guess this will rarely be a problem, since the shared > library requirement will be against something like libsvg.so.4. In general it is not a problem, but I think that this should be avoided. It has been already pointed out in lists, and in numerous package submissions (I always look for sane provides and for perl packages there are the 'usual bogusprovides on .so files'). I just have filled a bug against rpm: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224544 Another possible solution would be to avoid setting the SONAME for the files that are only to be dlopened. libtool always set the soname, and it seems to be the same for perl. Maybe this is where things should be fixed? -- Pat From rc040203 at freenet.de Fri Jan 26 10:48:31 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 26 Jan 2007 11:48:31 +0100 Subject: [Fedora-packaging] erroneous provides In-Reply-To: <20070126101128.GA2681@free.fr> References: <1169791893.3376.20.camel@localhost.localdomain> <20070126101128.GA2681@free.fr> Message-ID: <1169808511.5838.111.camel@mccallum.corsepiu.local> On Fri, 2007-01-26 at 11:11 +0100, Patrice Dumas wrote: > On Fri, Jan 26, 2007 at 01:11:33AM -0500, Matthias Clasen wrote: > In general it is not a problem, but I think that this should be avoided. In most cases this is not a problem for RH/Fedora. But it is a problem outside of RH/Fedora, e.g. for 3rd party packages designed for parallel installation, containing DSOs with the same names as Fedora. > It has been already pointed out in lists, and in numerous package > submissions (I always look for sane provides and for perl packages > there are the 'usual bogusprovides on .so files'). I just have filled a > bug against rpm: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224544 > > Another possible solution would be to avoid setting the SONAME for the > files that are only to be dlopened. libtool always set the soname, and it > seems to be the same for perl. Maybe this is where things should be > fixed? Nope, the bug is in rpmbuild rsp. redhat-rpm-config. They produce invalid results. Ralf From mclasen at redhat.com Fri Jan 26 15:29:45 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 26 Jan 2007 10:29:45 -0500 Subject: [Fedora-packaging] erroneous provides In-Reply-To: <1169808511.5838.111.camel@mccallum.corsepiu.local> References: <1169791893.3376.20.camel@localhost.localdomain> <20070126101128.GA2681@free.fr> <1169808511.5838.111.camel@mccallum.corsepiu.local> Message-ID: <1169825386.17555.4.camel@golem.boston.devel.redhat.com> To justify the time I invested in this excercise, I filed bugs for a few of the more obviously wrong cases: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224569 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224571 So, how does this list like the idea of adding a bulletpoint for "sane provides" to the package review guidelines ? From jkeating at redhat.com Fri Jan 26 15:45:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 Jan 2007 10:45:01 -0500 Subject: [Fedora-packaging] erroneous provides In-Reply-To: <1169825386.17555.4.camel@golem.boston.devel.redhat.com> References: <1169791893.3376.20.camel@localhost.localdomain> <1169808511.5838.111.camel@mccallum.corsepiu.local> <1169825386.17555.4.camel@golem.boston.devel.redhat.com> Message-ID: <200701261045.02061.jkeating@redhat.com> On Friday 26 January 2007 10:29, Matthias Clasen wrote: > So, how does this list like the idea of adding a bulletpoint for > "sane provides" to the package review guidelines ? I like it. However, defining 'sane provides' might prove difficult, but if you have pointers or a draft bullet point I'd gladly read 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 mclasen at redhat.com Fri Jan 26 16:04:35 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 26 Jan 2007 11:04:35 -0500 Subject: [Fedora-packaging] erroneous provides In-Reply-To: <200701261045.02061.jkeating@redhat.com> References: <1169791893.3376.20.camel@localhost.localdomain> <1169808511.5838.111.camel@mccallum.corsepiu.local> <1169825386.17555.4.camel@golem.boston.devel.redhat.com> <200701261045.02061.jkeating@redhat.com> Message-ID: <1169827475.17555.8.camel@golem.boston.devel.redhat.com> On Fri, 2007-01-26 at 10:45 -0500, Jesse Keating wrote: > On Friday 26 January 2007 10:29, Matthias Clasen wrote: > > So, how does this list like the idea of adding a bulletpoint for > > "sane provides" to the package review guidelines ? > > I like it. However, defining 'sane provides' might prove difficult, but if > you have pointers or a draft bullet point I'd gladly read it (: Its hard to make that very precise, but it should mean something like Look at the list of provides and verify that all of them are intentional. Use repoquery to check if other packages already provide the same thing, and if so, look closer. This is generally ok if the provides is for a .so that lives outside of LIBDIR, otherwise it indicates a potential problem. From tibbs at math.uh.edu Fri Jan 26 16:07:20 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Jan 2007 10:07:20 -0600 Subject: [Fedora-packaging] erroneous provides In-Reply-To: <1169825386.17555.4.camel@golem.boston.devel.redhat.com> References: <1169791893.3376.20.camel@localhost.localdomain> <20070126101128.GA2681@free.fr> <1169808511.5838.111.camel@mccallum.corsepiu.local> <1169825386.17555.4.camel@golem.boston.devel.redhat.com> Message-ID: >>>>> "MC" == Matthias Clasen writes: MC> So, how does this list like the idea of adding a bulletpoint for MC> "sane provides" to the package review guidelines ? I have always checked these in my reviews; I list out the dependencies so that others who happen to peruse the reviews can perhaps spot anything that I miss. It's caught problems in the past. Of course, as others have pointed out, it's tough to define "sane". I generally know a bogus provide when I see one, but I don't think I could list out all of the criteria. - J< From notting at redhat.com Fri Jan 26 18:12:32 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 26 Jan 2007 13:12:32 -0500 Subject: [Fedora-packaging] erroneous provides In-Reply-To: <1169827475.17555.8.camel@golem.boston.devel.redhat.com> References: <1169791893.3376.20.camel@localhost.localdomain> <1169808511.5838.111.camel@mccallum.corsepiu.local> <1169825386.17555.4.camel@golem.boston.devel.redhat.com> <200701261045.02061.jkeating@redhat.com> <1169827475.17555.8.camel@golem.boston.devel.redhat.com> Message-ID: <20070126181232.GE28065@nostromo.devel.redhat.com> Matthias Clasen (mclasen at redhat.com) said: > Its hard to make that very precise, but it should mean something like > > Look at the list of provides and verify that all of them are > intentional. Use repoquery to check if other packages already provide > the same thing, and if so, look closer. This is generally ok if > the provides is for a .so that lives outside of LIBDIR, otherwise > it indicates a potential problem. Maybe also: If your package provides perl(), and either: a) your package is not a perl module - or - b) your package is not named the same it is almost certainly a bug. Bill From rc040203 at freenet.de Sat Jan 27 03:28:31 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 27 Jan 2007 04:28:31 +0100 Subject: [Fedora-packaging] erroneous provides In-Reply-To: <1169825386.17555.4.camel@golem.boston.devel.redhat.com> References: <1169791893.3376.20.camel@localhost.localdomain> <20070126101128.GA2681@free.fr> <1169808511.5838.111.camel@mccallum.corsepiu.local> <1169825386.17555.4.camel@golem.boston.devel.redhat.com> Message-ID: <1169868512.5838.129.camel@mccallum.corsepiu.local> On Fri, 2007-01-26 at 10:29 -0500, Matthias Clasen wrote: > To justify the time I invested in this excercise, I filed bugs for a few > of the more obviously wrong cases: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224569 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224571 IMO, these are different cases, with similar symptoms, but with different causes than the "bogus DSO/shared lib 'Provides'". I think, 1. The ".so provides" should be tied to "ld.so's library search path" 2. The "perl() provides" (BZ 224569) should be tied to Perl's "module search-path". 3. BZ 224571 sounds like a bug in rpm's perl-reqprov filtering (Which is known to be pretty underdeveloped/immature and to quite frequently generate bogus/missing provide/requires) I know, many people will disagree, but IMO, 1+2 would not be an issue if rpm was using absolute filenames to DSO's/modules instead of virtual provides. > So, how does this list like the idea of adding a bulletpoint for > "sane provides" to the package review guidelines ? Could you elaborate? I don't understand. Ralf From ville.skytta at iki.fi Sat Jan 27 08:47:49 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 27 Jan 2007 10:47:49 +0200 Subject: [Fedora-packaging] Unused direct shared library dependencies and rpmlint Message-ID: <200701271047.49334.ville.skytta@iki.fi> Hi, Inspired by http://www.redhat.com/archives/fedora-maintainers/2006-June/msg00176.html, I've had a patch for rpmlint in my local tree for a while which checks for unused direct shared library dependencies in shared libs. I'm wondering whether this check is a good idea; I'm not an expert in this area and the check does produce quite a bit of output on some packages. Comments very much welcome. At the moment I'm leaning towards including this in the next rpmlint release anyway. For the adventurous, grab the latest rpmlint from svn (see http://rpmlint.zarb.org/cgi-bin/trac.cgi/browser/trunk/README.devel) and apply the attached patch to BinariesCheck.py. Example output: $ rpmlint krb5-libs | grep shlib W: krb5-libs unused-direct-shlib-dependency /usr/lib/libkrb5support.so.0.1 /lib/libresolv.so.2 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libk5crypto.so.3.0 /lib/libresolv.so.2 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libkdb5.so.4.0 /lib/libdl.so.2 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libkdb5.so.4.0 /lib/libresolv.so.2 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libgssrpc.so.4.0 /usr/lib/libkrb5.so.3 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libgssrpc.so.4.0 /usr/lib/libk5crypto.so.3 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libgssrpc.so.4.0 /lib/libcom_err.so.2 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libgssapi_krb5.so.2.2 /lib/libdl.so.2 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libgssapi_krb5.so.2.2 /lib/libresolv.so.2 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libdes425.so.3.0 /lib/libcom_err.so.2 $ rpmlint -I unused-direct-shlib-dependency unused-direct-shlib-dependency : The binary contains unused direct shared library dependencies. This may indicate gratuitously bloated linkage; check that the binary has been linked with the intended shared libraries only. -------------- next part -------------- A non-text attachment was scrubbed... Name: rpmlint-unused-direct-deps.patch Type: text/x-diff Size: 4400 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Jan 27 10:12:25 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 27 Jan 2007 11:12:25 +0100 Subject: [Fedora-packaging] Unused direct shared library dependencies and rpmlint In-Reply-To: <200701271047.49334.ville.skytta@iki.fi> (Ville Skytt's message of "Sat, 27 Jan 2007 10:47:49 +0200") References: <200701271047.49334.ville.skytta@iki.fi> Message-ID: <87wt38ixrq.fsf@kosh.bigo.ensc.de> ville.skytta at iki.fi (Ville Skytt?) writes: > Inspired by > http://www.redhat.com/archives/fedora-maintainers/2006-June/msg00176.html, > I've had a patch for rpmlint in my local tree for a while which checks for > unused direct shared library dependencies in shared libs. > > I'm wondering whether this check is a good idea; Generally yes; dynamically loaded modules are an exception, because their deps can be resolved by the loading lib/application already. Another exception might be glib2 based applications/modules. There seems to be something wrong with its type system so that applications (which are not linked against glib2) misbehave when a dynamic module is linked against glib2. After unloading the module and loading it again, some types might not be registered right. But these are minor issues only. A more major one might be, how this kind of warning can be fixed. All major buildsystems (libtool, cmake) are creating such unused dependencies. Setting '-Wl,--as-needed' linkerflags might help with cmake, but fails horribly with libtool because it moves such linkerflags to the end of the cmdline. I used some magic like | sed -i -e 's! -shared ! -Wl,--as-needed\0!g' libtool after %configure. But it's not a panacea because it will not work for the exceptions above. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From mr.ecik at gmail.com Sat Jan 27 15:26:14 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sat, 27 Jan 2007 16:26:14 +0100 Subject: [Fedora-packaging] BuildRequires proposal Message-ID: <668bb39a0701270726w7180322aje022033b67dd468b@mail.gmail.com> Hi! I've made a draft regarding to BuildRequires section of Packaging Guidelines. I propose to mention about mock there. Any opinions are welcomed. Draft is available here: http://fedoraproject.org/wiki/PackagingDrafts/BuildRequires -- Micha? Bentkowski mr.ecik at gmail.com From pertusus at free.fr Sat Jan 27 17:18:49 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 27 Jan 2007 18:18:49 +0100 Subject: [Fedora-packaging] Unused direct shared library dependencies and rpmlint In-Reply-To: <200701271047.49334.ville.skytta@iki.fi> References: <200701271047.49334.ville.skytta@iki.fi> Message-ID: <20070127171849.GA2749@free.fr> On Sat, Jan 27, 2007 at 10:47:49AM +0200, Ville Skytt? wrote: > Hi, > > Inspired by > http://www.redhat.com/archives/fedora-maintainers/2006-June/msg00176.html, > I've had a patch for rpmlint in my local tree for a while which checks for > unused direct shared library dependencies in shared libs. > > I'm wondering whether this check is a good idea; I'm not an expert in this I am not an expert either but I think this is a very good idea. I have started to do this manually in all the reviews. I think it seems interesting to me for the following reasons: * it seems to improve linking * it removes unneeded dependencies, so rpm/yum/... will likely be faster * rebuilt are not necessary when an indirect dependency ABI changes In my opinion the best way to remove those unneeded dependecies is to * use pkgconfig and .private apropriately in libraries * work with upstream such that packages that depend on the libraries use pkgconfig apropriately. -- Pat From chris.stone at gmail.com Tue Jan 30 16:41:44 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 30 Jan 2007 08:41:44 -0800 Subject: [Fedora-packaging] PHP Extensions (other than pear) default install dir Message-ID: Currently extensions such as php-Smarty install their php Class files in /usr/share This should change to /usr/share/php, and the default php include_path should include /usr/share/php This will allow endusers to simply have in their php files: include 'foo/foo.php' instead of: include '/usr/share/foo/foo.php' And basically things will "just work" as expected. Seems other distros do this as well. I have filed bugs against php and php-Smarty: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225434 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225436 Can we add this to the packaging guidelines for php classes other than pear? Regards, Chris From opensource at till.name Tue Jan 30 17:40:55 2007 From: opensource at till.name (Till Maas) Date: Tue, 30 Jan 2007 18:40:55 +0100 Subject: [Fedora-packaging] plugin naming Message-ID: <200701301840.58082.opensource@till.name> Hiyas, I want to ask for a Guideline on how to name plugins for a program/package. Here are some examples of current plugin names: xfce4-wavelan-plugin thunar-media-tags-plugin nagios-plugins-real p7zip-plugins lineak-xosdplugin digikamimageplugins childsplay_plugins audacious-docklet I want to propose to use -plugin- for rpms that contain one special plugin and -plugins or -plugins- for rpms that contain several plugins. This would make it a lot easier for a user to install or look for all plugins of a given package, e.g. with yum list audacious-plugin\* yum install audacious-plugin\* Regards, Till From rdieter at math.unl.edu Tue Jan 30 18:27:36 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 30 Jan 2007 12:27:36 -0600 Subject: [Fedora-packaging] DesktopFiles proposal, final wording Message-ID: <45BF8E18.8080501@math.unl.edu> As spot requested, here's an update to the wording of: http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles to make it clear that desktop-file-install usage is mandatory to help ensure .desktop file safety and spec-compliance. -- Rex From opensource at till.name Tue Jan 30 19:30:23 2007 From: opensource at till.name (Till Maas) Date: Tue, 30 Jan 2007 20:30:23 +0100 Subject: [Fedora-packaging] more verbose PackagingGuidelinee on compiler flags Message-ID: <200701302030.24724.opensource@till.name> Hiyas, I want to propose to add a link to a page to the PackagingGuidelines on compiler flags that explain why which compiler flags should be set and why some should not set. I made a page with some examples: http://fedoraproject.org/wiki/TillMaas/CompilerFlags Regards, Till From tcallawa at redhat.com Tue Jan 30 20:46:12 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 30 Jan 2007 14:46:12 -0600 Subject: [Fedora-packaging] Exception for JPackage Message-ID: <1170189972.31747.32.camel@localhost.localdomain> OK guys, here's the item that I've been working on with the JPackage folks for a while: http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage This exception documents how Java packages which come from JPackage are to be handled, and paves the way for the eventual removal of the jpp tag. Fernando Nasser, Jesse Keating, and many others helped me put this together, and they all seem pretty happy with what we've got in this final draft. FPC members: Please vote on this item. Thanks, ~spot From jkeating at redhat.com Tue Jan 30 21:37:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 30 Jan 2007 16:37:54 -0500 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <1170189972.31747.32.camel@localhost.localdomain> References: <1170189972.31747.32.camel@localhost.localdomain> Message-ID: <200701301637.54769.jkeating@redhat.com> On Tuesday 30 January 2007 15:46, Tom 'spot' Callaway wrote: > http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage > > This exception documents how Java packages which come from JPackage are > to be handled, and paves the way for the eventual removal of the jpp > tag. > > Fernando Nasser, Jesse Keating, and many others helped me put this > together, and they all seem pretty happy with what we've got in this > final draft. > > FPC members: Please vote on this item. +1 Thanks for the hard work on this! -- 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 Tue Jan 30 22:46:12 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 30 Jan 2007 16:46:12 -0600 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <1170189972.31747.32.camel@localhost.localdomain> References: <1170189972.31747.32.camel@localhost.localdomain> Message-ID: <45BFCAB4.9050103@math.unl.edu> Tom 'spot' Callaway wrote: > OK guys, here's the item that I've been working on with the JPackage > folks for a while: > > http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage > > This exception documents how Java packages which come from JPackage are > to be handled, and paves the way for the eventual removal of the jpp > tag. > > Fernando Nasser, Jesse Keating, and many others helped me put this > together, and they all seem pretty happy with what we've got in this > final draft. > > FPC members: Please vote on this item. > +1 -- Rex From a.badger at gmail.com Tue Jan 30 23:05:24 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 30 Jan 2007 15:05:24 -0800 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <1170189972.31747.32.camel@localhost.localdomain> References: <1170189972.31747.32.camel@localhost.localdomain> Message-ID: <1170198324.18675.201.camel@localhost.localdomain> On Tue, 2007-01-30 at 14:46 -0600, Tom 'spot' Callaway wrote: > OK guys, here's the item that I've been working on with the JPackage > folks for a while: > > http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage > > This exception documents how Java packages which come from JPackage are > to be handled, and paves the way for the eventual removal of the jpp > tag. > > Fernando Nasser, Jesse Keating, and many others helped me put this > together, and they all seem pretty happy with what we've got in this > final draft. > > FPC members: Please vote on this item. +1. Great work spot, fnasser, and f13! -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 Wed Jan 31 00:17:07 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 Jan 2007 18:17:07 -0600 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <1170189972.31747.32.camel@localhost.localdomain> References: <1170189972.31747.32.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom 'spot' Callaway writes: TC> This exception documents how Java packages which come from TC> JPackage are to be handled, and paves the way for the eventual TC> removal of the jpp tag. I have no problem with granting the exception, but I do think the definition of the exception should include a explicitly state the conditions under which it will go away. The linked document has rationale and ideas for things to be added to rpm and yum under the "Proposal" section, but there's no clear statement of just how long the exception is to be granted. (Perhaps it's intended to be permanent; it's just not clear from the document.) - J< From tcallawa at redhat.com Wed Jan 31 00:40:09 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 30 Jan 2007 18:40:09 -0600 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: References: <1170189972.31747.32.camel@localhost.localdomain> Message-ID: <1170204009.2961.15.camel@localhost.localdomain> On Tue, 2007-01-30 at 18:17 -0600, Jason L Tibbitts III wrote: > >>>>> "TC" == Tom 'spot' Callaway writes: > > TC> This exception documents how Java packages which come from > TC> JPackage are to be handled, and paves the way for the eventual > TC> removal of the jpp tag. > > I have no problem with granting the exception, but I do think the > definition of the exception should include a explicitly state the > conditions under which it will go away. > > The linked document has rationale and ideas for things to be added to > rpm and yum under the "Proposal" section, but there's no clear > statement of just how long the exception is to be granted. (Perhaps > it's intended to be permanent; it's just not clear from the document.) Unfortunately, the exception will be permanent for the Java packages from JPackage. The exception will be modified when we can safely drop the jpp tag from Fedora. ~spot From tibbs at math.uh.edu Wed Jan 31 00:57:33 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 Jan 2007 18:57:33 -0600 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <1170204009.2961.15.camel@localhost.localdomain> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom 'spot' Callaway writes: TC> Unfortunately, the exception will be permanent for the Java TC> packages from JPackage. The exception will be modified when we can TC> safely drop the jpp tag from Fedora. Perhaps you can understand my confusion, then. Here's my understanding: There's a singluar issue: the portion of the release field before the dist tag is not an integer and neither of the two exceptions in the NamingGuidelines apply. The proposed exception, for Java packages from JPackage only, is: *) Temporarily allow release to take the form Xjpp.Y%{?dist}[.Z] until the detailed changes to rpm and yum render the "jpp" unnecessary. *) Permanently allow release to take the form X.Y%{?dist}[.Z] Where X, Y, and Z are integers defined in the proposal. If that's correct, then +1. - J< From tcallawa at redhat.com Wed Jan 31 01:01:19 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 30 Jan 2007 19:01:19 -0600 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> Message-ID: <1170205279.2961.18.camel@localhost.localdomain> On Tue, 2007-01-30 at 18:57 -0600, Jason L Tibbitts III wrote: > >>>>> "TC" == Tom 'spot' Callaway writes: > > TC> Unfortunately, the exception will be permanent for the Java > TC> packages from JPackage. The exception will be modified when we can > TC> safely drop the jpp tag from Fedora. > > Perhaps you can understand my confusion, then. Here's my > understanding: > > There's a singluar issue: the portion of the release field before the > dist tag is not an integer and neither of the two exceptions in the > NamingGuidelines apply. The proposed exception, for Java packages > from JPackage only, is: > > *) Temporarily allow release to take the form Xjpp.Y%{?dist}[.Z] > until the detailed changes to rpm and yum render the "jpp" > unnecessary. > > *) Permanently allow release to take the form X.Y%{?dist}[.Z] > > Where X, Y, and Z are integers defined in the proposal. > > If that's correct, then +1. Yes, that is correct. ~spot From a.badger at gmail.com Wed Jan 31 01:30:30 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 30 Jan 2007 17:30:30 -0800 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <1170204009.2961.15.camel@localhost.localdomain> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> Message-ID: <1170207030.18675.219.camel@localhost.localdomain> On Tue, 2007-01-30 at 18:40 -0600, Tom 'spot' Callaway wrote: > On Tue, 2007-01-30 at 18:17 -0600, Jason L Tibbitts III wrote: > > >>>>> "TC" == Tom 'spot' Callaway writes: > > > > TC> This exception documents how Java packages which come from > > TC> JPackage are to be handled, and paves the way for the eventual > > TC> removal of the jpp tag. > > > > I have no problem with granting the exception, but I do think the > > definition of the exception should include a explicitly state the > > conditions under which it will go away. > > > > The linked document has rationale and ideas for things to be added to > > rpm and yum under the "Proposal" section, but there's no clear > > statement of just how long the exception is to be granted. (Perhaps > > it's intended to be permanent; it's just not clear from the document.) > > Unfortunately, the exception will be permanent for the Java packages > from JPackage. The exception will be modified when we can safely drop > the jpp tag from Fedora. Err.. If you mean "permanent for the Java packages *in* JPackage" then I'm still okay with the proposal. Otherwise I'm changing my 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 chitlesh at fedoraproject.org Wed Jan 31 05:40:34 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 31 Jan 2007 06:40:34 +0100 Subject: [Fedora-packaging] DesktopFiles proposal, final wording In-Reply-To: <45BF8E18.8080501@math.unl.edu> References: <45BF8E18.8080501@math.unl.edu> Message-ID: <13dbfe4f0701302140j57e8ca09wb5e31022d79314e3@mail.gmail.com> On 1/30/07, Rex Dieter wrote: > As spot requested, here's an update to the wording of: > http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles > to make it clear that desktop-file-install usage is mandatory to help > ensure .desktop file safety and spec-compliance. Hello, I think mentioning vendor-id is useless, since now fedora packaging policies doesn't include "fedora" as vendor name . Chitlesh -- http://clunixchit.blogspot.com From rdieter at math.unl.edu Wed Jan 31 06:57:05 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 31 Jan 2007 00:57:05 -0600 Subject: [Fedora-packaging] DesktopFiles proposal, final wording In-Reply-To: <13dbfe4f0701302140j57e8ca09wb5e31022d79314e3@mail.gmail.com> References: <45BF8E18.8080501@math.unl.edu> <13dbfe4f0701302140j57e8ca09wb5e31022d79314e3@mail.gmail.com> Message-ID: <45C03DC1.60906@math.unl.edu> Chitlesh GOORAH wrote: > On 1/30/07, Rex Dieter wrote: >> As spot requested, here's an update to the wording of: >> http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles >> to make it clear that desktop-file-install usage is mandatory to help >> ensure .desktop file safety and spec-compliance. > I think mentioning vendor-id is useless, since now fedora packaging > policies doesn't include "fedora" as vendor name . Uh, yes it does: "If upstream uses , leave it intact, otherwise use fedora as ." That part of the policy remains unchanged. -- Rex From chitlesh at fedoraproject.org Wed Jan 31 06:40:09 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 31 Jan 2007 07:40:09 +0100 Subject: [Fedora-packaging] DesktopFiles proposal, final wording In-Reply-To: <45C03DC1.60906@math.unl.edu> References: <45BF8E18.8080501@math.unl.edu> <13dbfe4f0701302140j57e8ca09wb5e31022d79314e3@mail.gmail.com> <45C03DC1.60906@math.unl.edu> Message-ID: <13dbfe4f0701302240p547dcfc9y700f0da73242d67a@mail.gmail.com> On 1/31/07, Rex Dieter wrote: > Uh, yes it does: > "If upstream uses , leave it intact, otherwise use fedora as > ." > That part of the policy remains unchanged. Hmm, so if kde adds its desktop files at /usr/share/applications/kde, I should consider the vendor be "kde" here ? and leave the desktop files at /usr/share/applications/kde instead of /usr/share/applications ? Chitlesh -- http://clunixchit.blogspot.com From rdieter at math.unl.edu Wed Jan 31 07:30:04 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 31 Jan 2007 01:30:04 -0600 Subject: [Fedora-packaging] DesktopFiles proposal, final wording In-Reply-To: <13dbfe4f0701302240p547dcfc9y700f0da73242d67a@mail.gmail.com> References: <45BF8E18.8080501@math.unl.edu> <13dbfe4f0701302140j57e8ca09wb5e31022d79314e3@mail.gmail.com> <45C03DC1.60906@math.unl.edu> <13dbfe4f0701302240p547dcfc9y700f0da73242d67a@mail.gmail.com> Message-ID: <45C0457C.2070007@math.unl.edu> Chitlesh GOORAH wrote: > On 1/31/07, Rex Dieter wrote: >> Uh, yes it does: >> "If upstream uses , leave it intact, otherwise use fedora as >> ." >> That part of the policy remains unchanged. > Hmm, so if kde adds its desktop files at /usr/share/applications/kde, > I should consider the vendor be "kde" here ? and leave the desktop > files at /usr/share/applications/kde instead of > /usr/share/applications ? Yes, exactly. -- Rex From chitlesh at fedoraproject.org Wed Jan 31 07:46:28 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 31 Jan 2007 08:46:28 +0100 Subject: [Fedora-packaging] DesktopFiles proposal, final wording In-Reply-To: <45C0457C.2070007@math.unl.edu> References: <45BF8E18.8080501@math.unl.edu> <13dbfe4f0701302140j57e8ca09wb5e31022d79314e3@mail.gmail.com> <45C03DC1.60906@math.unl.edu> <13dbfe4f0701302240p547dcfc9y700f0da73242d67a@mail.gmail.com> <45C0457C.2070007@math.unl.edu> Message-ID: <13dbfe4f0701302346g1b39dbbagd5a8124a133bc989@mail.gmail.com> On 1/31/07, Rex Dieter wrote: > Yes, exactly. > Ah ha, then I should correct one or two of my packages :) hihihi Chitlesh -- http://clunixchit.blogspot.com From laurent.rineau__fedora_extras at normalesup.org Wed Jan 31 09:14:12 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Wed, 31 Jan 2007 10:14:12 +0100 Subject: [Fedora-packaging] DesktopFiles proposal, final wording In-Reply-To: <13dbfe4f0701302346g1b39dbbagd5a8124a133bc989@mail.gmail.com> References: <45BF8E18.8080501@math.unl.edu> <45C0457C.2070007@math.unl.edu> <13dbfe4f0701302346g1b39dbbagd5a8124a133bc989@mail.gmail.com> Message-ID: <200701311014.12980@rineau.schtroumpfette> On Wednesday 31 January 2007 08:46, Chitlesh GOORAH wrote: > On 1/31/07, Rex Dieter wrote: > > Yes, exactly. > > Ah ha, then I should correct one or two of my packages :) hihihi Make sure you respect this: ??It is important that vendor_id stay constant for the life of a package.?? If I understood well, it means that, if one of your package use an "incorrect" vendor_id, you should keep it incorrect. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From tcallawa at redhat.com Wed Jan 31 16:12:27 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 31 Jan 2007 10:12:27 -0600 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <1170207030.18675.219.camel@localhost.localdomain> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> Message-ID: <1170259947.2961.38.camel@localhost.localdomain> On Tue, 2007-01-30 at 17:30 -0800, Toshio Kuratomi wrote: > On Tue, 2007-01-30 at 18:40 -0600, Tom 'spot' Callaway wrote: > > On Tue, 2007-01-30 at 18:17 -0600, Jason L Tibbitts III wrote: > > > >>>>> "TC" == Tom 'spot' Callaway writes: > > > > > > TC> This exception documents how Java packages which come from > > > TC> JPackage are to be handled, and paves the way for the eventual > > > TC> removal of the jpp tag. > > > > > > I have no problem with granting the exception, but I do think the > > > definition of the exception should include a explicitly state the > > > conditions under which it will go away. > > > > > > The linked document has rationale and ideas for things to be added to > > > rpm and yum under the "Proposal" section, but there's no clear > > > statement of just how long the exception is to be granted. (Perhaps > > > it's intended to be permanent; it's just not clear from the document.) > > > > Unfortunately, the exception will be permanent for the Java packages > > from JPackage. The exception will be modified when we can safely drop > > the jpp tag from Fedora. > > Err.. If you mean "permanent for the Java packages *in* JPackage" then > I'm still okay with the proposal. Otherwise I'm changing my vote.... The Java packages in Fedora which originally come from the JPackage repo are the only packages which fall under this exception. And those packages will always fall under this exception, forever and ever, amen (or until something dramatic changes). ~spot From rc040203 at freenet.de Wed Jan 31 17:27:27 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 31 Jan 2007 18:27:27 +0100 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <1170259947.2961.38.camel@localhost.localdomain> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> <1170259947.2961.38.camel@localhost.localdomain> Message-ID: <1170264447.5838.508.camel@mccallum.corsepiu.local> On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote: > On Tue, 2007-01-30 at 17:30 -0800, Toshio Kuratomi wrote: > > On Tue, 2007-01-30 at 18:40 -0600, Tom 'spot' Callaway wrote: > > > On Tue, 2007-01-30 at 18:17 -0600, Jason L Tibbitts III wrote: > > > > >>>>> "TC" == Tom 'spot' Callaway writes: > > > > > > > > TC> This exception documents how Java packages which come from > > > > TC> JPackage are to be handled, and paves the way for the eventual > > > > TC> removal of the jpp tag. > > > > > > > > I have no problem with granting the exception, but I do think the > > > > definition of the exception should include a explicitly state the > > > > conditions under which it will go away. > > > > > > > > The linked document has rationale and ideas for things to be added to > > > > rpm and yum under the "Proposal" section, but there's no clear > > > > statement of just how long the exception is to be granted. (Perhaps > > > > it's intended to be permanent; it's just not clear from the document.) > > > > > > Unfortunately, the exception will be permanent for the Java packages > > > from JPackage. The exception will be modified when we can safely drop > > > the jpp tag from Fedora. > > > > Err.. If you mean "permanent for the Java packages *in* JPackage" then > > I'm still okay with the proposal. Otherwise I'm changing my vote.... > > The Java packages in Fedora which originally come from the JPackage repo > are the only packages which fall under this exception. And those > packages will always fall under this exception, forever and ever, amen > (or until something dramatic changes). So Fedora will never have java packages of its own and depend on jpp? If so, fedora seems to be missing it's objectives, as it seems to me? Ralf From tcallawa at redhat.com Wed Jan 31 17:47:07 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 31 Jan 2007 11:47:07 -0600 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <1170264447.5838.508.camel@mccallum.corsepiu.local> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> <1170259947.2961.38.camel@localhost.localdomain> <1170264447.5838.508.camel@mccallum.corsepiu.local> Message-ID: <1170265627.27368.2.camel@localhost.localdomain> On Wed, 2007-01-31 at 18:27 +0100, Ralf Corsepius wrote: > On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote: > > On Tue, 2007-01-30 at 17:30 -0800, Toshio Kuratomi wrote: > > > On Tue, 2007-01-30 at 18:40 -0600, Tom 'spot' Callaway wrote: > > > > On Tue, 2007-01-30 at 18:17 -0600, Jason L Tibbitts III wrote: > > > > > >>>>> "TC" == Tom 'spot' Callaway writes: > > > > > > > > > > TC> This exception documents how Java packages which come from > > > > > TC> JPackage are to be handled, and paves the way for the eventual > > > > > TC> removal of the jpp tag. > > > > > > > > > > I have no problem with granting the exception, but I do think the > > > > > definition of the exception should include a explicitly state the > > > > > conditions under which it will go away. > > > > > > > > > > The linked document has rationale and ideas for things to be added to > > > > > rpm and yum under the "Proposal" section, but there's no clear > > > > > statement of just how long the exception is to be granted. (Perhaps > > > > > it's intended to be permanent; it's just not clear from the document.) > > > > > > > > Unfortunately, the exception will be permanent for the Java packages > > > > from JPackage. The exception will be modified when we can safely drop > > > > the jpp tag from Fedora. > > > > > > Err.. If you mean "permanent for the Java packages *in* JPackage" then > > > I'm still okay with the proposal. Otherwise I'm changing my vote.... > > > > The Java packages in Fedora which originally come from the JPackage repo > > are the only packages which fall under this exception. And those > > packages will always fall under this exception, forever and ever, amen > > (or until something dramatic changes). > > So Fedora will never have java packages of its own and depend on jpp? > > If so, fedora seems to be missing it's objectives, as it seems to me? No, it certainly can (and does) have java packages that don't come from JPackage. This exception is only for those packages which originate from jpp. ~spot From tibbs at math.uh.edu Wed Jan 31 17:52:26 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 31 Jan 2007 11:52:26 -0600 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <1170264447.5838.508.camel@mccallum.corsepiu.local> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> <1170259947.2961.38.camel@localhost.localdomain> <1170264447.5838.508.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote: >> The Java packages in Fedora which originally come from the JPackage >> repo are the only packages which fall under this exception. And >> those packages will always fall under this exception, forever and >> ever, amen (or until something dramatic changes). RC> So Fedora will never have java packages of its own and depend on RC> jpp? I'm having trouble understanding how you get from spot's statement above to your conclusion. There are some packages which come from jpackage and there are some that don't. Has it been stated otherwise somewhere? - J< From a.badger at gmail.com Wed Jan 31 18:26:36 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 31 Jan 2007 10:26:36 -0800 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <1170259947.2961.38.camel@localhost.localdomain> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> <1170259947.2961.38.camel@localhost.localdomain> Message-ID: <1170267996.18675.339.camel@localhost.localdomain> On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote: > On Tue, 2007-01-30 at 17:30 -0800, Toshio Kuratomi wrote: > > On Tue, 2007-01-30 at 18:40 -0600, Tom 'spot' Callaway wrote: > > > On Tue, 2007-01-30 at 18:17 -0600, Jason L Tibbitts III wrote: > > > > >>>>> "TC" == Tom 'spot' Callaway writes: > > > > > > > > TC> This exception documents how Java packages which come from > > > > TC> JPackage are to be handled, and paves the way for the eventual > > > > TC> removal of the jpp tag. > > > > > > > > I have no problem with granting the exception, but I do think the > > > > definition of the exception should include a explicitly state the > > > > conditions under which it will go away. > > > > > > > > The linked document has rationale and ideas for things to be added to > > > > rpm and yum under the "Proposal" section, but there's no clear > > > > statement of just how long the exception is to be granted. (Perhaps > > > > it's intended to be permanent; it's just not clear from the document.) > > > > > > Unfortunately, the exception will be permanent for the Java packages > > > from JPackage. The exception will be modified when we can safely drop > > > the jpp tag from Fedora. > > > > Err.. If you mean "permanent for the Java packages *in* JPackage" then > > I'm still okay with the proposal. Otherwise I'm changing my vote.... > > The Java packages in Fedora which originally come from the JPackage repo > are the only packages which fall under this exception. And those > packages will always fall under this exception, forever and ever, amen > (or until something dramatic changes). I'm with tibbs... The more information I get, the more confused I am :-) I think I've realized where I'm getting confused, though. JPackage packages will always fall under this policy. However this policy only allows use of the "jpp" portion of the JPackage release tag until the technical considerations are worked out. At that point the policy will use the integer subrelease from JPackage without jpp. If this is true then I'm still +1. I dislike using the word Exception in something that's meant to be permanent because exceptions are things you want to get rid of. Since this is something that we're seeing a continuous value in maybe "JPackage Subrelease Policy" would be better. Use of the subrelease by itself is generic enough that we might even consider extending it to cover other situations if there's a legitimate need for it in the future. -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 Wed Jan 31 18:32:46 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 31 Jan 2007 12:32:46 -0600 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <1170267996.18675.339.camel@localhost.localdomain> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> <1170259947.2961.38.camel@localhost.localdomain> <1170267996.18675.339.camel@localhost.localdomain> Message-ID: <1170268366.27368.5.camel@localhost.localdomain> On Wed, 2007-01-31 at 10:26 -0800, Toshio Kuratomi wrote: > I think I've realized where I'm getting confused, though. JPackage > packages will always fall under this policy. However this policy only > allows use of the "jpp" portion of the JPackage release tag until the > technical considerations are worked out. At that point the policy will > use the integer subrelease from JPackage without jpp. > > If this is true then I'm still +1. Yes. This is the case. > I dislike using the word Exception in something that's meant to be > permanent because exceptions are things you want to get rid of. Since > this is something that we're seeing a continuous value in maybe > "JPackage Subrelease Policy" would be better. Use of the subrelease by > itself is generic enough that we might even consider extending it to > cover other situations if there's a legitimate need for it in the > future. Agreed. I'll rename it accordingly when it gets out of Draft. ~spot