When an rpm is built for CentOS-Extras or CentOS-Plus, is it safe to assume that people using these repo's only use them for specific rpms ( eg, someone with a stock CentOS install might use the CentOS-Plus repo for php-5 and only php-5 ) or are most people enabling the entire repo ?
This question comes from the idea of when building a package, should a rpm, hosted in CentOS-Plus link against only [base]+[updates] and only use the minimum possible set of packages from [centosplus] ? So as to have a situation wherein you can use selective packages from CentOS-Plus, while not needing any support stuff from there ( eg. postfix-mysql in CentOS-Plus should link against mysql-4.1 since thats whats in [base] rather than mysql-5 which is in CentOS Plus )
This does create a risk that we might end up creating packages that are themselves incompatible with other packages from the same repository, but work fine when used with the [base] packages for the same functionality.
The other option is to have the entire CentOS-Plus repo enabled for any packages built for the same repo, which might mean that using php-5 from CentOS-Plus needs MySQL-5 and pgsql-8 from CentOS Plus also installed.
Comments ?
- KB
On Tue, 2006-11-14 at 00:05 +0000, Karanbir Singh wrote:
When an rpm is built for CentOS-Extras or CentOS-Plus, is it safe to assume that people using these repo's only use them for specific rpms ( eg, someone with a stock CentOS install might use the CentOS-Plus repo for php-5 and only php-5 ) or are most people enabling the entire repo ?
This question comes from the idea of when building a package, should a rpm, hosted in CentOS-Plus link against only [base]+[updates] and only use the minimum possible set of packages from [centosplus] ? So as to have a situation wherein you can use selective packages from CentOS-Plus, while not needing any support stuff from there ( eg. postfix-mysql in CentOS-Plus should link against mysql-4.1 since thats whats in [base] rather than mysql-5 which is in CentOS Plus )
This does create a risk that we might end up creating packages that are themselves incompatible with other packages from the same repository, but work fine when used with the [base] packages for the same functionality.
The other option is to have the entire CentOS-Plus repo enabled for any packages built for the same repo, which might mean that using php-5 from CentOS-Plus needs MySQL-5 and pgsql-8 from CentOS Plus also installed.
I'd say centos-plus can rely on centos-plus in total and base+updates.
either you have the repo enabled or you don't. Fence sitters can just suffer.
-sv
seth vidal wrote:
I'd say centos-plus can rely on centos-plus in total and base+updates. either you have the repo enabled or you don't. Fence sitters can just suffer.
Then why did you include the "includepkgs" option in yum ;-)
I use php5 with mysql4, as I'm sure lots of people do, so I'd rather see centosplus stay the same so that option is still available in the same place.
And if/when there is a RHWAS repository at CentOS, then I think those should not be in Centosplus, but a different folder, and I think those should rely on each other.
Greg
On Mon, 2006-11-13 at 18:49 -0800, Greg Swallow wrote:
seth vidal wrote:
I'd say centos-plus can rely on centos-plus in total and base+updates. either you have the repo enabled or you don't. Fence sitters can just suffer.
Then why did you include the "includepkgs" option in yum ;-)
mostly to shut users up from whining. :)
-sv
On Mon, 13 Nov 2006 at 9:57pm, seth vidal wrote
On Mon, 2006-11-13 at 18:49 -0800, Greg Swallow wrote:
Then why did you include the "includepkgs" option in yum ;-)
mostly to shut users up from whining. :)
I though your name was Seth, not Sisyphus...
On Tue, 2006-11-14 at 07:40 -0500, Joshua Baker-LePain wrote:
On Mon, 13 Nov 2006 at 9:57pm, seth vidal wrote
On Mon, 2006-11-13 at 18:49 -0800, Greg Swallow wrote:
Then why did you include the "includepkgs" option in yum ;-)
mostly to shut users up from whining. :)
I though your name was Seth, not Sisyphus...
And that is where you'd be wrong. :)
-sv
On Tue, 14 Nov 2006 at 7:54am, seth vidal wrote
On Tue, 2006-11-14 at 07:40 -0500, Joshua Baker-LePain wrote:
I though your name was Seth, not Sisyphus...
And that is where you'd be wrong. :)
And suddenly a great many things became clearer.
On Nov 14, 2006, at 7:54 AM, seth vidal wrote:
On Tue, 2006-11-14 at 07:40 -0500, Joshua Baker-LePain wrote:
On Mon, 13 Nov 2006 at 9:57pm, seth vidal wrote
On Mon, 2006-11-13 at 18:49 -0800, Greg Swallow wrote:
Then why did you include the "includepkgs" option in yum ;-)
mostly to shut users up from whining. :)
I though your name was Seth, not Sisyphus...
And that is where you'd be wrong. :)
I though skv was "script kiddie vidal". My mistake ...
73 de Jeff
--- seth vidal skvidal@linux.duke.edu wrote:
On Tue, 2006-11-14 at 00:05 +0000, Karanbir Singh wrote:
When an rpm is built for CentOS-Extras or
CentOS-Plus, is it safe to
assume that people using these repo's only use
them for specific rpms (
eg, someone with a stock CentOS install might use
the CentOS-Plus repo
for php-5 and only php-5 ) or are most people
enabling the entire repo ?
This question comes from the idea of when building
a package, should a
rpm, hosted in CentOS-Plus link against only
[base]+[updates] and only
use the minimum possible set of packages from
[centosplus] ? So as to
have a situation wherein you can use selective
packages from
CentOS-Plus, while not needing any support stuff
from there ( eg.
postfix-mysql in CentOS-Plus should link against
mysql-4.1 since thats
whats in [base] rather than mysql-5 which is in
CentOS Plus )
This does create a risk that we might end up
creating packages that are
themselves incompatible with other packages from
the same repository,
but work fine when used with the [base] packages
for the same functionality.
The other option is to have the entire CentOS-Plus
repo enabled for any
packages built for the same repo, which might mean
that using php-5 from
CentOS-Plus needs MySQL-5 and pgsql-8 from
CentOS Plus also installed.
I'd say centos-plus can rely on centos-plus in total and base+updates.
you might criticaly needs php5 but not mysql-5 or pgsql-8, so you are willing to use php-5 from centos-plus but not mysql-5 or pgsql-8 .... but it can be in the other way also ....
so I guess is a matter of personal needs.. 'I' try to be as close as rhel as posible, so, if 'I' can, 'I' will try to just use exactly what I need and nothing more, so, the approach that imply that I get everything in centos-plus to be linked to base+updates is prefered for me.
just my 0.02
cu roger
__________________________________________ RedHat Certified Engineer ( RHCE ) Cisco Certified Network Associate ( CCNA )
____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited
On Tue, 2006-11-14 at 00:05 +0000, Karanbir Singh wrote:
When an rpm is built for CentOS-Extras or CentOS-Plus, is it safe to assume that people using these repo's only use them for specific rpms ( eg, someone with a stock CentOS install might use the CentOS-Plus repo for php-5 and only php-5 ) or are most people enabling the entire repo ?
This question comes from the idea of when building a package, should a rpm, hosted in CentOS-Plus link against only [base]+[updates] and only use the minimum possible set of packages from [centosplus] ? So as to have a situation wherein you can use selective packages from CentOS-Plus, while not needing any support stuff from there ( eg. postfix-mysql in CentOS-Plus should link against mysql-4.1 since thats whats in [base] rather than mysql-5 which is in CentOS Plus )
This does create a risk that we might end up creating packages that are themselves incompatible with other packages from the same repository, but work fine when used with the [base] packages for the same functionality.
The other option is to have the entire CentOS-Plus repo enabled for any packages built for the same repo, which might mean that using php-5 from CentOS-Plus needs MySQL-5 and pgsql-8 from CentOS Plus also installed.
Comments ?
Well, it is currently done so that each major grouping of packages goes with "base + updates"
By grouping, I mean that some things (php and php-pear as an example) can require each other as a group ... no need to try and make any of them compatible with another version.
That is how I think we should maintain it, to that maximum extent possible ...
We are also making sure (to the max extent possible) that Items that are in there also work with backward compatibility (ie, the mysql5 will also work with packages are in base and compiled against mysql4).
We have things in CentOSPlus that we don't want people to use UNLESS they need it (the mysql_pgsql postfix is an example) ... so I think that the packages need to be stand alone and work with "base + updates" individually.
Now, I also understand that SOME packages may need to be done so that they are built against the versions in centosplus ... and if that is the case, then we need to specify the minimum install requirements in the program to make that happen and make sure that is spelled out in readme files and/or the wiki.
I personally use parts of CentOSPlus (mysql5,php5) and not other parts (no postfix_mysql_pgsql, no kernel / xfs / reiserfs etc.)
I do not think that it should be required that if you use mysql5 or php5 from centosplus that you also have to use pgsql8 from there ... or if you use the kernel, we should expect that you should also use mysql or php.
I think we need to keep it the way that it currently is and that centosplus items are separate to the max extent practical.
On Tue, Nov 14, 2006 at 12:31:19AM -0600, Johnny Hughes enlightened us:
I think we need to keep it the way that it currently is and that centosplus items are separate to the max extent practical.
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.
Matt
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.
For individual packages this is the best route, and makes things work well for people who just want a more recent package or two. The down side is that this isn't always possible, and results in the repository itself acting in an inconsistent way. Some packages would be drop-in replacements like php or mysql5, while others are not. I guess it comes down to aiming for consistent behavior for packages in a repository, and finding out if the community is okay with a certain amount of disharmony in the repository.
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 ???
Lance
-- uklinux.net - The ISP of choice for the discerning Linux user.
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?
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.
On Friday 17 November 2006 14:32, Johnny Hughes wrote:
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
?
This doesn't really seem to address what I was talking about (or at least it doesn't contradict it, the quoted section could apply to everything I described easily). I'm talking mainly about the default naming convention in centosplus of packages that supercede a package in the core package set. I included an example of an RPM built against another package in centosplus because much of this thread has been about addressing how to accomplish that in manner that is consistent and intuitive.
Kevan Benson wrote:
This doesn't really seem to address what I was talking about (or at
least
it doesn't contradict it, the quoted section could apply to everything I described easily). I'm talking mainly about the default naming
convention
in centosplus of packages that supercede a package in the core package
set.
I included an example of an RPM built against another package in
centosplus
because much of this thread has been about addressing how to
accomplish
that in manner that is consistent and intuitive.
You have to consider upstream, because they aren't going to add "Obsoletes: php5" to their php packages.
My only concern with php-5.1.6 in centosplus is that RHEL5-beta1 is currently using 5.1.4. Sure it's just beta1 and it may change, but if it doesn't that will make for a slightly trickier upgrade for some people at some point in the future. For example the RHWAS php rpm is newer than the RHEL5-beta1 rpm but has a lower version# (5.1.4-1 vs 5.1.4-8). I am sure that is intentional so an upgrade to RHEL5 upgrades php.
Greg
On Friday 17 November 2006 15:09, Greg Swallow wrote:
You have to consider upstream, because they aren't going to add "Obsoletes: php5" to their php packages.
My only concern with php-5.1.6 in centosplus is that RHEL5-beta1 is currently using 5.1.4. Sure it's just beta1 and it may change, but if it doesn't that will make for a slightly trickier upgrade for some people at some point in the future. For example the RHWAS php rpm is newer than the RHEL5-beta1 rpm but has a lower version# (5.1.4-1 vs 5.1.4-8). I am sure that is intentional so an upgrade to RHEL5 upgrades php.
Good point. Unless you want to muck with all the core spec files to change that, it means installing php from the base would result in two package sets. Does anyone know how RHWAS deals with this? I guess it's actually a non-issue for them, as their whole application stack repo is probably meant to be installed together, not in portions (as with centosplus).
Hi Greg,
Greg Swallow wrote:
My only concern with php-5.1.6 in centosplus is that RHEL5-beta1 is currently using 5.1.4. Sure it's just beta1 and it may change, but if it doesn't that will make for a slightly trickier upgrade for some people at some point in the future. For example the RHWAS php rpm is newer than the RHEL5-beta1 rpm but has a lower version# (5.1.4-1 vs 5.1.4-8). I am sure that is intentional so an upgrade to RHEL5 upgrades php.
There is a php-5.1.6 in el5b2...
also, the decision was made within CentOS to move to 5.1.6 over 5.1.4, mainly due to the fact that the 5.1.4 we had access to has known security issues. And I know lots of people have concerns about leaving vulnerable packages out there. We did do some testing internally to ensure the 5.1.6 published on dev. didnt break anything ( within reason ).
once/if rhwas is published, we will definitely look into sync'ing the setup with what we can provide ( might mean an ugly (Epoc)++, but if its required, then so be it ). For the time being, we need to make the best decision, based on what we have available to and what the users of the repo are already using. 5.1.6 seemed to be the best fit.
Hope this clears up the situation a bit.
- KB
Kevan Benson wrote:
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.
yes ? so you mean to say that php-4.3.9 from [base] provides: php and php5-5.1.6 from [centosplus] also provides: php
guess which one is going to get used when a package comes along that Requires: php ?
so based on your example, we can just as well drop php-4 from [base] and all go home :)
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.
how did you work that one out ? { side note: you do realise that packages get pulled in to satisfy depends on/from other packages }
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.
err. no, thats the wrong fix to the problem. The right fix might be to provide a relevant compat-<package>-<version> in the right place to provide the right lib linking bridge. That is we fix a problem, I'm not quite sure if we've defined the problem well enough to actually propose a fix.
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)
so what about pgsql ? should we then have php5 and a php5-mysql4-pgsql8 and php5-mysql5-pgsql7 and a php5-mysql5-pgsql8 ?
and pgsql isnt all, there are other things that php links into :) so do we add a dimension to php's namespace for each of these ?
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.
think about it. no wait, actually create some spec files and play with them to see what you are proposing here.
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 its essentially brain dead ? personally, i'd think thats a good reason to not use this :) The only way something of this nature might even try to work is if there was 1 single repo that everyone used, and all packagers from around the world were using a single specification to write against and Provides/Requires were managed to handle such quirks.
- KB
On Saturday 18 November 2006 18:13, Karanbir Singh wrote:
Kevan Benson wrote:
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.
yes ? so you mean to say that php-4.3.9 from [base] provides: php and php5-5.1.6 from [centosplus] also provides: php
guess which one is going to get used when a package comes along that Requires: php ?
so based on your example, we can just as well drop php-4 from [base] and all go home :)
That's an interesting question, and based on my testing may not be what you suspect.
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.
how did you work that one out ? { side note: you do realise that packages get pulled in to satisfy depends on/from other packages }
Because upgrades seem to work on the basis of a package of the same name. In this case, the names are different, php vs. php5. In case this is ambiguous I'm referring to having php 4 installed, adding centosplus without specifying specific packages to allow, and running "yum update". We'll get into dependency resolution a bit later.
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.
err. no, thats the wrong fix to the problem. The right fix might be to provide a relevant compat-<package>-<version> in the right place to provide the right lib linking bridge. That is we fix a problem, I'm not quite sure if we've defined the problem well enough to actually propose a fix.
Not every program easily allows for a nice separated package to define the back-end it's going to use. The fact that many programs do so is useful to package maintainers, but you can't count on that being the case unless you want to muck with the code.
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)
so what about pgsql ? should we then have php5 and a php5-mysql4-pgsql8 and php5-mysql5-pgsql7 and a php5-mysql5-pgsql8 ?
and pgsql isnt all, there are other things that php links into :) so do we add a dimension to php's namespace for each of these ?
PHP really is a bad example, I just used it because that's what was being talked about. if you look at the PHP package set, you'll notice that php-mysql already exists, and it contains the mysql.so that PHP compiles to interface with libmysql, and resides in /usr/lib/php4 (for the core package) or /usr/lib/php/modules (for the centosplus php5).
In the example I used above, you could mix and match easily, choosing php, php-mysql5, and php-pgsql (for core linked pgsql) just by choosing those packages. That's not too hard. I assumed since this is the devel list, and since this thread was referring to php, that particular package layout would be understood. Not every package links in this manner though, so yes, it could get confusing for packages that don't (although the more distinct libraries a package links to, the more likely it is to compartmentalize them).
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.
think about it. no wait, actually create some spec files and play with them to see what you are proposing here.
I have. It seems to work (besides the tangle that Greg mentioned previously). I can't explain exactly why it does, as your explanation of the system makes sense, other than the yum/rpm combo behaves in a manner that neither of us can entirely explain. Possibly it looks for the first package named in the possibilities, which would be php (and not php5) in this case. My testing seems to indicate something along that line.
Have you tried this, or are you just going by how you think yum/rpm should work?
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 its essentially brain dead ? personally, i'd think thats a good reason to not use this :) The only way something of this nature might even try to work is if there was 1 single repo that everyone used, and all packagers from around the world were using a single specification to write against and Provides/Requires were managed to handle such quirks.
I'm not exactly sure where this part is aimed, but I'd like to assume you're calling the idea brain dead (which is in use by other distros, although not necessarily using rpm and yum together), so I'll assume you meant "Working with the upstream limits what we can do, and this would require upstream changes, which is something we don't want to do." ;)
I didn't say the idea didn't have any problems, I just wanted to know the original reasoning and to open up a dialogue about this. I tend to assume I'm missing something if mutiple smart people have come to a different conclusion than I have, and I was inquiring as to what that was.
In the example I used above, you could mix and match easily, choosing php, php-mysql5, and php-pgsql (for core linked pgsql) just by choosing those packages. That's not too hard. I assumed since this is the devel list, and since this thread was referring to php, that particular package layout would be understood. Not every package links in this manner though, so yes, it could get confusing for packages that don't (although the more distinct libraries a package links to, the more likely it is to compartmentalize them).
To nit-pick your example: This isn't hard on the user side. On the builder side however, this requires amazing amounts of work, including multiple builds per arch based on linking package-sets, and multiple copies of repositories to build against. There is not really a nice way to automate a build of this style and the reward is not worth the effort. Even for php, which does separate out and would be 'simple' it is still a very complex process on the back end.
On Monday 20 November 2006 12:09, Jim Perrin wrote:
In the example I used above, you could mix and match easily, choosing php, php-mysql5, and php-pgsql (for core linked pgsql) just by choosing those packages. That's not too hard. I assumed since this is the devel list, and since this thread was referring to php, that particular package layout would be understood. Not every package links in this manner though, so yes, it could get confusing for packages that don't (although the more distinct libraries a package links to, the more likely it is to compartmentalize them).
To nit-pick your example: This isn't hard on the user side. On the builder side however, this requires amazing amounts of work, including multiple builds per arch based on linking package-sets, and multiple copies of repositories to build against. There is not really a nice way to automate a build of this style and the reward is not worth the effort. Even for php, which does separate out and would be 'simple' it is still a very complex process on the back end.
Yeah, I agreed that it could get confusing. Any way you look at it providing a package that links towards base and another similar package linked against another repo containg newer libs is going to be hard. I included that in the reply for clarification and in the original post because that's what this thread is about, even though the post wasn't so concerned with that particular.
Lance Davis wrote:
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.
Could we overcome some ( all ? ) of this overlap issue with relevant compat-package-version packages ?
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 ???
Extras only link against base, since they dont overlap any of the functionality of the packages in base. Also, Extras are enabled by default, a user can 'yum install foo' from a stock install with no manual intervention or an 'opt in' required. If a package from Extras was to link against something in CentOSPlus, I'd presume that the package needs to be moved into CentOSPlus itself since its unusable in Extras.
- KB
-
Greg Swallow -
Jeff Johnson -
Jim Perrin -
Johnny Hughes -
Joshua Baker-LePain -
Karanbir Singh -
Kevan Benson -
Lance Davis -
Matt Hyclak -
Roger Pe�a Escobio -
seth vidal