[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: My thoughts on repotag



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 redhat com
https://www.redhat.com/mailman/listinfo/epel-devel-list


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]