My thoughts on repotag

Axel Thimm Axel.Thimm at ATrpms.net
Mon Mar 19 08:15:08 UTC 2007


On Sun, Mar 18, 2007 at 10:05:27PM -0500, Tom 'spot' Callaway wrote:
> 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.

That is not the problem space the repotag tries to address. If you are
as far as to whether a repotag matters or not, you already lost the
game, Still ...

> Is this better than having two repositories with the same n-v-r? I don't
> think so.

... it is better to have any of the two win, than to have two
identical packages of which yum and any other depsolver throws a dice
to chose. Because in the later case you get both unreproducable bugs
(50% pick the left package, and 50% the right) as well as users and
bug assignees unsuspecting of the real cause since the reported
package does existing in exactly that nvr in the repo. At the end this
will lead to enough frustration on all sides to use only repo A or B.

So even in this problem repotags are helpful, and are not causing any
harm by themselves.

> 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?
> 
> 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.

Fedora Extras was from the beginning a merger of RHL and
Fedora.us. Technically it took longer to make that happen, and with F7
we're there. The separation in Core and Extras was like Red Hat vs
Community - dropping the repotag was both sane (it was intended to
become one) and *political*, because you didn't want to mark community
packages different than the big brother's.

So it was a proper call to make IMHO. And in this case it is similar
argumentation: Is RHEL and EPEL to become a merged project? Most
probably not. Is it politically wise to add a repotag? It depends on
the messege you want to deliver: No repotag means "We assume we are
the only or main repo supporting RHEL, we don't care about other 3rd
parties that may have established". A repotag means "We're the new
kids on the block and are playing in the game like everybody else".

> 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.

How often have you seen a Vendor tag queried by end users or used on an
online repo? And how often is it even set properly by various 3rd
party repos?

> 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.

That would break quite a lot of admin scripts that scrape the output of
rpm, and believe me every RHEL admin out there has his bash scripts.

We had this discussion a long time ago (adding epochs in the display),
and had to drop this idea. I don't think that we'll have better
arguments to change rpm's output on RHEL.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20070319/c94c5f06/attachment.sig>


More information about the epel-devel-list mailing list