On Thu, 2007-08-02 at 07:47 -0500, Les Mikesell wrote:
> Axel Thimm wrote:
> > On Wed, Aug 01, 2007 at 11:29:25AM -0500, Les Mikesell wrote:
> >> 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.
> >
> > Let's assume no one wants that (I think I don't). Shouldn't you be
> > chasing the repo that just created the duplicates instead of the ones
> > that supported RHEL/CentOS over years now?
> >
> > And before you rightfully extend the argument - as far as duplicates
> > between RPMForge/Dag, Dries, Karan Extras, CentOS Extras SL contrib
> > and ATrpms are concerned: We're working *together* on eliminating
> > them.
>
> And yet, conflicts have always kept popping up, and I can't see any
> provision you make to enable additional repositories to exist without
> coordinating with your rules. The issue is that there is only one
> namespace which is the part that doesn't make sense and can't work
> without a single authority or a hierarchial structure, and I can't come
> up with a reason that you should be that authority.
>
> > We're too old for clone wars, the only kid on the block that
> > wants to play by its own rules is on another list, go patronize it ;)
>
> The LFHS is the problem here, although putting applications where you
> want them in the filesystem would make Linux as hard to use as the Mac.
> Oh wait...
That compromises one of GNU/Linux's biggest strengths, that of shared
libraries. So instead of just upgrading OpenSSL, I now have to upgrade
the following that is on one of my servers:
$ rpm -q --whatrequires libcrypto.so.4
cyrus-sasl-2.1.19-5.EL4
cyrus-sasl-md5-2.1.19-5.EL4
lftp-3.0.6-3
pyOpenSSL-0.6-1.p23
stunnel-4.05-3
wget-1.10.2-0.40E
xmlsec1-openssl-1.2.6-3
libwvstreams-3.75.0-2
ipsec-tools-0.3.3-6.rhel4.1
bind-libs-9.2.4-24.EL4
bind-utils-9.2.4-24.EL4
bacula-client-2.0.3-1
openssl-0.9.7a-43.16
python-2.3.4-14.4
openldap-2.2.13-7.4E
net-snmp-libs-5.1.2-11.EL4.10
postgresql-libs-7.4.17-1.RHEL4.1
net-snmp-5.1.2-11.EL4.10
cups-libs-1.1.22-0.rc1.9.20
curl-7.12.1-11.el4
net-snmp-utils-5.1.2-11.EL4.10
postgresql-server-7.4.17-1.RHEL4.1
OpenIPMI-1.4.14-1.4E.17
ntp-4.2.0.a.20040617-6.el4
openssh-server-3.9p1-8.RHEL4.20
openssh-clients-3.9p1-8.RHEL4.20
pam_ccreds-3-3.rhel4.2
openssh-3.9p1-8.RHEL4.20
postfix-2.2.10-1.1.el4
postgresql-7.4.17-1.RHEL4.1
dhcpv6_client-0.10-17_EL4
cups-1.1.22-0.rc1.9.20
$ rpm -q --whatrequires libssl.so.4
lftp-3.0.6-3
pyOpenSSL-0.6-1.p23
stunnel-4.05-3
wget-1.10.2-0.40E
xmlsec1-openssl-1.2.6-3
libwvstreams-3.75.0-2
ipsec-tools-0.3.3-6.rhel4.1
bacula-client-2.0.3-1
openssl-0.9.7a-43.16
python-2.3.4-14.4
openldap-2.2.13-7.4E
postgresql-libs-7.4.17-1.RHEL4.1
cups-libs-1.1.22-0.rc1.9.20
curl-7.12.1-11.el4
postgresql-server-7.4.17-1.RHEL4.1
postfix-2.2.10-1.1.el4
postgresql-7.4.17-1.RHEL4.1
cups-1.1.22-0.rc1.9.20
That's just awesome. The logistics of that is just staggering, imagine
that just one maintainer failed to update code/recompile against fixed
OpenSSL. However, I imagine that there could be a hybrid approach, but
this is definitely /not/ the forum to be radically changing the way
GNU/Linux behaves as a whole. A good start might be on the kernel devel
list. HPFS also uses embedded meta info, that would probably be needed
also. Essentially, you are talking *radical* changes when you start
thinking along the lines of "Mac does this; Windows does that; Foo OS
does some other thing...", some of which might be integrated /over
time/.
--
Timothy Selivanow <timothys@xxxxxxxxxxxxxx>
Linux System Administrator
EasyStreet Online Services, Inc. http://www.easystreet.com
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
