My thoughts on repotag

[Greg Swallow]

Tom 'spot' Callaway wrote:
> It seems like everyone keeps asking me in private to speak on the topic
> of using a repotag for EPEL, probably since I'm the one who decided to
> not use one for Fedora Extras (the decision predates the Fedora
> Packaging Committee).
>
> The first problem I have with overloading Release with a repotag is that
> we start to play games between repositories:
>
> foo-1.0.0-1.el5.epel < foo-1.0.0-1.el5.notepel
>
> Is it really? Nah. This is just RPM trying to make sense of what we've
> shoved in there.
>
> Is this better than having two repositories with the same n-v-r? I don't
> think so. We're not really solving this problem by using the repotag.
> We're now in the realm of "my repotag is considered larger than yours by
> RPM". We might as well be playing games with epoch. Is this the intent?
> Almost certainly not, but it is the side-effect.
I think it's more useful to know that two packages are different than 
worry about the repotag with the exact same release and higher 
alphabetical version winning.  Then at least when someone uses yum to 
upgrade from foo-0.9.9 and it fails because of a dependency, they know 
whose package is trying to be installed from the output of yum.
> Fedora Extras succeeded in this by having very good packages. If the
> primary repository has good packages, there is less need for other
> repositories to conflict. So, is EPEL intended as the primary repository
> for Enterprise Linux addon packages?
>   
Well it certainly isn't yet.  And to get the cooperation of the primary 
repository (Dag) would be smart IMO, especially if the goal is 
cooperation and having a package removed from the other repositories 
once it's in EPEL.
> Now, I absolutely don't mean this to imply that other EL addon
> repositories are lesser, bad, whatever. I'm simply noting how Fedora
> Extras managed to get by without having a repotag.
>
> I'd very much like to see EPEL as a place where packagers can put their
> FLOSS bits that aren't legally encumbered in the US. If we succeed in
> that, then rpm package conflicts are less likely.
I agree that it makes sense (in most cases) to have one package in one 
repository, and I think EPEL is fine place for that to happen as it lets 
interested people maintain packages they're interested in.  But 
maintainers should check if the package they are going to branch for 
EPEL is in another EL addon repository and check it will upgrade that 
package cleanly.  And then convince and give some time for the EL addon 
repository to communicate to their users that enabling the EPEL 
repository is needed, before they stop packaging (or updating) a certain 
package for EL4 or EL5.  I suggested an addition to the EPEL guidelines 
regarding that already a few days ago on this list.
> The second problem is determining where a package came from. This seems
> like a legitimate problem, but I'm not convinced that using a repotag is
> the best solution. To me, this seems like a better use for the Vendor
> tag. Now, if we use the Vendor tag, the problem becomes that users don't
> see the Vendor tag when they query the package to file a bug.
>   
If the vendor tag was more descriptive than "Fedora" that would be good 
too.  (ie.  "Fedora EPEL-4" or "Fedora EPEL-5").
> The %{_query_all_fmt} tag controls the output that users see when they
> query installed package(s). Perhaps EPEL users (with epel-release
> package installed) get a%{_query_all_fmt} redefined to
> %{name}-%{version}-%{release}.%{vendor} (or something like that). Then,
> the origination repository is clear on an rpm query, so we solve this
> problem, without overloading Release.
>   
The other problem discussed already is packages that aren't installed - 
ie, failed yum upgrades, which does not show the repository of a package 
to be updated until it has a list of packages to be installed.
> I always prefer to discuss problems and possible ways to solve them (and
> then try to find the least intrusive way). :)
>   
Good plan :)

Greg
> ~spot
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>