On Mon, Jul 30, 2007 at 02:29:23PM +0000, [EMAIL PROTECTED] wrote: > > 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 ? Yes. > > 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) It's not something that I would consider it a priority to work on, in the case of existing packages; I'm just pointing out why adding "| php4" for new packages isn't necessarily a good answer. 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]
