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. Regards, Paddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
