Repotag in EPEL

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

 

Hi,

I'd like to ask the Packaging Committee (which afaics is responsible for
the Packaging standards used in Fedora projects, which includes EPEL)
for advice and a formal decision about using a repotag in EPEL. There
are a lot of people strongly urging to use one -- see attached mails or
the threads in the online archive at

https://www.redhat.com/archives/epel-devel-list/2007-March/msg00224.html
https://www.redhat.com/archives/epel-devel-list/2007-March/msg00258.html

I (and some other EPEL SIG members afaics) don't care much about using
one or not. But afaics the use of a repotag is unwanted in Fedora-land
up to now afaics.

If the answer from the PC is "yes, EPEL is free to use a repotag" then
please decide how to actually use it -- Add a "repotag" macro defined by
the buildsys or overload %{dist}, ...

We need a decision soon. Thanks for your support.

CU
thl
--- Begin Message --- 
Hi,

Could you please add a repotag to your EPEL packages ?

I know you guys think you have enough authority to not require a repotag.
And you generally do not care because the default policy will be to tell 
people other packages than EPEL are dangerous. (look at the release to 
identify a package)

But by not tagging your packages, you take advantage of the fact that 
other repositories play nice and *do* tag their packages.

But what will happen if I (and other repositories) start doing the same 
thing and drop the repotag ?

I don't know if I have to start threaten to make you see the light, but I 
strongly consider dropping the repotag if Fedora and Red Hat cannot play 
nice.

Thanks for taking notice.
--   dag wieers,  dag@xxxxxxxxxx,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]

_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--- Begin Message --- 
Once upon a time Wednesday 14 March 2007, Dag Wieers wrote:
> Hi,
>
> Could you please add a repotag to your EPEL packages ?

We do we use .elX  as has been defined in the Fedora guidelines since it was 
started

> I know you guys think you have enough authority to not require a repotag.
> And you generally do not care because the default policy will be to tell
> people other packages than EPEL are dangerous. (look at the release to
> identify a package)
>
> But by not tagging your packages, you take advantage of the fact that
> other repositories play nice and *do* tag their packages.
>
> But what will happen if I (and other repositories) start doing the same
> thing and drop the repotag ?
you are free to use .elX also  that is perfectly ok. if  you do i would ask 
that you set the Vendor tag.  which you probably already do.

If you do a rpm -qi on a epel package you will get something like
rpm -qip nagios-2.7-2.el4.x86_64.rpm
warning: nagios-2.7-2.el4.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 
217521f6
Name        : nagios                       Relocations: (not relocatable)
Version     : 2.7                               Vendor: Fedora Project
Release     : 2.el4                         Build Date: Tue 06 Feb 2007 
01:16:24 PM EST
Install Date: (not installed)               Build Host: 
xenbuilder1.fedora.redhat.com
Group       : Applications/System           Source RPM: 
nagios-2.7-2.el4.src.rpm
Size        : 4434495                          License: GPL
Signature   : DSA/SHA1, Fri 02 Mar 2007 06:23:16 PM EST, Key ID 
119cc036217521f6
Packager    : Fedora Project <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.nagios.org/
Summary     : Host/service/network monitoring program



> I don't know if I have to start threaten to make you see the light, but I
> strongly consider dropping the repotag if Fedora and Red Hat cannot play
> nice.

Seriously feel free to use the same disttag as we use.  Please help me to 
understand better what it is that you want to achieve and what exactly you 
mean  by tagging packages.  

Dennis

Attachment: pgps2n8LDwpPd.pgp
Description: PGP signature

_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--- Begin Message --- 
On Wed, 14 Mar 2007, Dennis Gilmore wrote:

> Once upon a time Wednesday 14 March 2007, Dag Wieers wrote:
> > Hi,
> >
> > Could you please add a repotag to your EPEL packages ?
> 
> We do we use .elX  as has been defined in the Fedora guidelines since it was 
> started

That's what we call a disttag. It identifies for what distribution 
something is build. (Even though it is not enforced, this helps people 
that dowxnload and install packages manually)

