Re: Should fast-evolving packages be backports-only?
On Tue, Nov 11, 2014 at 9:20 AM, Daniel Pocock <daniel@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 <daniel@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."
Reply to: