(this is a follow up to https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00539.html I'd like to move this part of the discussion here to fedora-devel to make sure everyone can participate in this discussion -- that not the case on fedora-maintainers as it's a closed list and moderators don't let any non-contributors mail pass afaik; epel-devel-list seemsed like the wrong place to discuss, as certain Fedora people that we need for this discussion are not subscribed there afaik)
Brian Pepple schrieb:
/topic FESCO-Meeting -- EPEL
There was no meeting this week afaics from looking at #fedora-meeting.
Other stuff: There was and still is a lot of political discussions on the mailing list about EPEL not using a repotag. Political in the sense of "Fedora/EPEL is bad/unfair to existing repos because it doesn't use a repotag". See the archives at https://www.redhat.com/archives/epel-devel-list/ for details.
Not using a repotag was a decision FESCo did already last fall; the EPEL Steering Committee voted the same way recently, too. I was actually one of those voting it down both times, too. Some of my reasons for doing this were (in short, rough form below and all IMHO; btw, feel free to simply skip the next five paras, the interesting stuff are below):
- we have nothing in place to properly use of a repotag everywhere; yes, we could abuse disttag, but I dislike abusing something that is meant to be used for something else; and the disttag in not used by all packages -- a repotag IMHO mainly makes sense only if we really use it everywhere.
- there is a place in the rpm header already (%{vendor}) where a package comes from. Maintaining a certain information in two places sounds wrong to me and can lead to inconsistencies. The tools used should just display the tag probably where relevant, and we should make sure it is properly set.
- minor: disk space is cheap, but classic terminals are limited to 80 chars. Or, in other words: I dislike making each rpm name as displayed by yum/rpm and other tools five chars longer for a repotag like ".epel" as those chars can result in ugly output (line breaks)
- minor: there was a certain high member of both FESCo and the Packaging Committee that strongly was against using repotags; I trust his opinion in packaging issues a lot, and thus in parts addapted the was a reasons
I don't want to discuss those reasons I outlined above again in detail here, as all those were discussed endlessly on mailing lists or IRC channels already. It seems different people just have different expectations and opinions in this area, and thus come to different conclusions -- that's life and happens every day and (in general) is something good. Feel free to reply to those four reasons I outlined above and tell the world why thl and the reasons he gave are stupid/wrong -- I probably won't reply to your reply, as that probably doesn't lead anywhere productive; what I'm up to comes below, and that's what I'd like to see discussed.
= Important part starts here =
From a political standpoint EPEL looks quite bad in some peoples eyes
now due to not having a repotag. I think those people are making the issue worse then it is. But well, seems it's quite important to them and they make a lot of noise -- that will have negative impact on the fame of Fedora; thus I'd say we have reached the point where FESCo and the Board should back the decision to not use a repotag *or* (IMHO preferred) we need to find a solution to make the situations at least somehow acceptable for everyone involved.
So for the sake of cooperation and being nice to people that want a repotag I'd like to propose the below solution in the hope that it is acceptable for most people and even makes some people happy:
---
Use a repotag for EPEL4 and EPEL5 like this: add a "%define repotag foo" in the buildsys, where foo expands to ".epel4" in EPEL4 and ".epel5" on EPEL5; the repotag macro doesn't get defined in Fedora builders and thus nothing will change when building a package for Fedora, even if it has a %{?repotag} in %{release}.
Then enforce the use of "%{?repotag}" at the end of %{release} for all packages in EPEL. To make that effective used in the repo it requires a rebuild of all packages that are in EPEL already. Not nice and a bit of work, but for the sake of making people happy let's just do it. The added "%{?repotag}" in the release field must be allowed in Fedora spec files, too, so people can easily copy spec files from Fedora to EPEL and vice versa without having to modify them.
By Fedora 8 or Fedora 9 enhance the tools (rpm, yum, ...) to display a the %{vendor} field in case of problems (for all packages that are involved) and in popular queries. Then drop the repotag in EPEL6 and later again, as it shouldn't be that much needed anymore
---
Did I miss anything?
Note note: it's just a idea I propose for discussion now; I'd like to get feedback from the list over the next few days, get feedback from FESCo in their meeting today (just feedback, don't vote on this yet please, as this is still a decision the EPEL Steering Committee should do, and I have no idea what the other think about it), from the Packaging Committee in their meeting on Tuesday (they have to ACK the new macro and it's use in both Fedora and EPEL spec files); then the EPEL Steering Committee can finally discuss and decide in next weeks meeting (next Wednesday) and we can all move on to our regular business again and end this area that otherwise might end in "Fedora repowars -- the second season" otherwise?
CU thl
On 4/26/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
Political in the sense of "Fedora/EPEL is bad/unfair to existing repos because it doesn't use a repotag".
Why is the repotag even considered part of the version string? repotags _should_ have nothing to do with version numbers as far as I understand it.
On 4/26/07, Christopher Stone chris.stone@gmail.com wrote:
Why is the repotag even considered part of the version string? repotags _should_ have nothing to do with version numbers as far as I understand it.
Historically, rpm's default cmdline query output doesn't provide vendor identification information so its difficult for some users to easily figure out where a package came from. The rpm cmdline tool was never really designed with multiple package vendors in mind. Its a problem. Nor does yum's default status information provide any vendor information for installed packages when using yum list. Certainly the add/remove gui makes no such effort to inform you of the vendor for any installed package. Even the rpmpkg log that gets created nightly doesn't make any effort to inform local admins about multiple vendors.
Repotags are a downstream effort to fix short-comings in status information for the most common clientside package management tool commands so that some repository originating information is relayed to the poor unsuspecting and uninformed user/admin. Repotags are duct tape.
Something needs to be done to help users figure out where a package if there is a problem... on their own. If they have to wander into an irc channel or a web forum or mailinglist or bugzilla and be told how to check the vendor string for packages.. so they can then go to the correct irc channel or web forum or mailinglist or bugzilla ... that's just wasteful and prone to the sins of misinformation (or the glory of unpolitic truth depending on your pov). These sort of repetitive interactions with less technically skilled users strongly suggests the usability of the clientside package management tools needs to enhanced to be more robust to troubleshooting situations that involve multiple repository package sets.
The reality is, its a lot easier to install new packages from 3rd party repositories, then it is to go back and to identify which package came from where..without a repotags. Seriously, only perverse masochists, like myself, go through the trouble reading the complete manpage of rpm and learning about the --qf option. We certainly shouldn't be expecting novice home system admins to know about --qf. They really need a more accessible way to see the breakdown of their installed packages by Vendor.
Even the Vendor tag isn't authoritative really. The only way we can generally solve this currently this is to rely on the actually package signatures and relate those back to signing key ID strings (until packages start using a more generalized cert istead of gpg sigs). And there doesn't appear to be any way to do that with even an rpm commandline argument with the rpm in fedora currently. "Who signed this package" is not a question that rpm can reasonably answer as far as I can tell. I wouldn't characterize an alpha-numeric key ID in the -qi output as user-friendly. I'd love to be able to ask that question and get information like the output of rpm -q --qf "%{SUMMARY}\n" gpg-pubkey-1ac70ce6-41bebeef.
You could of course go further and have repository information linked to that particular key which repository aware client tools could use to bring up contact information such as the bug tracker and communication channels to be used for any package.
Just remember there is an underlying usability problem that goes past the surface politics which repotags try to impact. In the grubby unpure everyday user world of multiple repositories, when problems or bugs show up, how do those users interact with their computer system so that they can be pointed to the best location for assistance for the application they are having problems with? If repotags aren't a sound technical answer, then what is? And more importantly who is going to step up to the plate and implement it?.
-jef"not me"spaleta
-jef
On Thu, 2007-04-26 at 09:04 +0200, Thorsten Leemhuis wrote:
Use a repotag for EPEL4 and EPEL5 like this: add a "%define repotag foo" in the buildsys, where foo expands to ".epel4" in EPEL4 and ".epel5" on EPEL5; the repotag macro doesn't get defined in Fedora builders and thus nothing will change when building a package for Fedora, even if it has a %{?repotag} in %{release}.
Just a tiny detail, picking a random EPEL package: denyhosts-2.6-4.el5.noarch.rpm then it would/could become: denyhosts-2.6-4.el5.epel5.noarch.rpm
which I think is redundant, repotag should expand to "epel" only for all versions, so we would have: denyhosts-2.6-4.el5.epel.noarch.rpm
Then enforce the use of "%{?repotag}" at the end of %{release} for all packages in EPEL. To make that effective used in the repo it requires a rebuild of all packages that are in EPEL already. Not nice and a bit of work, but for the sake of making people happy let's just do it. The added "%{?repotag}" in the release field must be allowed in Fedora spec files, too, so people can easily copy spec files from Fedora to EPEL and vice versa without having to modify them.
Sounds good. The rebuild could happen over a period of time, of course.
Would it be possible to use the already existing %{?dist} distag and just change the way it is expanded in EPEL alone? That would actually avoid changing the spec file at all. I don't know if this might be a technical no-no for some reason in Fedora's build system.
Hmmm, I seem to remember something about incremental releases being set by a number _after_ the distag... that might make this option a no-go (AFAIK third party repos - including mine - have used disttag as the _last_ component of release, so, for example in my case disttag expands to .fcx.ccrma).
By Fedora 8 or Fedora 9 enhance the tools (rpm, yum, ...) to display a the %{vendor} field in case of problems (for all packages that are involved) and in popular queries. Then drop the repotag in EPEL6 and later again, as it shouldn't be that much needed anymore
Did I miss anything?
Sounds good to me. I like Jeff's suggestion (further down in the thread) to eventually use the signature of the package to id the distro:
On Thu, 2007-04-26 at 13:22 -0800, Jeff Spaleta wrote:
Even the Vendor tag isn't authoritative really. The only way we can generally solve this currently this is to rely on the actually package signatures and relate those back to signing key ID strings (until packages start using a more generalized cert istead of gpg sigs). And there doesn't appear to be any way to do that with even an rpm commandline argument with the rpm in fedora currently. "Who signed this package" is not a question that rpm can reasonably answer as far as I can tell. I wouldn't characterize an alpha-numeric key ID in the -qi output as user-friendly. I'd love to be able to ask that question and get information like the output of rpm -q --qf "%{SUMMARY}\n" gpg-pubkey-1ac70ce6-41bebeef.
Looks to me like the right technical solution. Reliable and automatic (does not depend on the packager to conform to a standard). Obviously its usefulness depends on how rpm & friends are changed to support it in a "transparent" way.
-- Fernando
Forewarning: I've not paid attention to the entire discussion, but...
Fernando Lopez-Lezcano wrote:
On Thu, 2007-04-26 at 09:04 +0200, Thorsten Leemhuis wrote:
Use a repotag for EPEL4 and EPEL5 like this: add a "%define repotag foo" in the buildsys, where foo expands to ".epel4" in EPEL4 and ".epel5" on EPEL5; the repotag macro doesn't get defined in Fedora builders and thus nothing will change when building a package for Fedora, even if it has a %{?repotag} in %{release}.
Just a tiny detail, picking a random EPEL package: denyhosts-2.6-4.el5.noarch.rpm then it would/could become: denyhosts-2.6-4.el5.epel5.noarch.rpm
which I think is redundant, repotag should expand to "epel" only for all versions, so we would have: denyhosts-2.6-4.el5.epel.noarch.rpm
el5.epel still seems a bit redundant. Why not just forget the repotag and set the dist tag to epel5?
Jarod Wilson wrote:
Forewarning: I've not paid attention to the entire discussion, but...
Fernando Lopez-Lezcano wrote:
On Thu, 2007-04-26 at 09:04 +0200, Thorsten Leemhuis wrote:
Use a repotag for EPEL4 and EPEL5 like this: add a "%define repotag foo" in the buildsys, where foo expands to ".epel4" in EPEL4 and ".epel5" on EPEL5; the repotag macro doesn't get defined in Fedora builders and thus nothing will change when building a package for Fedora, even if it has a %{?repotag} in %{release}.
Just a tiny detail, picking a random EPEL package: denyhosts-2.6-4.el5.noarch.rpm then it would/could become: denyhosts-2.6-4.el5.epel5.noarch.rpm
which I think is redundant, repotag should expand to "epel" only for all versions, so we would have: denyhosts-2.6-4.el5.epel.noarch.rpm
el5.epel still seems a bit redundant. Why not just forget the repotag and set the dist tag to epel5?
Regardless, (correct me if I'm wrong), but I thought that the EPEL SIG was to only make the *policy* decision on yes/no to repotag, and leave the implementation details to others (like FPC). ???
-- Rex
On Fri, 2007-04-27 at 12:34 -0500, Rex Dieter wrote:
Jarod Wilson wrote:
Forewarning: I've not paid attention to the entire discussion, but...
Fernando Lopez-Lezcano wrote:
On Thu, 2007-04-26 at 09:04 +0200, Thorsten Leemhuis wrote:
Use a repotag for EPEL4 and EPEL5 like this: add a "%define repotag foo" in the buildsys, where foo expands to ".epel4" in EPEL4 and ".epel5" on EPEL5; the repotag macro doesn't get defined in Fedora builders and thus nothing will change when building a package for Fedora, even if it has a %{?repotag} in %{release}.
Just a tiny detail, picking a random EPEL package: denyhosts-2.6-4.el5.noarch.rpm then it would/could become: denyhosts-2.6-4.el5.epel5.noarch.rpm
which I think is redundant, repotag should expand to "epel" only for all versions, so we would have: denyhosts-2.6-4.el5.epel.noarch.rpm
el5.epel still seems a bit redundant. Why not just forget the repotag and set the dist tag to epel5?
Regardless, (correct me if I'm wrong), but I thought that the EPEL SIG was to only make the *policy* decision on yes/no to repotag, and leave the implementation details to others (like FPC). ???
Re: ???, I don't know. Thorsten chose to move the thread here for the reasons he outlined in his initial post.
-- Fernando
Rex Dieter schrieb:
Jarod Wilson wrote:
Fernando Lopez-Lezcano wrote:
Regardless, (correct me if I'm wrong), but I thought that the EPEL SIG was to only make the *policy* decision on yes/no to repotag, and leave the implementation details to others (like FPC). ???
Well, I for one (as a member of the EPEL Steering Committee in this case) don't want to vote on something if I don't know yet what the consequences will be for packagers and users of EPEL, as the decision how to technically realize what we voted on gets done by a different group/committee.
Thus stuff like this needs somehow be decided by EPEL and the FPC together IMHO. That why I started this thread. If something got worked out that looks as being like acceptable for both groups involved *then* I think the time has come for both Steering Committees to vote and realize it.
CU thl
On Fri, 2007-04-27 at 13:04 -0400, Jarod Wilson wrote:
Forewarning: I've not paid attention to the entire discussion, but...
A lot to read here: https://www.redhat.com/archives/epel-devel-list/2007-March/msg00276.html https://www.redhat.com/archives/epel-devel-list/2007-March/msg00258.html https://www.redhat.com/archives/epel-devel-list/2007-March/msg00224.html
Fernando Lopez-Lezcano wrote:
On Thu, 2007-04-26 at 09:04 +0200, Thorsten Leemhuis wrote:
Use a repotag for EPEL4 and EPEL5 like this: add a "%define repotag foo" in the buildsys, where foo expands to ".epel4" in EPEL4 and ".epel5" on EPEL5; the repotag macro doesn't get defined in Fedora builders and thus nothing will change when building a package for Fedora, even if it has a %{?repotag} in %{release}.
Just a tiny detail, picking a random EPEL package: denyhosts-2.6-4.el5.noarch.rpm then it would/could become: denyhosts-2.6-4.el5.epel5.noarch.rpm
which I think is redundant, repotag should expand to "epel" only for all versions, so we would have: denyhosts-2.6-4.el5.epel.noarch.rpm
el5.epel still seems a bit redundant. Why not just forget the repotag and set the dist tag to epel5?
Other distros separate what is called the disttag from the repotag (different concepts, the first is which distro version the package is built for, the second is which repository the package belongs to), it would be nice to keep that in epel so that it is compatible with preexisting usage.
-- Fernando
On 4/27/07, Fernando Lopez-Lezcano nando@ccrma.stanford.edu wrote:
Other distros separate what is called the disttag from the repotag (different concepts, the first is which distro version the package is built for, the second is which repository the package belongs to), it would be nice to keep that in epel so that it is compatible with preexisting usage.
I assume the usage would be along the same lines as dist: * always called as %{?repotag} * containing a leading '.'
/me feels a touch pedantic today
-Chris
On Fri, Apr 27, 2007 at 11:42:55AM -0700, Fernando Lopez-Lezcano wrote:
denyhosts-2.6-4.el5.epel.noarch.rpm
el5.epel still seems a bit redundant. Why not just forget the repotag and set the dist tag to epel5?
Other distros separate what is called the disttag from the repotag (different concepts, the first is which distro version the package is built for, the second is which repository the package belongs to), it would be nice to keep that in epel so that it is compatible with preexisting usage.
So, really, we want %repotag to be ".el" and %dist to be "5"?
Alternately, the repotag should be _hard coded_ in the spec file. (For better or worse.)
On Fri, 2007-04-27 at 14:54 -0400, Matthew Miller wrote:
On Fri, Apr 27, 2007 at 11:42:55AM -0700, Fernando Lopez-Lezcano wrote:
denyhosts-2.6-4.el5.epel.noarch.rpm
el5.epel still seems a bit redundant. Why not just forget the repotag and set the dist tag to epel5?
Other distros separate what is called the disttag from the repotag (different concepts, the first is which distro version the package is built for, the second is which repository the package belongs to), it would be nice to keep that in epel so that it is compatible with preexisting usage.
So, really, we want %repotag to be ".el" and %dist to be "5"?
Repotag is meant for epel[*] only AFAIK, so the repository is not Enterprise Linux but "epel" - which is separate from the base distro.
%dist is already ".elx" for epel, just as it is ".fcx" for fedora, where x stands for the version of the distro. No need to change that.
Alternately, the repotag should be _hard coded_ in the spec file. (For better or worse.)
The reason for not hard coding it is that not doing that enables the same spec file to be used for both epel and extras (or now, fedora).
-- Fernando
[*]Goal: Make high quality packages that get developed and tested in Fedora available for RHEL and compatible derivates like CentOS and Scientific Linux.
On Fri, Apr 27, 2007 at 12:46:26PM -0700, Fernando Lopez-Lezcano wrote:
Alternately, the repotag should be _hard coded_ in the spec file. (For better or worse.)
The reason for not hard coding it is that not doing that enables the same spec file to be used for both epel and extras (or now, fedora).
So, uh, how does it differ from the dist tag at that point? It ends up meaning the same thing.
On Fri, 2007-04-27 at 15:57 -0400, Matthew Miller wrote:
On Fri, Apr 27, 2007 at 12:46:26PM -0700, Fernando Lopez-Lezcano wrote:
Alternately, the repotag should be _hard coded_ in the spec file. (For better or worse.)
The reason for not hard coding it is that not doing that enables the same spec file to be used for both epel and extras (or now, fedora).
So, uh, how does it differ from the dist tag at that point? It ends up meaning the same thing.
disttag: version of the distribution the package was built for. value common to all repos that build for the same distro version. does not say anything about where the package comes from. (it is useful to have it even in the core distribution)
repotag: repository the package comes from. unique value for each repository. value common to all packages in a given repository. does not say anything about the version of the distro the package was built for.
Within a spec file the release tag is appended with either (current usage): %{?dist} expanding to ".elx.epel" or ".fcx" or (suggested usage): %{?dist}%{?repotag} expanding to the same thing.
See Jeff Spaletta's email in this thread for a very very nice explanation of why it exists, how it is done today and potential future directions.
-- Fernando
Jarod Wilson schrieb:
Forewarning: I've not paid attention to the entire discussion, but...
Maybe a wise decision ;-)
Fernando Lopez-Lezcano wrote:
On Thu, 2007-04-26 at 09:04 +0200, Thorsten Leemhuis wrote:
Use a repotag for EPEL4 and EPEL5 like this: add a "%define repotag foo" in the buildsys, where foo expands to ".epel4" in EPEL4 and ".epel5" on EPEL5; the repotag macro doesn't get defined in Fedora builders and thus nothing will change when building a package for Fedora, even if it has a %{?repotag} in %{release}.
Just a tiny detail, picking a random EPEL package: denyhosts-2.6-4.el5.noarch.rpm then it would/could become: denyhosts-2.6-4.el5.epel5.noarch.rpm
which I think is redundant, repotag should expand to "epel" only for all versions, so we would have: denyhosts-2.6-4.el5.epel.noarch.rpm
Fernando is correct, ".epel" should be enough as repotag
el5.epel still seems a bit redundant. Why not just forget the repotag and set the dist tag to epel5?
Disttag is optional, repotag IMHO should not. I think having the two (disttag=dist for which package rot build; repotag=repo where package comes from) separated is the cleanest solution.
CU thl
On Fri, Apr 27, 2007 at 09:18:53AM -0700, Fernando Lopez-Lezcano wrote:
Would it be possible to use the already existing %{?dist} distag and just change the way it is expanded in EPEL alone? That would actually avoid changing the spec file at all. I don't know if this might be a technical no-no for some reason in Fedora's build system.
That was the suggestion I had made as well, and is the best technical solution indeed:
http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting#head-efb18a3ff4e...
"A possible implementation is to extend %{?dist} to include the repotag. Since EPEL is targeting building software out of the former Fedora Extras pool of software which at this point in time uses %{?dist} in 2989 of 3049 (98%) it does indeed already have a disttag everywhere but the epel-release package. So that seems the least intrusive and fastest way to achieve this."
On Sat, 2007-04-28 at 11:58 +0200, Axel Thimm wrote:
On Fri, Apr 27, 2007 at 09:18:53AM -0700, Fernando Lopez-Lezcano wrote:
Would it be possible to use the already existing %{?dist} distag and just change the way it is expanded in EPEL alone? That would actually avoid changing the spec file at all. I don't know if this might be a technical no-no for some reason in Fedora's build system.
That was the suggestion I had made as well, and is the best technical solution indeed:
http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting#head-efb18a3ff4e...
"A possible implementation is to extend %{?dist} to include the repotag. Since EPEL is targeting building software out of the former Fedora Extras pool of software which at this point in time uses %{?dist} in 2989 of 3049 (98%) it does indeed already have a disttag everywhere but the epel-release package. So that seems the least intrusive and fastest way to achieve this."
The only "flaw" in that implementation is that it would not be implemented universally. 98% is not 100%.
If (and this is still a big if) we want to implement repotags for EPEL, I think the best way is to take the packager out of the loop entirely, and append .epel to the release at the buildsystem layer.
So, if you've got %{?dist}, you get:
foo-1.0.0-1.el5.epel
If you don't use %{?dist}, you get
foo-1.0.0-1.epel
The disttag is for marking the distribution for which that package is built for, not the repo from whence it came. The repotag shouldn't be used for version comparison, thus it should be the last significant "digit". Packages shouldn't use it for macro purposes (if I'm built in this repo, do foo, otherwise, do bar). Unlike the disttag, for it to be effective, it needs to be mandatory for the repo (EPEL, in this specific case, not Fedora), and the easiest way to do this (without having people scream at each other) is to have the buildsystem append the repotag to the Release field (in a local copy inside mock) before building the spec.
Thus, it is no additional work for packagers to have to add it to an existing FC spec (EPEL packages just get it when they're built automagically). Its not easily overridden by anyone who decides to be "independent" on this issue. %{?dist} is still optional.
The only catch is that versioned requires/depends with the release integrated need to be careful. 1 < 1.epel, but the same concerns are present with %{?dist} and have mostly been a non-issue.
Thoughts?
~spot
On Sun, Apr 29, 2007 at 07:58:28AM -0500, Tom spot Callaway wrote:
On Sat, 2007-04-28 at 11:58 +0200, Axel Thimm wrote:
On Fri, Apr 27, 2007 at 09:18:53AM -0700, Fernando Lopez-Lezcano wrote:
Would it be possible to use the already existing %{?dist} distag and just change the way it is expanded in EPEL alone? That would actually avoid changing the spec file at all. I don't know if this might be a technical no-no for some reason in Fedora's build system.
That was the suggestion I had made as well, and is the best technical solution indeed:
http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting#head-efb18a3ff4e...
"A possible implementation is to extend %{?dist} to include the repotag. Since EPEL is targeting building software out of the former Fedora Extras pool of software which at this point in time uses %{?dist} in 2989 of 3049 (98%) it does indeed already have a disttag everywhere but the epel-release package. So that seems the least intrusive and fastest way to achieve this."
The only "flaw" in that implementation is that it would not be implemented universally. 98% is not 100%.
But check out the remaining 2%: It's firmware and data files that should not carry a disttag (and they should not even be rebuilt at all).
If (and this is still a big if) we want to implement repotags for EPEL, I think the best way is to take the packager out of the loop entirely, and append .epel to the release at the buildsystem layer.
Same goes for the disttag itself and when I brought up this request some years ago to have an appendable "releasesuffix" macro for rpm the god of rpm loudly laughed and looked away ;)
See for example (no rpm god involved)
http://www.redhat.com/archives/fedora-packaging/2005-February/msg00116.html
| In fact the best solution would be to have a releasesuffix | macro/header tag which rpm automatically tags onto the releasetag, | e.g. | | rpmbuild -bs --define 'releasesuffix .at' foo.spec | | produces the distro agnostic foo-1.2.3-4.at.src.rpm | | rpmbuild --rebuild --define 'releasesuffix rhel4.at' | foo-1.2.3-4.at.src.rpm | | produces foo-1.2.3-4.rhel4.at.i386.rpm | | As a side effect the releasesuffix macro/header tag can be used both | for disttags as well as for repotags, the latter being just a mark of | origin.
On Sun, 2007-04-29 at 17:21 +0200, Axel Thimm wrote:
But check out the remaining 2%: It's firmware and data files that should not carry a disttag (and they should not even be rebuilt at all).
Not all of those packages are things that shouldn't have disttags. Some packagers choose not to use %{?dist} for their own reasons, and I respect that.
If (and this is still a big if) we want to implement repotags for
EPEL,
I think the best way is to take the packager out of the loop
entirely,
and append .epel to the release at the buildsystem layer.
Same goes for the disttag itself and when I brought up this request some years ago to have an appendable "releasesuffix" macro for rpm the god of rpm loudly laughed and looked away ;)
Not at the rpm layer, no, at the buildsystem layer. This is a notable difference.
~spot
On Sun, Apr 29, 2007 at 06:41:58PM -0500, Tom spot Callaway wrote:
On Sun, 2007-04-29 at 17:21 +0200, Axel Thimm wrote:
But check out the remaining 2%: It's firmware and data files that should not carry a disttag (and they should not even be rebuilt at all).
Not all of those packages are things that shouldn't have disttags. Some packagers choose not to use %{?dist} for their own reasons, and I respect that.
Well, still, do have a look and see that the reasons are as stated above. :)
Anyway, that's not that important, the roadblocks are elsewhere.
If (and this is still a big if) we want to implement repotags for
EPEL,
I think the best way is to take the packager out of the loop
entirely,
and append .epel to the release at the buildsystem layer.
Same goes for the disttag itself and when I brought up this request some years ago to have an appendable "releasesuffix" macro for rpm the god of rpm loudly laughed and looked away ;)
Not at the rpm layer, no, at the buildsystem layer. This is a notable difference.
I've tried (and even have code) to manipulate this outside of rpm and it is quite messy. The problem is that you either cheat and don't use the same specfile, or you start fiddling with the rpm headers invalidtaing any signatures on the way.
The latter is of course fixable by resigning the rpm, but it is a rather dirty hack, instead having a simple releasesuffix option to rpm via a macro is more flexible, less a hack and callable by any buildsystem as well.
But to be honest, even a hackish solution is better than no solution.
On Mon, 2007-04-30 at 03:50 +0200, Axel Thimm wrote:
I've tried (and even have code) to manipulate this outside of rpm and it is quite messy. The problem is that you either cheat and don't use the same specfile, or you start fiddling with the rpm headers invalidtaing any signatures on the way.
So, yes. You cheat. You have the buildsystem tag the repotag onto the end of the Release field in its local copy before it builds.
But I'd like to point out that I'm still fundamentally opposed to the repotag, as I've yet to hear what problem it solves, aside from the "other repos want it" problem.
~spot
On Mon, 2007-04-30 at 08:30 -0500, Tom "spot" Callaway wrote:
On Mon, 2007-04-30 at 03:50 +0200, Axel Thimm wrote:
I've tried (and even have code) to manipulate this outside of rpm and it is quite messy. The problem is that you either cheat and don't use the same specfile, or you start fiddling with the rpm headers invalidtaing any signatures on the way.
So, yes. You cheat. You have the buildsystem tag the repotag onto the end of the Release field in its local copy before it builds.
But I'd like to point out that I'm still fundamentally opposed to the repotag, as I've yet to hear what problem it solves, aside from the "other repos want it" problem.
Problem they solve (as I see it): repotags[*] make it easy to spot where packages come from using simple rpm queries (or any other existing tools), which in turn makes it easier to help determine where problems come from when they happen. AFAIK repotags have not caused technical problems when used, they _have_ been useful, and they work now.
Other major repos have asked for inclusion of repotags in EPEL, but that is not the problem.
If EPEL does not include it in their packages it makes it more difficult to find out easily where a package comes from. EPEL is entering an existing ecosystem of repositories and it'd be nice to not make life more difficult for them.
-- Fernando
[*] repotag == short ascii string appended to the end of "Release:" that uniquely ids the repository it comes from.
Fernando Lopez-Lezcano schrieb:
[...] AFAIK repotags have not caused technical problems when used, they _have_ been useful, and they work now.
repotags are part of the release and as such they influence the version-comparison when rpm determinates which rpm package is the newest. Some people call that a "technical problem".
In other words: the repo with the "highest" repotag wins:
[thl@notebook ~]$ rpmdev-vercmp 0 1.1 5 0 1.1 5.at 0:1.1-5.at is newer [thl@notebook ~]$ rpmdev-vercmp 0 1.1 5.at 0 1.1 5.epel 0:1.1-5.epel is newer [thl@notebook ~]$ rpmdev-vercmp 0 1.1 5.epel 0 1.1 5.rf 0:1.1-5.rf is newer [thl@notebook ~]$ rpmdev-vercmp 0 1.1 5.rf 0 1.1 5.zzzzzzzzzz 0:1.1-5.zzzzzzzzzz is newer
[...]
CU thl
Thorsten Leemhuis wrote:
Fernando Lopez-Lezcano schrieb:
[...] AFAIK repotags have not caused technical problems when used, they _have_ been useful, and they work now.
repotags are part of the release and as such they influence the version-comparison when rpm determinates which rpm package is the newest. Some people call that a "technical problem".
In other words: the repo with the "highest" repotag wins:
[thl@notebook ~]$ rpmdev-vercmp 0 1.1 5 0 1.1 5.at 0:1.1-5.at is newer [thl@notebook ~]$ rpmdev-vercmp 0 1.1 5.at 0 1.1 5.epel 0:1.1-5.epel is newer [thl@notebook ~]$ rpmdev-vercmp 0 1.1 5.epel 0 1.1 5.rf 0:1.1-5.rf is newer [thl@notebook ~]$ rpmdev-vercmp 0 1.1 5.rf 0 1.1 5.zzzzzzzzzz 0:1.1-5.zzzzzzzzzz is newer
That doesn't fly with me. Compare that with the repotag-less situation of each repo providing packages with *identical* EVR's. Which is worse?
-- Rex
On Tuesday 01 May 2007, Rex Dieter wrote:
Compare that with the repotag-less situation of each repo providing packages with *identical* EVR's. Which is worse?
IMO having several repositories enabled which ship the same packages [0] is already bad enough to make the repotag discussion pretty much moot.
[0] Same as in same software being packaged in packages that aren't *strictly equal*, no matter what the versions are, let alone release, repotag and friends.
On 5/1/07, Rex Dieter rdieter@math.unl.edu wrote:
That doesn't fly with me. Compare that with the repotag-less situation of each repo providing packages with *identical* EVR's. Which is worse?
Once you have multiple vendors in the mix, each providing packages which may install over a package from another vendor there's no one-size fits all version comparison scheme which will hold. So to answer the question which is worse.. they are both significantly bad enough that your screwed either way.
The only way to really solve the problem is to hold vendor as a separate metric by which to test against in a different way than version comparison. Vendor-ness simply doesn't translate to ordering in a programmatic way. Instead, you hold vendor-ness a parallel collection of namespaces in which you do version comparisons internally. So if I have package foo installed from the Vendor called babyeater, and updates for package foo are available from both the babyeater vendor and the lazybastard Vendors, regardless of how those versions compare, the management tool can be told to stay inside the babyeater namespace for package updates for foo (or be told to ignore vendor-ness completely and gobble the highest versioned packaged based on version comparison rules).
If we had a way to authoritatively identify vendors ( hint gpg sigs ) then you could programmatically instruct a depsolver to always prefer updates from the vendor of the package for which you already have packages installed. If such functionality was possible, I bet it would be implemented in a yum plugin called protectvendor.
-jef"I'm not a glass is half-empty of half-full sort of person. My glass is filled to the brim.. one part tequila, one part nerve gas"spaleta
On Tue, 2007-05-01 at 11:10 +0200, Thorsten Leemhuis wrote:
Fernando Lopez-Lezcano schrieb:
[...] AFAIK repotags have not caused technical problems when used, they _have_ been useful, and they work now.
repotags are part of the release and as such they influence the version-comparison when rpm determinates which rpm package is the newest. Some people call that a "technical problem".
How is having a repotag in the "Release:" tag semantically _different_ from having only a number and an optional disttag?
In other words: the repo with the "highest" repotag wins:
[thl@notebook ~]$ rpmdev-vercmp 0 1.1 5 0 1.1 5.at 0:1.1-5.at is newer [thl@notebook ~]$ rpmdev-vercmp 0 1.1 5.at 0 1.1 5.epel 0:1.1-5.epel is newer [thl@notebook ~]$ rpmdev-vercmp 0 1.1 5.epel 0 1.1 5.rf 0:1.1-5.rf is newer [thl@notebook ~]$ rpmdev-vercmp 0 1.1 5.rf 0 1.1 5.zzzzzzzzzz 0:1.1-5.zzzzzzzzzz is newer
[...]
If I may state the obvious, any component of the "Release:" tag influences the ordering. The numbers there do that, the distag there (if present) does that and the repotag there does that as well. None of the components have a magical meaning that makes it right[1].
Within a given repository the "extra" components (disttag, repotag) are irrelevant as they are a constant. The arbitrary number(s) at the beginning of the "Release:" tag will determine which package is newer, and hopefully packagers and the build system will keep them sane and nicely e-v-r ordered :-)
So, I dare say there are no technical problems within a repository that could be caused by adding a repotag.
Release tag comparison between repositories is meaningless. There is no "right way" of comparing between repositories. Having only a number there has the same _meaning_ in comparisons between repositories as having a number, an optional disttag and a repotag. To restate it differently, if an added repotag is a concern because of the fact that it can define the ordering of packages between repositories, then the already existing number there should raise exactly the same concern as it has _exactly_ the same effect. _All_ of the components of the "Release:" tag, when comparing between repositories, are meaningless.
So, I dare say there are no technical problems in comparing packages between repositories that could be caused by adding a repotag.
[furthermore and in case it was missed, when I wrote "AFAIK repotags have not caused technical problems when used, they _have_ been useful, and they work now." it means what it says, there have NOT been problems with them - there's nothing magical in EPEL that would suddenly cause problems now, I think]
-- Fernando
[1] you can also add letters, numbers, dates, etc that spill from the "Version:" tag to the "Release:" tag when packaging cvs, svn, beta or rc releases.