Bug#594461: apt-setup: Should propose using t-p-u when testing is installed
Quoting Joey Hess (jo...@debian.org): Does it really make sense for users to use t-p-u? Anything can be uploaded there, rejected by the release team, and no upgrade path is necessarily provided for a system that installed a package from there and ends up tracking stable. Well, after thinking a little bit more, I wonder if the case of users installing testing *and then* wanting to track stable is really what we want to address here. And I also wonder whether that happens often (that someone installs testing and then sticks to stable once the testing (s)he installed has been released. I more see users who install testing as those users you want to address with your CUT proposal, ie people who will always follow testing. In such case, it then makes some sense to *not* use the release name in sources.list. And, of course, the question of upgrade path to stable is becoming less important. OTOH, not being able to guarantee an upgrade path from t-p-u to (the next) stable is probably not a good idea if we want people to use t-p-u (which was the original point of this discussion). Couldn't that be turned into a requirement? signature.asc Description: Digital signature
Bug#594461: apt-setup: Should propose using t-p-u when testing is installed
Christian PERRIER wrote: Well, after thinking a little bit more, I wonder if the case of users installing testing *and then* wanting to track stable is really what we want to address here. And I also wonder whether that happens often (that someone installs testing and then sticks to stable once the testing (s)he installed has been released. Anecdotally, I can tell you that it's not uncommon for users on debian-user to talk about installing testing around this time in the freeze to get a leg up on the stable release. (Assuming there is a recent installer.) As to actual data, I do remember seeing that effect in the popcon data around previous releases, and it was a significant percentage of eg, total stable systems reporting to popcon, though I don't remember it and lack network to look it up. OTOH, not being able to guarantee an upgrade path from t-p-u to (the next) stable is probably not a good idea if we want people to use t-p-u (which was the original point of this discussion). Couldn't that be turned into a requirement? Such a requirement would make it hard for t-p-u to be used for uploading a new minor upstream release to fix a security hole. If the release happened before that got out of t-p-u, the security hole would later be fixed by backporting. -- see shy jo signature.asc Description: Digital signature
Bug#594461: apt-setup: Should propose using t-p-u when testing is installed
Package: apt-setup Severity: wishlist After a (short) discussion in -devel, I came up with the proposal of activating testing-proposed-updates when users install testing, in a similar way that we currently propose activating volatile when they install stable. So, sending this as a bug report against apt-setup. I suggest this is done post-squeeze. Quoting Paul Wise (p...@debian.org): On Wed, Aug 25, 2010 at 6:38 PM, Christian PERRIER bubu...@debian.org wrote: Quoting Russ Allbery (r...@debian.org): Hmhm, out of curiosity, why is t-p-u “way riskier”. Mostly because there isn't any large pool of systems using t-p-u the way there is for unstable, so the aging process where we get testing in unstable before migrating the package never happens. This means uploads I wonder whether we (in D-I) could add t-p-u to the list of proposed repositories when users install testing. We already propose security and volatile (defaulting to both added): the same mechanism could be made for t-p-u when users install testing. Sounds like a good idea to me. When they reject t-p-u you could either add it commented out or with pinning such that it is not selected by default but when packages from it are selected then they are kept upgraded within it until the packages migrate to testing itself. AFAIK to achieve that you need pinning priorities 500 and 1000. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinbf2ktsg7ppwmv4cnz74wvhdj2vkfq3n9wf...@mail.gmail.com ** CRM114 Whitelisted by: WHITELIST ** -- signature.asc Description: Digital signature
Bug#594461: apt-setup: Should propose using t-p-u when testing is installed
[Christian PERRIER] After a (short) discussion in -devel, I came up with the proposal of activating testing-proposed-updates when users install testing, in a similar way that we currently propose activating volatile when they install stable. One challenge that should be considered, is what should happen when testing become stable, and the meaning of testing-proposed-updates changes. For example now, testing-proposed-updates is packages intended for squeeze, and after the release, it will no longer have packages intended for squeeze. Should those installing testing today keep using testing, or should they get squeeze? If they should get squeeze, the testing-proposed-update source will give them the wrong set of packages after squeeze is released. I believe those installing testing today should get squeeze and continue to use squeeze after the release. At least that is what I expect when I install testing today. I am sure others might believe otherwise, and am not sure which view should have priority. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594461: apt-setup: Should propose using t-p-u when testing is installed
On Thu, Aug 26, 2010 at 10:03:40AM +0200, Petter Reinholdtsen wrote: [Christian PERRIER] After a (short) discussion in -devel, I came up with the proposal of activating testing-proposed-updates when users install testing, in a similar way that we currently propose activating volatile when they install stable. One challenge that should be considered, is what should happen when testing become stable, and the meaning of testing-proposed-updates changes. For example now, testing-proposed-updates is packages intended for squeeze, and after the release, it will no longer have packages intended for squeeze. Should those installing testing today keep using testing, or should they get squeeze? If they should get squeeze, the testing-proposed-update source will give them the wrong set of packages after squeeze is released. There is a 'squeeze-proposed-updates' alias for 'testing-proposed-updates', which will continue to work after release (when it becomes 'stable-proposed-updates' instead). So whatever method is used for configuring sources.list currently (and I think it's always right to use the codename here rather than the suite name, to avoid accidental dist-upgrades down the line) should apply equally well to testing-proposed-updates in that sense. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594461: apt-setup: Should propose using t-p-u when testing is installed
Does it really make sense for users to use t-p-u? Anything can be uploaded there, rejected by the release team, and no upgrade path is necessarily provided for a system that installed a package from there and ends up tracking stable. -- see shy jo signature.asc Description: Digital signature
Bug#594461: apt-setup: Should propose using t-p-u when testing is installed
Hello, On Thu, Aug 26, 2010 at 10:20 AM, Joey Hess jo...@debian.org wrote: Does it really make sense for users to use t-p-u? Anything can be uploaded there, rejected by the release team, and no upgrade path is necessarily provided for a system that installed a package from there and ends up tracking stable. I didn't think about upgrade path but the revision there will be smaller then unstable so a package migrating to testing would be used in place of the older version. The only problem is if the upgrade path between them are incompatible. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