A disttag doesn't say where a package comes from. A repotag does. And even 
when that doesn't guarantee anything as anyone can fake that, just like 
the disttag, it helps people to identify who to report problems too. Or 
helps to identify who's responsible from command-line output.

 
> > I know you guys think you have enough authority to not require a repotag.
> > And you generally do not care because the default policy will be to tell
> > people other packages than EPEL are dangerous. (look at the release to
> > identify a package)
> >
> > But by not tagging your packages, you take advantage of the fact that
> > other repositories play nice and *do* tag their packages.
> >
> > But what will happen if I (and other repositories) start doing the same
> > thing and drop the repotag ?
>
> you are free to use .elX also  that is perfectly ok. if  you do i would ask 
> that you set the Vendor tag.  which you probably already do.

Sure, the vendor tag however is not seen from copy&pasted yum output. ANd 
is harder to grep for when doing package lists. (although not entirely 
impossible, but that's not the point here)

 
> > I don't know if I have to start threaten to make you see the light, but I
> > strongly consider dropping the repotag if Fedora and Red Hat cannot play
> > nice.
> 
> Seriously feel free to use the same disttag as we use.  Please help me to 
> understand better what it is that you want to achieve and what exactly you 
> mean  by tagging packages.  

[dag@rhun ~]# ls -l /dar/packages/nagios/*el*2.8*
-rw-r--r--  3 root root 35592 Mar 10 17:42 /dar/packages/nagios/nagios-devel-2.8-1.el3.rf.i386.rpm
-rw-r--r--  3 root root 35575 Mar 10 17:42 /dar/packages/nagios/nagios-devel-2.8-1.el3.rf.x86_64.rpm
-rw-r--r--  3 root root 35606 Mar 10 17:42 /dar/packages/nagios/nagios-devel-2.8-1.el4.rf.i386.rpm
-rw-r--r--  3 root root 35580 Mar 10 17:42 /dar/packages/nagios/nagios-devel-2.8-1.el4.rf.x86_64.rpm
-rw-r--r--  3 root root 37123 Mar 10 17:42 /dar/packages/nagios/nagios-devel-2.8-1.el5.rf.i386.rpm
-rw-r--r--  3 root root 37027 Mar 10 17:42 /dar/packages/nagios/nagios-devel-2.8-1.el5.rf.x86_64.rpm
-rw-r--r--  3 root root 35554 Mar 10 17:42 /dar/packages/nagios/nagios-devel-2.8-1.rh9.rf.i386.rpm

Kind regards,
--   dag wieers,  dag@xxxxxxxxxx,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]

_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--- Begin Message --- 
Hi!

On 14.03.2007 12:49, Dag Wieers wrote:
> Could you please add a repotag to your EPEL packages ?
> [...]

<disclaimer>I don't care much about having a repotag or not: I'm fine
going with or without one.</disclaimer>

I think this decision is in the hands of the Fedora Packaging Committee,
as that was set in place to maintain packaging guidelines across the
different Fedora repositories -- that was Core and Extras in the past,
now it's the Fedora Repository and EPEL afaics.

I talked to some members of the Packaging Committee on IRC. Seems a
repotag is unwanted. I can accept that. If somebody inside or outside
EPEL or Fedora dislikes that it's best to bring this issue up on the
Packaging Committee list fedora-packaging:
https://www.redhat.com/archives/fedora-packaging/

I can forward the issue there, too, but I'm not going to advocate for
either side in this game (¹). Those that care have to do that themselves.

CU
thl

(¹) -- the only thing I'll advocate for on is having this problem solved
once for all of Fedora, and as such it's IMHO in the hands of the
Packaging Committe (thus this mail).

_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--- Begin Message --- 
On Wed, 14 Mar 2007, Thorsten Leemhuis wrote:

