On Tue, Nov 11, 2014 at 9:20 AM, Daniel Pocock <dan...@pocock.pro> wrote: > On 11/11/14 14:30, Rebecca N. Palmer wrote: >> It has been recently stated [0-1] that backports is enabled by default >> in Jessie. >> >> 1. Does that mean that if pkgX is in jessie-backports but not jessie, >> "apt-get install pkgX" will install it from -backports? >> >> 2. If so, when (if ever) is it appropriate to deliberately invoke that >> behaviour by removing pkgX from jessie? > One big question that arises then (and what I asked in a separate thread > about the browser-related packages but it is relevant to other classes > of package too) is compatibility > - if package foo is allowed to change, do all packages broken by the > change (e.g. browser plugins) get to be uploaded again too? > - if some package hides the complexity of the change and the maintainer > has kept the API stable so that dependent packages don't break should it > be looked on more favorably and allowed to be updated in stable too?
maybe a crazy idea, but maybe build in some easy way to apt-pin package (and dependencies) to testing in apt/dpkg? This way we can leverage all of the existing transition infrastructure and essentially provide backports for all packages with no extra work? possibly lots of unintended consequences, and someone will mess up their machine by pulling in tons of libraries from the future, but it will essentially perform the same function for those users that need the up-to-date leaf packages while keeping the stable core. testing is pinned by default to <100 "$ apt-get install-updated ${PACKAGE}" where install-updated will pin ${PACKAGE} to testing and do "$ apt-get install ${PACKAGE} -t testing" This will pull in the package from testing and dependencies from testing that are missing from stable. Not a good idea for jessie, maybe something to think about for future. Either way, I think you have excellent points in your final paragraph, thank you Rebecca and Daniel for bringing this up. On Tue, Nov 11, 2014 at 9:20 AM, Daniel Pocock <dan...@pocock.pro> wrote: "I also feel that this is something that impacts each maintainer and each user differently. Some people are working in parts of the system where the freeze concept really is the most important thing. Other people are working on applications where network compatibility is the most important thing (as it is with communications) and people simply won't use the package or won't be able to use it successfully if is not updated. Ultimately, with more and more packages being in this category as the world becomes more networked/cloudified, this impacts Debian's relevance for whole groups of users." -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cang8-dbkbdzghr-vvkc7x9g0f6c1quaz9j3kgvbsdsusent...@mail.gmail.com