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