> On 14.03.2007 12:49, Dag Wieers wrote:
> > Could you please add a repotag to your EPEL packages ?
> > [...]
> 
> <disclaimer>I don't care much about having a repotag or not: I'm fine
> going with or without one.</disclaimer>
> 
> I think this decision is in the hands of the Fedora Packaging Committee,
> as that was set in place to maintain packaging guidelines across the
> different Fedora repositories -- that was Core and Extras in the past,
> now it's the Fedora Repository and EPEL afaics.
> 
> I talked to some members of the Packaging Committee on IRC. Seems a
> repotag is unwanted. I can accept that. If somebody inside or outside
> EPEL or Fedora dislikes that it's best to bring this issue up on the
> Packaging Committee list fedora-packaging:
> https://www.redhat.com/archives/fedora-packaging/
> 
> I can forward the issue there, too, but I'm not going to advocate for
> either side in this game (¹). Those that care have to do that themselves.

The problem is not a Fedora one. Since Fedora is considered a distribution 
and the distribution never has a repotag. EPEL is not part of the 
distribution and therefor does require a repotag to identify where 
packages come from.

At least if you believe in the purpose of a repotag. If you don't and 
cannot envision what would happen if no repository ever had a repotag,
then there lies the problem.

If I hadn't a repotag, my nagios-packages would be numbered the same as 
the EPEL packages. Including the same release tag. If people then have 
problems, nobody could tell from the output whether this was an EPEL, 
non-EPEL, RPMforge or other package.

The only reason why EPEL now can 'assume' that this is an EPEL package is 
because most of the other players play nice and use a repotag. For that 
reason EPEL should have a repotag. It is as much a community-member as the 
other repositories.

This is an EPEL issue, not a Fedora issue. Why could there not be a rule 
that says Fedora packages do not have a repotag, but EPEL packages will ?

Kind regards,
--   dag wieers,  dag@xxxxxxxxxx,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]
_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--- Begin Message --- 
Dag Wieers wrote:
If I hadn't a repotag, my nagios-packages would be numbered the same as the EPEL packages. Including the same release tag. If people then have problems, nobody could tell from the output whether this was an EPEL, non-EPEL, RPMforge or other package.
I can think of a couple ways to figure this out, none of which are very difficult. Buildhost, vendor, packager, and key signature come to mind.
This is an EPEL issue, not a Fedora issue. Why could there not be a rule that says Fedora packages do not have a repotag, but EPEL packages will ?
Because its just one more thing to maintain/change/whatever that so far has only one supporter. 

   -Mike

_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--- Begin Message --- 
On Thu, 15 Mar 2007, Mike McGrath wrote:

> Dag Wieers wrote:
> > If I hadn't a repotag, my nagios-packages would be numbered the same as the
> > EPEL packages. Including the same release tag. If people then have problems,
> > nobody could tell from the output whether this was an EPEL, non-EPEL,
> > RPMforge or other package.
>   
> I can think of a couple ways to figure this out, none of which are very
> difficult.  Buildhost, vendor, packager, and key signature come to mind.

You can't tell all that from a posting on a forum. The problem is not that 
you can get that information from somewhere, the problem is that you have 
to have more communication via email/forums to get that information.


> > This is an EPEL issue, not a Fedora issue. Why could there not be a rule
> > that says Fedora packages do not have a repotag, but EPEL packages will ?
>
> Because its just one more thing to maintain/change/whatever that so far has
> only one supporter.

Fine, RPMforge will be dropping the repotag as well.

Kind regards,
--   dag wieers,  dag@xxxxxxxxxx,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]

_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--- Begin Message --- 
Mike McGrath wrote:
> Dag Wieers wrote:
> > If I hadn't a repotag, my nagios-packages would be numbered the same
as
> > the EPEL packages. Including the same release tag. If people then
have
> > problems, nobody could tell from the output whether this was an
EPEL,
> > non-EPEL, RPMforge or other package.
> >
> I can think of a couple ways to figure this out, none of which are
very
> difficult.  Buildhost, vendor, packager, and key signature come to
mind.

What about if you don't have the package installed?  If you have a
failed 'yum upgrade' and are trying to figure out what's happening you
only see the name/arch/epoch/version/release while it's resolving
dependancies and if Dag takes away the repotag, using his example, 'yum
list nagios' would show that 2 versions of nagios named identically are
available.

