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

RE: Repotag



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


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