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 at gmail.com