> > This is an EPEL issue, not a Fedora issue. Why could there not be a
rule
> > that says Fedora packages do not have a repotag, but EPEL packages
will
> ?
> >
> Because its just one more thing to maintain/change/whatever that so
far
> has only one supporter.

You can add me as a supporter even just for the reason of keeping Dag
happy.  If you want everyone to work together (Dag, ATrpms, CentOS,
EPEL) then respecting each others concerns is a good start.  Adding
%{repotag} is really not that big of a deal, is it?
 
Greg

_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--- Begin Message --- 
On Thu, Mar 15, 2007 at 10:34:26AM -0700, Greg Swallow wrote:
> Mike McGrath wrote:
> > Dag Wieers wrote:
> > > If I hadn't a repotag, my nagios-packages would be numbered the same
> as
> > > the EPEL packages. Including the same release tag. If people then
> have
> > > problems, nobody could tell from the output whether this was an
> EPEL,
> > > non-EPEL, RPMforge or other package.
> > >
> > I can think of a couple ways to figure this out, none of which are
> very
> > difficult.  Buildhost, vendor, packager, and key signature come to
> mind.
> 
> What about if you don't have the package installed?  If you have a
> failed 'yum upgrade' and are trying to figure out what's happening you
> only see the name/arch/epoch/version/release while it's resolving
> dependancies and if Dag takes away the repotag, using his example, 'yum
> list nagios' would show that 2 versions of nagios named identically are
> available.
> 
> > > This is an EPEL issue, not a Fedora issue. Why could there not be a
> rule
> > > that says Fedora packages do not have a repotag, but EPEL packages
> will
> > ?
> > >
> > Because its just one more thing to maintain/change/whatever that so
> far
> > has only one supporter.
> 
> You can add me as a supporter even just for the reason of keeping Dag
> happy.  If you want everyone to work together (Dag, ATrpms, CentOS,
> EPEL) then respecting each others concerns is a good start.  Adding
> %{repotag} is really not that big of a deal, is it?

FWIW I would support it, too, and it's even easier than defining
%repotag, just define %disttag to be "el5.epel" or similar. E.g for
ATrpms I use disttags like "fc6.at", "el5.at" etc.
-- 
Axel.Thimm at ATrpms.net

Attachment: pgp8qceeRbSpr.pgp
Description: PGP signature

_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--- Begin Message --- On Thu, 2007-03-15 at 10:34 -0700, Greg Swallow wrote:
You can add me as a supporter even just for the reason of keeping Dag
happy.  If you want everyone to work together (Dag, ATrpms, CentOS,
EPEL) then respecting each others concerns is a good start.  Adding
%{repotag} is really not that big of a deal, is it?

+1

A "Red Hat community" standard on this would avoid a lot of confusion on the part of users who have enabled multiple repos, and would lead to fewer problems being incorrectly reported to the wrong maintainers/packagers.

Phil


Phil

_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--- Begin Message --- 
Greg Swallow wrote:
> Mike McGrath wrote:
>> Dag Wieers wrote:
>>> If I hadn't a repotag, my nagios-packages would be numbered the same
> as
>>> the EPEL packages. Including the same release tag. If people then
> have
>>> problems, nobody could tell from the output whether this was an
> EPEL,
>>> non-EPEL, RPMforge or other package.
>>>
>> I can think of a couple ways to figure this out, none of which are
> very
>> difficult.  Buildhost, vendor, packager, and key signature come to
> mind.
> 
> What about if you don't have the package installed?  If you have a
> failed 'yum upgrade' and are trying to figure out what's happening you
> only see the name/arch/epoch/version/release while it's resolving
> dependancies and if Dag takes away the repotag, using his example, 'yum
> list nagios' would show that 2 versions of nagios named identically are
> available.

Not a good example. The repo the package is in is listed in the output
of yum list.

# yum list kernel
Loading "installonlyn" plugin
Installed Packages
kernel.ia64           2.6.20-2.2975.bz231219 installed
kernel.ia64           2.6.20-1.2966.fc7      installed
Available Packages
kernel.ia64           2.6.20-1.2987.fc7      development

