Axel Thimm wrote:
Maybe the original draft will be picked up by other projects to
signal their mode of collaboration, let's see. It certainly was in
thge spirit of the existing 3rd party repos.
Maybe you should cut them a little slack considering that they are not
so experienced as the rest of you...
Experienced in what? Hidden agendas and politics? I'm not experienced
in that really. Please check the epel list where these topics were
discussed over *months* and often revealed their political background
instead of a "lack of experience".
I meant experience with running a repo, but experience in trying to
coordinate disparate policies is probably more relevant. It just isn't
going to happen and everyone might as well recognize that up front.
Next, what use would it be to give a different name? E.g. xemacs vs
xemacs-myrepo?
It would be very useful to me in any case where the versions differ. I
like to know what I'm running and why.
> The two packages would conflict so xemacs-myrepo has to
either Conflict: or Obsolete:/Provide: with the standard name, and the
end result is a worse setup than having the proper name since there
will be no way back to the unadorned name unless the xemacs package
starts obsoleting/providing the alternate name as well.
If the package name makes the difference visible, can't I "yum remove
xemacs-myrepo" and "yum install xemacs-otherrepo" depending on which I
want to have installed?
So there is no real improvement in obfuscating names.
But there is an improvement if I can see and control what I install and
understand the differences. The names are obfucated now since the
same name can refer to any of several different things.
And I didn't
even mention dependent packages that would break with
perl-Bar-myrepo and libfoo-devel-myrepo instead of perl-Bar and
libfoo-devel.
That's only a problem if you overwrite each other's files. Put them
somewhere else. Yes, having files of the same name in different path
locations can confuse people who don't understand that path order
searches have been used since the invention of the tree structured
directory to permit multiple versions of the same things to co-exist,
but the concept isn't that difficult. It's just too bad the package
managers didn't get it and had to go through contortions after realizing
that there are things that people need to have multiple versions
installed at the same time, like the kernel and architecture-dependent
libraries.
ATM we'll just live and let live, and there will not be any one-side
effort to rectify any compatibility issues EPEL created. It's their
mess, they'll have to clean it up.
Live and let die, you mean - at least as far as the users are concerned.
I don't think this issue has any solution other than separate
namespaces.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
