On Mon, Jul 23, 2007 at 03:07:23PM +0000, [EMAIL PROTECTED] wrote: > On Sun, Jul 22, 2007 at 02:47:41PM -0700, Steve Langasek wrote: > > On Sun, Jul 22, 2007 at 07:12:47PM +0200, Gregory Colpart wrote: > > > On Thu, Jul 19, 2007 at 06:06:14PM -0500, Raphael Geissert wrote:
> > > > That's exactly the reason why I recommend to Depend on php5. > > > > $ apt-cache show php5 | grep Depends > > > > Depends: libapache2-mod-php5 (>= 5.2.3-1) | php5-cgi (>= 5.2.3-1), > > > > php5-common (>= 5.2.3-1) > > > > That's more than enough. > > > * For web server, I recommend: > > > Depends: apache2 | httpd > > > * For PHP depends, if your application is compatible with PHP4, you > > > should let php4 and php4-cgi (because php4-cgi is not in depends > > > of virtual package php4 in sarge): > > Which makes it not particularly relevant to newly-packaged software. In > > fact, you can pretty much drop the 'php4' alternative altogether now, since > > php5 was in etch and php4 won't be in lenny. > while I wouldn't want to encourage anyone to use php4 ... ;-) > 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. 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. So in the case of php-related packages, yes, I do think that new packages should not bother with the alternative dependencies on php4*. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
