On 20.05.2007 16:02, Dag Wieers wrote: Thanks for your detailed and helpful feedback. I propose this here for discussion. So if you have a technical solution that could work, but does not confirm to the points of the proposal? Then please show or explain it, that we can consider adjusting the proposal before it's being voted upon. That why I posted it for discussion. Ohh, sorry, I nearly forgot: there is a technical solution that could work. I outlined it in https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01232.html In short: add a %{?repotag} to the end of release in all EPEL spec files, set that in the EPEL builders (not in the Fedora ones) to ".epel" and the solution is there. We could start with it tomorrow -- but we need the Fedora Packaging Committee to agree first, as that's responsible for stuff like this in Fedora. Cu thl

On 20.05.2007 17:36, Dag Wieers wrote: Just out of interest: how? Well, I could live with the buildsys adding it. But I'd prefer not to go with special patches, thus I'd would be best if patches that make this work get integrated directly into mock. But: Nobody said that we need to use it everywhere in Fedora-only packages. But it should be allowed there. That afaics should be acceptable A special repotag macro has one benefit (and that's why I currently think it's the best solution): the spec file could be exchanged easily with other repos. Just define the individual repotag and rebuild one spec file in different repos (dag, CentOS Extras, EPEL, <private repos>, ...). Cu thl Cu thl

On 20.05.2007 18:21, Dag Wieers wrote: Well, that or something similar could be done in the scripts that create the srpm. That would be acceptable (and, btw, not directly "buildsystem" in Fedora-land). No sorry, didn't know that. That was not nice -- we at Fedora could have simply used a different name for the macro. disttag is optional in Fedora-land and some people (including me) want it to stay optional. Cu thl

On 20.05.2007 20:23, Stephen John Smoogen wrote: Sorry, apart from maybe one mail in this sub-thread I found this discussion fruitful to understand each others points. CU thl

On Sun, 20 May 2007, Thorsten Leemhuis wrote: And I agree with Thorsten. Please try to live with my sarcasm, since I do want to shake hands at LinuxTag without hard feelings ! :) Kind regards, -- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]

On 5/20/07, Dag Wieers <dag(a)wieers.com&gt; wrote: My apologies, but I couldnt tell when people were being sarcastic or just plain angry. From someone who is just wanting to get a working cross repo somehow.. it seemed that everything had devolved into a cesspool of comments. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"

On 5/20/07, Jeff Sheltren <sheltren(a)cs.ucsb.edu&gt; wrote: Allow me to add a +1 for discussion of this. Working in an enterprise where Admins sometimes pull packages from a variety of sources, having a repo-tag helps me. I can figure where someone pulled a package. Our internally built packages also have a repotag (abuse of %dist tag actually) but it can be seen easily. I understand how to query rpms for a repo, sadly, many admins/users I work with don't. For the good of the end-user in EL-land, I support a repo tag. The implementation, I hope, could be painless . If EPEL started using repotags, maybe it would drive yum/rpm developers to evaluate its value again and get the proper coding into the packaging products. This isn't about right or wrong, it's about moving in a positive direction for the consumers of EL and ultimately the new EPEL platform. stahnma

On Sun, 20 May 2007, Thorsten Leemhuis wrote: [...] My 5c on the topic I've been trying to avoid because it's too flammable for my taste. I hate politics so I'm not going to get into that, I'm commenting from purely technical POV, and actually have a proposal that might make them unnecessary. Repotags as part of release string are just plain wrong. Unlike disttag, the repotag does not have a meaningful version information in it, it's really just a fuzz-factor to somehow differentiate packages coming from different places. The perfect repotag would actually be the package's gpg signature: - it's not involved in version comparison - it can't be faked by locally rebuilding a package - it's recorded in rpmdb so it's possible to see where a package came from For depsolvers, you need some sort of priorisation mechanism anyway to make any sense out of mixed repository situation. So the repotag mostly serves as a visual clue to humans. All the major depsolvers now have some means to priorize between repositories so what the actual rpm EVR string is doesn't really matter, what's missing is the visual clue. Now, I hereby volunteer to write a script/popt-alias/whatever that will do the necessary mapping of gpg signature into something human readable so people can diagnose their repo-mixing problems and whatnot easily. So you'd get something resembling the below: $ repotag -q foo bar foo-1.2-4.el5 (EPEL) bar-2.3-1.el5 (ATrpms) Would something like that be enough for the "repotag folks", short term? Long-term, more than that's needed to really solve the issues with repository mixing. One (perhaps crazy) idea is turning repotags into namespaces, and dependencies are first looked up within that namespace and only if unsolved, other namespaces are looked at in (configurable) order. An example (please excuse the :: notation, that's not a good choice but for examples sake...): assume we have packages foo and bar which both depend on glibc, and foo additionally depends on bar. Foo and bar are available from, say, both EPEL and ATrpms: rhel::libxml2-2.6.28-1 epel::foo-1.2-1 atrpms::foo-1.2-1 epel::bar-2.4-5 atrpms::bar-2.4-1 If you install atrpms::foo, as atrpms namespace also provides bar, that one gets selected instead of epel::bar even though it's evr is higher. The actual namespace could internally be the gpg signature, only mapped to a human readable where exposed to the user. Sound crazy enough? ;) - Panu -

