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/.