[CentOS-devel] Looking for input from EPEL

Jeff Johnson n3npq at mac.com
Wed Sep 1 12:20:17 EDT 2010


On Sep 1, 2010, at 12:04 PM, Les Mikesell wrote:
> 
> It's not so much a flame as an observation that package managers don't 
> and can't work with uncoordinated changes in the same namespace.  And 
> repotags don't do much to help unless the package manager uses them - 
> although they do help in diagnosing problems after they've happened.
> 

Well since "observations" have become folk lore, I am forced to respond
here. If you wish detailed responses move to some other list where I can
subscribe: Note that I am routinely "moderated" on the usual mailing lists.)

Summary comments below:

> package managers don't 
> and can't work with uncoordinated changes in the same namespace.

FALSE.

E.g. smart quite happily handles both *.deb and *.rpm (and 4 other
formats) with zero coordination. Then there's PackageKit which also
doesn't require package coordination.

Please note that I did NOT say RPM in andy of the above. There are some
rather simple things that can be done in the rpmlib "engine room"
to avoid the need for "coordination".

FALSE is the summary point.
> 
>> The obvious means of maximizing portibility and NOT stepping
>> on another archive, is simply building packages that depend
>> ONLY on LSB provided interfaces, and uses a private namespace,
>> assigned by LANANA   that approach exists, has existed, and
>> still work today.  It is merely cumbersome -- so automate it!!
> 
> I'm not convinced there either.  Even if you follow LSB guidelines, 
> uncoordinated packagers are going to step on each others' choices in 
> compile options, config file layout.
> 

Again whether you are convinced (or not) is purely your opinion.

LSB and LANANANANANA were actually designed to address difficulties
in linux distro coordination, not only with API/ABI issues, but also
with package distribution.

The failure of LSB and LANANANANANA to make any progress says more
about "coordianted" pointed ignorance from distro vendors than anything else.

73 de Jeff




More information about the CentOS-devel mailing list