On Wed, 23 May 2007, Tim Lauridsen wrote: It does have meaningful version information in a multi-repository world. It shows what version of the package you have. rf means this is the RPMforge version. It makes the package/filename/version unique ! Granted, the repotag does not have any real meaning in "version comparison" between packages from different repositories. Neither does the release tag. The release tag has no meaningful version information between packages from different repositories. It is not a perfect repotag for other reasons: - It doesn't make the filename unique (or gives insight of the package before downloading) - It is not shown when one has dependency problems, either on yum, apt or rpm level The major depsolvers lack a meaningful way for a user to provide a policy of what they want to do with repositories or packages. Some plugins do allow somewhat more, but there are many shortcomings and without repotags errors are at first sight inexplicable or confusing. Especially when packages from different repositories have the same NEVR, similar sub-packages and have dependencies between them. The clamav package is a nice example. Without repotags, dependencies would exists between packages from different repositories. Saying that repotags have no meaningful version information is very wrong. It makes the system work. It doesn't help for dependency problems. In this case it shows what a working rpmdb consists of. Necessary, but not sufficient to replace a repotag implementation as it is. The namespace idea is an interesting one and when it gets implemented and is ready is surely an alternative to repotags. But it is not ready and will not be in EL2.1, EL3, EL4 or EL5. So we cannot consider it an alternative because we cannot use it now. It's not that I'm unwilling to see an alternative, it's just that there is NO alternative to repotags that cover it's different uses. It doesn't solve real problems as it is not a realistic solution yet. Kind regards, -- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]

On Wed, 23 May 2007, Dag Wieers wrote: Ah, a good point which I didn't think of at all, sorry about that. I was only talking about version information in the "newer/older than another package of same name" sense. Yes, repotag-in-release allows sub-package dependencies to be expressed in a way that prevents accidental mixing of sub-packages of same name from other repositories. It would be of course possible to express that by using additional virtual provides-requires pairs but that adds a fair bit of manual work for little or no gain. Repository namespaces would help :) But the root issue here I think is that sub-packages often should and could have a stronger dependencies on each other than the typical "Requires: %{name} = %{version}-%{release}". In other words, one would want the sub-package dependency to only match packages originating from the same *build*. Something like "Requires: %{name} = %{buildid}" where the build id is a hash computed from version, release, arch, buildhost, buildtime plus possibly bunch of other things, and automatically injected into provides. It's just that the actual issues tend to get lost in all the noise. At least I haven't had the stamina to read through all of the repotag discussions, because the "to repotag or not to repotag" question itself is totally irrelevant and uninteresting to me. The actual problems, not the bandaid, is what I'm interested in. - Panu -

On Thu, 24 May 2007, Panu Matilainen wrote: Yes, that would replace one of the things that repotags are useful for. But not the most important. They make the version/release unique. (cross-repository) This has (now) become the most overlooked benefit of repotags :) Oh, I do not object in engineering future solutions. But that's not what we are discussing within EPEL or RPMforge. We create packages that are available for 7 years ! RHEL5 has just been released and we'll have packages going into 2014. We'll have to see if EPEL actively supports RHEL5 when RHEL7 is release, like RPMforge actively supports RHEL2.1 and RHEL3 now. As I mentioned to you before, Panu, is that my last contract was to migrate RHEL2.1 to RHEL3 ! Yes, in 2007 companies migrate to RHEL3. Reasons are vendor-support of tested applications. That's production. New systems are being deployed with RHEL4 now as well, but RHEL3 is what most of production is using. People that now start afresh with RHEL5 are just lucky chaps, living a bit on the edge :) True, it does not necessarily fix all problems. But the most obvious ones are the subpackages depending on each other and on the base package. Right. It helps a bit, plus it adds the other benefits that others may not validate as a requirement. At this point it's either bandaid or nothing. I'd prefer the bandaid, thos prefering nothing do not see the whole repository picture but look inside EPEL only. Existing RPMforge/ATrpms/CentOS users beware ! Kind regards, -- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]