[users] Dropping the repotag

Sun Mar 18 14:06:38 UTC 2007

Dag Wieers schrieb:
> Maybe the below discussion could help introduce the repotag in EPEL.
> 
> Please let me know when the repotag will be decided for EPEL

As I told you in
https://www.redhat.com/archives/epel-devel-list/2007-March/msg00242.html

Please bring that up to the Fedora Packaging committee on
fedora-packaging at redhat.com, those guys are the ones that are
responsible for the Packaging Standard used in both EPEL and Fedora.

The offer still stands: I can forward this discussion/your mail there if
you want. But the only position in this stuff I'll take is "Let the
Packaging Committee" decide.

Cu
thl

> ---------- Forwarded message ----------
> From: Dag Wieers <dag at wieers.com>
> To: Andreas Rogge <a.rogge at solvention.de>
> Cc: RPMforge <users at lists.rpmforge.net>,
>     Nicolas Thierry-Mieg <Nicolas.Thierry-Mieg at imag.fr>
> Date: Sun, 18 Mar 2007 14:37:12 +0100 (CET)
> Subject: Re: [users] Dropping the repotag
> 
> On Sun, 18 Mar 2007, Andreas Rogge wrote:
> 
>> On Sat, 17 Mar 2007, Dag Wieers wrote:
>>> On Sat, 17 Mar 2007, Andreas Rogge wrote:
>>>
>>>> What if you could use for example "listrpms --vendor RPMForge" 
>>>> instead of "rpm -qa | grep rf" and get a 100% result without 
>>>> false-positives?
>>> It will not tell you which nagios-2.8-4.el5 breaks a dependency chain. 
>>> Was it the one from EPEL or the one from RPMforge ? Both have the 
>>> exact same release.
>>>
>>> yum doesn't say, you cannot query it because it is not installed. 
>>> Hell, since both have the same filename you won't even know by querying the 
>>> repositories.
>>>
>>> This is not solvable unless you either improve yum to report all other 
>>> information (including keys and/or other tags), which still doesn't 
>>> fix all the other tools and is plain confusing. Or if you make the 
>>> filename more unique, which is what the repotag does.
>>>
>>> BTW rpm -qa | grep '\.rf$' is pretty conclusive _if_ everybody follows 
>>> the same standard and you require packages to be signed.
>>>
>>> BTW2 Dissing the repotag usefulness is like dissing the disttag 
>>> usefulness. It is as arbitrary, makes the release longer and is in 
>>> essence not required. Still it has its use.
>> First of all: yes, you're right.
>>
>> But we will face this issue with EPEL. A repotag will not help to blame
>> EPEL when something breaks (they don't have one). It will only help to
>> blame RPMForge (as RPMforge has one). 
> 
> That's why EPEL should have one. At least until something better comes 
> around (if there ever will).
> 
> People say a repotag should not be in the filename. But a filename is 
> there to identify what it is. The version is there to identify what it is, 
> just like the name and the arch. All of these are not required in the 
> package name. In fact, rename whatever package you have to "this_package"
> (without the arch, without the extension) and rpm handles that fine, 
> because it doesn't use the information in the filename, it uses the 
> header. So the filename is there for the user to identify what it is.
> 
> So what's wrong with having the repotag, like the disttag and like the 
> version and name in the filename ? It helps (at least) some people as much 
> as all that other information and it solves a practical problem with 
> yum/rpm and other tools that cannot give all that other information right 
> there when we need it. (and if they would, most people wouldn't understand 
> why the signature or an arbitrary string is there the moment you have a 
> dependency problem).
> 
> 
>> I don't think repotags should be dropped because they suck. I just think
>> that they're a workaround for broken/incomplete tools and have been in
>> place for too long. Hell, neither rpm nor yum nor anything else actually
>> knows there is something like a repotag. They just display it because we
>> hijack the package signature.
> 
> It is a work around. Why else the disttag ? The repotag is arguably as 
> useful as the disttag in the filename. Would you argue against the disttag 
> in the same way ? In fact why have the release there at all. And the 
> architecture ? Most people don't know what that means anyway.
> 
> 
>> People will need better tools anyway, because nobody will be able to
>> tell the difference between an EPEL and a base distro package. I think
>> yum should actually tell you vendor and distro on all packages.
> 
> The problem is, even when you have 'better' tools, how would they present 
> that information without filling the screen and actually helping to 
> understand the information. The repotag is short and doesn't add as much 
> noise as a signature or an arbitrary string would cause.
> 
> I don't think it is practically fixable (if anybody would ever care to fix 
> RPM and backport it to EL2.1, EL3, EL4 and now EL5 -> NEVER). So whatever 
> 'better' technical solution you propose, it wouldn't be useful until EL5 
> is out of support.
> 
> And not to be kidding, we had this discussion when EL3 was released and 
> you know what: people also said it was not the correct solution. Do we 
> have a correct solution today ? No. Will we have one tomorrow ? No.
> 
> So why postpone a solution until we have a better one ? Especially when we 
> cannot define what a better solution would look like and we cannot fix the 
> tools.
> 
> 
>> We already had similar issues on x86_64 where you couldn't tell the
>> difference between i386 and x86_64 packages. Today yum reports every
>> package with its arch.
> 
> Right. So more information is better. How would you ideally present the 
> repository info in the output when there's a problem. The repotag is the 
> most preferred (read: shortest) way IMNSHO.
> 
> Kind regards,
> --   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
> [all I want is a warm bed and a kind word and unlimited power]
> _______________________________________________
> users mailing list
> users at lists.rpmforge.net
> http://lists.rpmforge.net/mailman/listinfo/users
> 
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
> 