[Yum-devel] post 3.2.0 things to think about

Tim Lauridsen tla at rasmil.dk
Fri May 4 07:07:46 UTC 2007


seth vidal wrote:
> On Fri, 2007-05-04 at 08:33 +0200, Tim Lauridsen wrote:
>   
>> Panu Matilainen wrote:
>>     
>>> On Thu, 3 May 2007, Michael E Brown wrote:
>>>
>>>       
>>>> On Thu, May 03, 2007 at 05:11:46PM -0400, seth vidal wrote:
>>>>         
>>>>> On Thu, 2007-05-03 at 09:18 +0200, Tim Lauridsen wrote:
>>>>>
>>>>>           
>>>>>>  * yum list vendors
>>>>>>     List install packages and the rpm vendors, there have been a 
>>>>>> lot of
>>>>>> discussions on the EPEL list, about repotag as a way to locate the
>>>>>>     source of the packages, because the basic packages tools like yum
>>>>>> don't show it in a simple way.
>>>>>>             
>>>>> Can't repoquery do this?
>>>>>           
>>> Sure it can but...
>>>
>>>       
>>>> I think the point there is that we want to list the vendor at all times
>>>> whenever we display the package name.
>>>>
>>>> The example given was something like this:
>>>>
>>>> core os package: foo-1.0-1.fc6.i386.rpm   files: /bin/file1, /bin/file2
>>>> evil repo package: foo-1.1-1.fc6.i386.rpm files: /bin/file1, /bin/file2,
>>>>                                                 /bin/file3
>>>> good repo package: bar-1.0-1.fc6.i386.rpm files: /bin/file3, /bin/file4
>>>>
>>>>
>>>> user does:
>>>> 1) install system
>>>> 2) configure evil repo
>>>> 3) yum upgrade (upgrades foo)
>>>> 4) configure good repo
>>>> 5) yum install bar
>>>>    WTF?! Why does the #!@#$@ "bar" package in "good" repo conflict with
>>>>    my BASE OS package "foo"??? Dont they even test this stuff?
>>>>
>>>> The user then proceeds to berate admin of good repo, even though it was
>>>> actually evil repo's fault.
>>>>
>>>> If, when you gave the conflict message ("/bin/file3 from package foo
>>>> conflicts with /bin/file3 from package bar"), you also mentioned the
>>>> vendor, that might allevate some problems. ("/bin/file3 from package
>>>> foo, vendor 'evil repo' conflicts with file /bin/file3 from package bar,
>>>> vendor 'goot repo'")
>>>>         
>>> Been reading the EPEL repotag flamewars I see :)
>>>
>>> And yes, I agree, dragging the vendor string out of the dark cave it's 
>>> been hiding in all these years would seem to be a good thing. It's 
>>> just that screen estate is already a scarce resource, there's no room 
>>> on 80char terminal to put the potentially lengthy vendor string into, 
>>> unless per-package info is split on two lines.
>>>       
>> This is why i think something like yum list vendors could be nice, i 
>> could show something like this
>>
>> foo-1.0-1.fc7.i386                                 Vendor X
>> bar-1.0-2.fc7.noarch                             Vendor Y
>>     
>
> is there a sensible situation when a single repo will have more than one
> vendor contributing the same package name/arch? 
>
> or are you meaning only for installed pkgs?
>   
Only for installed packages, i want a easy way to show the source of the 
packages, the same info that a repotag will give you,
but there is no repo info in the rpmdb, the best available info is the 
vendor field.
If yum contained some kind of transaction database, it could be a place 
to store the source of each package.
> If it is for installed pkgs we'd almost be better off recording the repo
> a package was installed FROM elsewhere.
>
> -sv
>
>
> _______________________________________________
> Yum-devel mailing list
> Yum-devel at linux.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.baseurl.org/pipermail/yum-devel/attachments/20070504/fcaa7fbd/attachment.htm 


More information about the Yum-devel mailing list