Feizhou wrote:
> Les Mikesell wrote:
>> Dag Wieers wrote:
>>
>>> You may argue that that is a good thing. But Fedora is a different
>>> beast than RHEL. People may want stable packages, or current packages
>>> and a single repository (with the tools we have today) cannot provide
>>> this.
>>
>> But people may want _both_ the stable package and the current package
>> on the same machine at the same time. Having a hint of the difference
>> barely visible in the package name doesn't help a bit.
>
> I cannot see how it is possible to install both the stable package and
> current package.
How many kernel packages do you have installed? All it takes is to not
write the same-named file in the same place as the other package. In
some cases there are practical problems where a service needs to listen
on a default port and you can't run 2 at once, or the init script is
expected to live in a certain place so we'd need a creative solution,
but most files could just have their own unique path and you'd pick the
one you want with your PATH setting - something well understood decades
ago.
>>> Besides, it punishes people who did not have an alternative back when
>>> Fedora Extras refused to do RHEL packages and only had RPMforge to
>>> fall back on.
>>>
>>> At least that's my point of view.
>>
>> I think you are making too much out of name differences for things
>> that can clobber each other and not enough about ways to let the
>> different things co-exist - on the same machines if you want them, or
>> to let users choose which they want. If two same-named packages can
>> conflict, someone did something wrong and the issue shouldn't be about
>> who did it but how to avoid it.
>>
>>
>
> I disagree. If I was going to roll my own packages in my own repository
> to overrule the OS repositories, tagging my packages would be essential.
But the tags are in an inconvenient position to control anything. How
do you ensure that you'll get your copies if any other repo adds a newer
release? Normally you'd want updates to float to the latest.
--
Les Mikesell
lesmikesell at gmail.com