>>> This is an EPEL issue, not a Fedora issue. Why could there not be a
> rule
>>> that says Fedora packages do not have a repotag, but EPEL packages
> will
>> ?
>> Because its just one more thing to maintain/change/whatever that so
> far
>> has only one supporter.
> 
> You can add me as a supporter even just for the reason of keeping Dag
> happy.  If you want everyone to work together (Dag, ATrpms, CentOS,
> EPEL) then respecting each others concerns is a good start.  Adding
> %{repotag} is really not that big of a deal, is it?

I'm sort of up in the air on this one. Fedora Extras is, er, was, an
official project endorsed by RH, had no repotag, and EPEL is just an
extension of this same project. Since its an official repo, it requires
no repotag to identify the package. Of course, Fedora and RHEL are a wee
bit different, and making the distinction that's easy to see at a glance
between core RHEL packages and EPEL-for-RHEL certainly does have some
merit that it doesn't have (or didn't when Extras was separate) in
Fedora-land. It would likely be of help to RH support if they could tell
if a package was from RHEL-proper or from EPEL without having to look
anything up...

-- 
Jarod Wilson
jwilson@xxxxxxxxxx

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--- Begin Message --- 
Jarod Wilson wrote:
> Not a good example. The repo the package is in is listed in the output
> of yum list.
> 
> # yum list kernel
> Loading "installonlyn" plugin
> Installed Packages
> kernel.ia64           2.6.20-2.2975.bz231219 installed
> kernel.ia64           2.6.20-1.2966.fc7      installed
> Available Packages
> kernel.ia64           2.6.20-1.2987.fc7      development

Yes, but if dag and epel had the same package name/version/release (and
no repotag) you might see:

Available Packages
nagios.i386 	2.8-1.el4 	dag
nagios.i386 	2.8-1.el4 	epel

If a yum upgrade fails while looking for a dependency of nagios, the
output wouldn't tell you if it was the dag or epel package it was trying
to install.

> I'm sort of up in the air on this one. Fedora Extras is, er, was, an
> official project endorsed by RH, had no repotag, and EPEL is just an
> extension of this same project. Since its an official repo, it
requires
> no repotag to identify the package. 

That attitude doesn't seem to be conducive to getting everyone to work
together.  Remember Dag has been providing "EPEL" packages for years
now.   (Thanks Dag!)

And I don't know if the RHEL support department would use the word
"official".  Sounds too much like a synonym of "100% safe and fully
supported" maybe ;-)

> Of course, Fedora and RHEL are a wee
> bit different, and making the distinction that's easy to see at a
glance
> between core RHEL packages and EPEL-for-RHEL certainly does have some
> merit that it doesn't have (or didn't when Extras was separate) in
> Fedora-land. It would likely be of help to RH support if they could
tell
> if a package was from RHEL-proper or from EPEL without having to look
> anything up...

Yup, that's a good reason to add a repotag too.  

Greg

_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--- Begin Message --- 
Greg Swallow wrote:
> Jarod Wilson wrote:
>> Not a good example. The repo the package is in is listed in the output
>> of yum list.
>>
>> # yum list kernel
>> Loading "installonlyn" plugin
>> Installed Packages
>> kernel.ia64           2.6.20-2.2975.bz231219 installed
>> kernel.ia64           2.6.20-1.2966.fc7      installed
>> Available Packages
>> kernel.ia64           2.6.20-1.2987.fc7      development
> 
> Yes, but if dag and epel had the same package name/version/release (and
> no repotag) you might see:
> 
> Available Packages
> nagios.i386 	2.8-1.el4 	dag
> nagios.i386 	2.8-1.el4 	epel
> 
> If a yum upgrade fails while looking for a dependency of nagios, the
> output wouldn't tell you if it was the dag or epel package it was trying
> to install.

True.

>> I'm sort of up in the air on this one. Fedora Extras is, er, was, an
>> official project endorsed by RH, had no repotag, and EPEL is just an
>> extension of this same project. Since its an official repo, it
> requires
>> no repotag to identify the package. 
> 
> That attitude doesn't seem to be conducive to getting everyone to work
> together.

