Le mercredi 04 mai 2011 à 16:20 +0200, Raphael Hertzog a écrit : > A full suite can have 2 versions of the same source package and > can contain both libgnomekbd4 and libgnomekbd7. It's not a problem.
OK, so I officially do not care a shit™. > > What the britney-like thing could do is bring automatically all > > dependencies that are actually necessary for the package to be > > installable. But this could also make things more complicated, since > > britney tests source packages, not binaries. You might bring a source in > > rolling only for a runtime that is needed, but the development header > > being uninstallable is not a problem. Britney would prevent that, while > > it would still be a good move. > > Yes, we could try to improve britney towards this. > > But I'm not sure it's a good idea to pick only some binary packages from a > source package. It happens often enough that the package lack a strict > dependency that might be required and picking all the binaries from a > source package limits the risk of upgrading them separately (and thus > experiencing the bug). Indeed. The appropriate result to obtain would be something like: “the list of source packages you need to pull for a given binary package to be installable”. > > I’m not entirely sure, but I think it’s better to pick the update from > > unstable instead of letting in rolling a package that is no longer > > available somewhere else. It should make upgrades smoother, and it > > should also be less work for maintainers, since it avoids having another > > version from which problems can arise. > > In that case, those updates should follow the same rules than for testing > itself. It would be unreasonable to accept the new unstable upload > immediately. I don’t think it would be entirely unreasonable, since we’re already in the case of a specific package we had to pull from unstable, to expect the maintainer to be careful enough. Don’t forget that we’re talking about probably a dozen of packages at a given time. Of course, having a delay before accepting the package seems sensible too, so it’s not like I really care. -- Joss -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304524993.9090.298.camel@pi0307572
