[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [users] Dropping the repotag
- From: Thorsten Leemhuis <fedora leemhuis info>
- To: EPEL development disccusion <epel-devel-list redhat com>
- Subject: Re: [users] Dropping the repotag
- Date: Sun, 18 Mar 2007 15:06:38 +0100
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
Please bring that up to the Fedora Packaging committee on
fedora-packaging 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.
> ---------- Forwarded message ----------
> From: Dag Wieers <dag wieers com>
> To: Andreas Rogge <a rogge solvention de>
> Cc: RPMforge <users lists rpmforge net>,
> Nicolas Thierry-Mieg <Nicolas Thierry-Mieg 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
>>> 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
>>> 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
>> 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 wieers com, http://dag.wieers.com/ --
> [all I want is a warm bed and a kind word and unlimited power]
> users mailing list
> users lists rpmforge net
> epel-devel-list mailing list
> epel-devel-list redhat com
[Date Prev][Date Next] [Thread Prev][Thread Next]