There would be that.

> Remember Dag has been providing "EPEL" packages for years
> now.   (Thanks Dag!)

Yep, I know. Used some of 'em in a previous life on RH7.3 and RHEL3 systems.

> And I don't know if the RHEL support department would use the word
> "official".  Sounds too much like a synonym of "100% safe and fully
> supported" maybe ;-)

Exactly the point I was making below.

>> Of course, Fedora and RHEL are a wee
>> bit different, and making the distinction that's easy to see at a
> glance
>> between core RHEL packages and EPEL-for-RHEL certainly does have some
>> merit that it doesn't have (or didn't when Extras was separate) in
>> Fedora-land. It would likely be of help to RH support if they could
> tell
>> if a package was from RHEL-proper or from EPEL without having to look
>> anything up...
> 
> Yup, that's a good reason to add a repotag too.  

However, I believe support typically asks people to get them the output
from the sysreport tool, which could be easily modified to add %vendor
to the rpm listing it outputs (currently does %n-%v-%r-%arch).

-- 
Jarod Wilson
jwilson@xxxxxxxxxx

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--- Begin Message --- 


You can add me as a supporter even just for the reason of keeping Dag
happy.  If you want everyone to work together (Dag, ATrpms, CentOS,
EPEL) then respecting each others concerns is a good start.  Adding
%{repotag} is really not that big of a deal, is it?

+1

_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--- Begin Message --- 
On Thu, Mar 15, 2007 at 01:16:09PM +0100, Dag Wieers wrote:
> 
> The problem is not a Fedora one. Since Fedora is considered a distribution 
> and the distribution never has a repotag. EPEL is not part of the 
> distribution and therefor does require a repotag to identify where 
> packages come from.

It seems to me that EPEL is meant to be more than 'a community-member
as the other repositories'. I am not saying that it is good or bad, but 
it seems to me that EPEL has the same hegemonic purpose Fedora Extras
once had (and still has). Even though it is distinct from RHEL, it is 
meant to be the only big third party repo. That's my interpretation at 
least.

I am biased toward considering that it is a good idea to have only one
big repo, but I am open to other views. It certainly has pros and cons. 
The main argument in favor of having only one repo is that there is 
less confusion for the users, and less duplication of work. The argument 
against this approach is that the 'design' of the repo may be different, 
and also that it adds competition.

Fedora Extras succeded in some way, since, in my opinion there is a lot
of quality packaging and packagers that have found their way in it,
including Matthias and Axel. The EPEL extension is a proof of that too. 
It didn't completly succeed, however since some packagers are still outside, 
especially you and dries.

Back to the repotag issue, it seems to me to be fair to consider EPEL
to be special and don't need a repotag, based on the fedora extras
success. It would also be fair to treat other repos equally and provide 
a repotag since the fedora extras experience shows that other repos
still coexist. The must, in my opinion, would be a peacefull merge with 
existing repos, packaging quality would certainly improve, and only new 
repos would use repotags, but (sadly in my opinion) history shows that it 
is not that likely to happen.

--
Pat

_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--- Begin Message --- 
Hi,

Maybe the below discussion could help introduce the repotag in EPEL.

Please let me know when the repotag will be decided for EPEL, so I know 
when to unleash hell :)

Kind regards,
--   dag wieers,  dag@xxxxxxxxxx,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]

---------- Forwarded message ----------
From: Dag Wieers <dag@xxxxxxxxxx>
To: Andreas Rogge <a.rogge@xxxxxxxxxxxxx>
Cc: RPMforge <users@xxxxxxxxxxxxxxxxxx>,
    Nicolas Thierry-Mieg <Nicolas.Thierry-Mieg@xxxxxxx>
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@xxxxxxxxxx,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]
_______________________________________________
users mailing list
users@xxxxxxxxxxxxxxxxxx
http://lists.rpmforge.net/mailman/listinfo/users

_______________________________________________
epel-devel-list mailing list
epel-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list

--- End Message ---
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux