On Fri, 2006-11-17 at 12:48 -0800, Kevan Benson wrote: > On Friday 17 November 2006 03:13, Lance Davis wrote: > > On Tue, 14 Nov 2006, Jim Perrin wrote: > > >> I agree with Johnny here. It's very convenient to be able to pull in a > > >> newer version of a single package and have it work on top of an existing > > >> stable system. No need to debug MySQL 5 because I wanted PHP 5. > > > > I can see the need for possibly 2 different repositroies here to provide > > diferent strokes for different folks :- > > > > maybe > > > > centosplus-base linked against base - usable for people who only want to > > include particular packages and want them linked against base + updates. > > > > centosplus - where packages are linked against other packages in > > centosplus - usable by people who want all the latest & greatest. > > > > (or centosplus and centosplus-ng - that is up for discussion ) > > > > Once we have the new builder in place it shouldnt be too much effort to > > provide both. > > > > The same discussion presumably is also merited for what centos-extras are > > linked against ??? > > If the following is a rehash of a topic that's already been talked to death, > please just point me at the spot in the archive... > > I've always been a little confused by the packaging choices in the centosplus > repos. Why name packages such as php and mysql the same as their core > counterparts? Why not append an extra 5 to both to the package names to > designate they are fundamentally different? This seems to be how Mandiva and > Debian do it, and it seems to work. > > For example having php 5 named php5-5.0.4 instead of php-5.0.4 would get > around accidental upgrades after adding the repo, wouldn't it? Similarly > with mysql 5. > > As for which lib to built with, you could standardize on the default being the > core package, and if needed, another built specifically using the centosplus > package but also named differently. In the example this thread was started > with and using the naming convention I just put forward, you would have > packages such as this in the centosplus repo: > > mysql5-5.0.22-1.centos.1.i386.rpm > php5-5.0.4-5.centos4.i386.rpm > php5-mysql-5.0.4-5.centos4.i386.rpm (built against mysql 4 in the core) > php5-mysql5-5.0.4-5.centos4.i386.rpm (obviously built against mysql5 in > centosplus) > > There are no accidental upgrades from adding the whole centosplus repo, it's > immediately clear what's being installed, and using the Provides and > Obsoletes correctly in the spec files should be able to remove any conflicts > offered by having separate sets of packages with competing functionality. > > This seems to be the route other distros have taken, with what seems to be > success. Is there a reason CentOS didn't follow this? Is there some > fundamental drawback I'm missing in this? Because that is not how the upstream provider does it. Almost every thing in the CentOS Plus repo is a rebuild of some upstream package, just an upgrade to something in CentOS proper. We could certainly redesign CentOS if we choose to, however that has never been the goal. php is an upgrade to php ... the kernel is an upgrade to the standard kernel, etc. They are not designed to be installed at the same time as their base counterparts. People should only be looking in CentOSPlus if they know what they are doing. There is much documentation discussing the use of includepkgs= and exclude= in relation to the CentOSPlus repo. There are plenty of warnings. CentOSPlus is there for powerusers who want to upgrade portions of their install ... it was never designed so all of it would be used at the same time. All the other CentOS repositories are designed to be used fully enabled ... but not CentOSPlus. It is a special and dangerous repo ... but it is also very powerful. It does, however, require more planning and a higher knowledge level to use. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20061117/ed475d58/attachment-0007.sig>