Hello
I need a piece of advice on a small problem regarding the package called mysqltuner, which I maintain in EPEL.
Background info:
This package consists of a single perl script which at rpm build time is copied from its source tarball to /bin. The program itself reads some variables from mysql and makes recommendations for tuning the mysql settings in order to optimize the performance. Since there is no 'compiling', Ville (the packager) decided to not use %dist. As a consequence, in order to build the package in both EL-4 and El-5 there are two options - use different release tags (the build system prohibits using the same tags ... or at least I was not able to figure out how to build in one branch stuff tagged on another branch: when I tried to do "make tag" for the first time in EL-4, using the same spec as the one from rawhide, I was told that the tag 0.9.8-1 has already been applied (and it was, of course, in rawhide) ; OTOH I could not build (of course) because the files I have uploaded were not tagged -manually copy from one branch to another one (to be performed by the admins). Hopefully this will occur quite rarely, so there should not be a great burden.
At https://bugzilla.redhat.com/show_bug.cgi?id=452172 is the rationale for not using %dist (which makes sense, as I have explained above). Ville also took the time to explaine me how to inherit stuff from one branch to another one, but the mechanism seems to be valid only for Fedora.
So: what do you think is the recommended way: - build twice, with different release tags , once in EL-4 and once in EL-5 (I see absolutely no gain in this route) - switch to using %dist and go the usual way - build in one branch (EL-5 ?) and rely on the admins to copy the package to the other one
TIA manuel
Manuel Wolfshant wrote:
Since there is no 'compiling', Ville (the packager) decided to notuse %dist. As a consequence, in order to build the package in both EL-4 and El-5 there are two options
Imo, the extra pain/work involved in maintaining/deploying this without using %dist simply isn't worth it.
Add %{?dist} to Release tag and be done with it.
-- Rex
On 29.07.2008 20:36, Rex Dieter wrote:
Manuel Wolfshant wrote:
Since there is no 'compiling', Ville (the packager) decided to notuse %dist. As a consequence, in order to build the package in both EL-4 and El-5 there are two options
Imo, the extra pain/work involved in maintaining/deploying this without using %dist simply isn't worth it. Add %{?dist} to Release tag and be done with it.
I tend to agree for this kind package. Copying it over makes only makes sense when it comes to big data packages, but for a small easy package like this the overhead is not worth the risk and trouble.
Cu knurd
On Tue, Jul 29, 2008 at 08:59:33PM +0200, Thorsten Leemhuis wrote:
I tend to agree for this kind package. Copying it over makes only makes sense when it comes to big data packages, but for a small easy package like this the overhead is not worth the risk and trouble.
Still it would be nice to hae this fixed in EPEL. Will it be fixed with a switch to using koji/bodhi?
-- Pat
Patrice Dumas wrote:
On Tue, Jul 29, 2008 at 08:59:33PM +0200, Thorsten Leemhuis wrote:
I tend to agree for this kind package. Copying it over makes only makes sense when it comes to big data packages, but for a small easy package like this the overhead is not worth the risk and trouble.
Still it would be nice to hae this fixed in EPEL. Will it be fixed with a switch to using koji/bodhi?
afaik no. It (still) requires manual intervention copy the same pkg to different repos/releases.
-- Rex
On Wednesday 30 July 2008, Rex Dieter wrote:
Patrice Dumas wrote:
On Tue, Jul 29, 2008 at 08:59:33PM +0200, Thorsten Leemhuis wrote:
I tend to agree for this kind package. Copying it over makes only makes sense when it comes to big data packages, but for a small easy package like this the overhead is not worth the risk and trouble.
Still it would be nice to hae this fixed in EPEL. Will it be fixed with a switch to using koji/bodhi?
afaik no. It (still) requires manual intervention copy the same pkg to different repos/releases.
FWIW, in Fedora, Rawhide auto-inherits builds from earlier repos, but only if there have been no builds with the tag Rawhide points to. So for example if a package has not been built to dist-f10 (any EVR, ever) but it is in let's say dist-f9-updates-testing, it will be automatically copied to Rawhide.
On Wed, 2008-07-30 at 22:55 +0300, Ville Skyttä wrote:
but it is in let's say dist-f9-updates-testing, it will be automatically copied to Rawhide.
Close. Things in -testing don't get inherited. Only things in dist-foo and dist-foo-updates
On 07/30/2008 11:09 PM, Jesse Keating wrote:
On Wed, 2008-07-30 at 22:55 +0300, Ville Skyttä wrote:
FWIW, in Fedora, Rawhide auto-inherits builds from earlier repos, but only if there have been no builds with the tag Rawhide points to[...]but it is in let's say dist-f9-updates-testing, it will be automatically copied to Rawhide.
Close. Things in -testing don't get inherited. Only things in dist-foo and dist-foo-updates
Let's see if I got it right, and please do correct me where I am wrong.
Auto-inheritance assumes that the package was never released for rawhide, hence it does not apply to _new_ packages, which by default should start by being pushed to rawhide, right [1] ? Therefore basically this inheritance applies only when branching for a new fedora release. Am I right here ?
[1]: the case described by Ville would be: - have a new package reviewed and approved, - request a - say - F9 branch (beside the default one for devel), - build and push to F9-updates (I have assumed here that the packager really knows what he does and is sure about the stability, compatibility of the new packag etc) Does auto-inheritance kick in here at this moment and " magically " copy it to devel so you get two-for-one for free ? Until today I have thought that this process happens only when composing for the new release.
On Thu, 2008-07-31 at 00:21 +0300, Manuel Wolfshant wrote:
Does auto-inheritance kick in here at this moment and " magically " copy it to devel so you get two-for-one for free ? Until today I have thought that this process happens only when composing for the new release.
Yes, inheritance would kick in at that point.
On Wednesday 30 July 2008, Jesse Keating wrote:
On Wed, 2008-07-30 at 22:55 +0300, Ville Skyttä wrote:
but it is in let's say dist-f9-updates-testing, it will be automatically copied to Rawhide.
Close. Things in -testing don't get inherited. Only things in dist-foo and dist-foo-updates
there is zero inheritance in EPEL so its all moot until we can move to koji. the only thing that can be done is to copy the rpms from one needsign queue to the other. which meens you need to email epel_signers as soon as your build is done to request that it happens
On 07/31/2008 01:38 AM, Dennis Gilmore wrote:
On Wednesday 30 July 2008, Jesse Keating wrote:
On Wed, 2008-07-30 at 22:55 +0300, Ville Skyttä wrote:
but it is in let's say dist-f9-updates-testing, it will be automatically copied to Rawhide.
Close. Things in -testing don't get inherited. Only things in dist-foo and dist-foo-updates
there is zero inheritance in EPEL so its all moot until we can move to koji. the only thing that can be done is to copy the rpms from one needsign queue to the other. which meens you need to email epel_signers as soon as your build is done to request that it happens
Thanks a lot, Dennis. That's part of the reply I was wishing for in the first place ( as of technical approach; the political approach was settled already )
FWIW: I've just built 0.9.8-2.el5 and also comited to CVS the modified spec for EL-4. However I have not built it for EL-4 since I see no real gain in that: rpmdev-vercmp says 0.9.8-2 (which is now in EL-4/testing) is older than 0.9.8-2.el5 so once the newly built package lands in EL-5/testing everything should be OK wrt the upgrade path.
epel-devel@lists.fedoraproject.org
-
Dennis Gilmore -
Jesse Keating -
Manuel Wolfshant -
Patrice Dumas -
Rex Dieter -
Thorsten Leemhuis -
Ville Skyttä