[CentOS-devel] RPMS and REPOS and REPO-Linkages

[Kevan Benson]

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.

-- 
- Kevan Benson
- A-1 Networks