Dag Wieers wrote:
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.
RPM allows it, but for anything else the depsolver needs to be modified to
allow it. And even if you allow it, there is no policy of what needs to be
updated and how. For the kernel there is a lot of specialized logic to
make it work.
While I agree with you that it is possible (in RPM) and can be useful, I
do not agree that it is a solution to the repository mixing problem.
It is the solution for cases where there are known differences in
packages and only the end user/admin can make the right choice about
which or how many of them he wants. That obviously can't be automated,
although I've always wanted to see a way to track exactly the
package/versions that one system has installed and reproduce it on any
number of other systems. In that scenario, an expert sysadmin could
hand-tune a system for a certain set of functions, publish his
configuration, and any number of other people could have equally well
tuned systems that duplicated the setup and tracked the same updates.
The end user would then have to choose nothing but his virtual
representative sysadmin.
You'll have to remind me why anyone wants different same-named packages
with differences the end user doesn't understand and can't control to
exist at all before I can comment on a solution about managing them.
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.
Correct, you would think Fedora took care of this, right ? But there is
no interest for Fedora to take care of that because they want to be the
only repository. It is not something they have an incentive for to fix.
That is exactly the problem. The repotag would be a workaround (and a
convenient one for users) but the real changes need to be in yum or
somewhere else. And Fedora does not care, so RHEL will not have it.
I have warned for this on the Feodra mailinglist years ago. There just is
no interest to have the diversity of more than one repository.
What value does diversity add when the end user can't select which one
he wants or load all of them? I understand the scenario where a single
repository has a policy that prohibits certain packages from being
included, but the only conflicts in those cases should be where an
incomplete version is packaged in one place under the same name as the
full version in a place with a different policy. The more common case
would just be additional packages or packages with different names.
From an end-user viewpoint, I can't see why anyone would want to
maintain a potentially-conflicting package of something that can be
freely distributed and keep it in an isolated repository, especially
without any mechanism to control which will be installed. Can you
explain the reason anyone would want to have diversity instead of a
single maintainer per package and the same packages in all repositories
whose policies find them acceptable?
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
