Les Mikesell wrote:
> Petr "Qaxi" Klíma wrote:
>>
>>>> Diversity adds a lot of value. If EPEL will be only repo nobody on
>>>> RHEL workstation can see/listen MP3, WMA, DVD playing, because of
>>>> interesting US software patent and millenium act law.
>>>
>>> That's not what I meant. Obviously we need additional packages in
>>> other repositories and that will be true as long as there is any
>>> policy that might exclude any contribution to a centrally managed
>>> repository. The question is, why do we need/want different versions
>>> of the same-named packages, or packages that provide different
>>> versions of the same files that can overwrite each other based on
>>> conditions we can't control? There probably is a good reason to want
>>> this - I just can't think of it right now.
>>>
>> That's easy:
>>
>> (this is example, has no reflection to current state ...)
>>
>> EPEL provides xmms-1.2.10-1.i586.rpm - but without MP3, WMA, AAC ...
>> DAG provides xmms-1.2.9-1.rf.i586.rpm - with all those beasts
>> ATRPM provides xmms-1.2.10-1.at.i586.rpm - with all those beasts
>>
>> Which you installs? Who knows, probably EPEL ...
>>
>> Solution?
>>
>> Repo priorities and includes
>
> But wouldn't it be easier if the packages had different names so you
> could just install the one(s) you want from the command line?
>
NO ... because many other packages might depend on xmms (to use your
example). xmms-devel might be needed to build against. All the other
packages that need it (some in ATRPMS, some in RPMForge, some in Base,
soem in KBS, some in EPEL) all think it provides xmms-devel or xmms.
One could provide:xmms with the package ... however then it would ACT
like it was named xmms too (which would make them the same).
If we change the %{name} then all of those are broken ... of we change
the %{release} (ie ... add a repo tag) then all the other programs are
not broken.
Also a reason for providing packages named the same thing is to provide
"repo closure". That concept is to provide all packages (besides those
in the main OS) that all packages in your repo need to install.
Sticking with our example, xmms might require perl-Magic to install and
perl-Magic is missing from BASE. You need perl-Magic to get xmms to
install ... and it is in other repos (Maybe EPEL) but you don't want to
force your users to also use EPEL, so you need to have perl-Magic also
in your repo.
===============
It is also well beyond the scope of any distribution or repo to try and
create "one-off" packages. What I consider "one-off" are things in
different paths (like /opt) that allow 2 packages to be installed at the
same time.
This kind of situation rapid develops into the stuff that very
experienced admins need to create for their specific installation. I
would be for the same problems as above ... other packages require /
expect xmms-1.2.3.so.1.1.2 and they expect it in /usr/lib (or
/usr/lib64) ... my renamed and relocated package can't be there. (Since
you also have xmms from EPEL installed). You would need to rebuild any
other packages to look at my new name/location if you wanted it to use
my "one-off" package instead of the default location). That is fine if
you need it for a specific reason ... it is not fine for normal installs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20070802/a6e867c5/attachment-0005.sig>