Re: Doubts about PHP
On Thu, Jul 26, 2007 at 11:24:34AM -0700, Steve Langasek wrote:
> > what about backports?
> > if a package actually works with an older version of supporting
> > software, why not use that usefull information in the dependencies
> > instead of throwing it away ?
> > Saying that package x depends on package y >= 5 when in fact x depends
> > on y >= 4, just because that version of package x is being packaged for
> > unstable and there is no y < 5 in unstable really seems like a lost
> > opportunity to me :-(
> That is not the reason at all.
> First of all, this is not an instance of saying php (>= 4) instead of php
> (>= 5); this is saying php5 | php4 | php4-cgi vs. php5. If it were simply
> the case of getting the versioning right on a single versioned dependency, I
> would agree with you, but alternative dependencies do come with some cost.
> First, they add complexity to dependency resolution, which when compounded
> can cause problems for aptitude and britney.
so this applies to all packages.
in particular, like a lot of package management decisions, it could impact
the ability to scale down ?
> Second, particularly in the
> case of php applications, maintainers almost never correctly express the
> package's real dependencies. For instance, if a package requires "php with
> mysql support", this often gets expressed as "php5 | php4, php5-mysql |
> php4-mysql", but that relationship is satisfied by combinations of packages
> that may not be usable together for the target application -- e.g., it's
> satisfied by php5 + php4-mysql, but php4-mysql's own dependencies are
> satisfiable by phpapi-$foo which is provided by php4-cli, so you can install
> these packages together and satisfy your web app's dependencies without
> having a usable pairing.
would it be practical to get a lint to pick up this kind of thing ?
(might be a good idea anyway)
still, if it is a commonly made mistake, then I see the attraction of
trying to design out the task altogether.
> So in the case of php-related packages, yes, I do think that new packages
> should not bother with the alternative dependencies on php4*.
I find this much easier to understand now.
Thanks for taking the time to help me understand.