Re: enabling wheezy-backports by default (Re: Backports integrated into the main archive
On 04/04/2013 09:56 AM, Hideki Yamane wrote:
> Hi,
>
> On Wed, 3 Apr 2013 10:21:16 +0200 (CEST)
> Thorsten Glaser <t.glaser@tarent.de> wrote:
>>> I think dselect is effectively unmaintained. It had an open RFH for
>>> years, although that's been closed now so maybe I'm wrong and someone
>>> picked it up?
>>
>> Possibly, but it’s still useful, *especially* for manual
>> interactive cleanup of unused packages that a-g autoremove
>> doesn’t touch.
>>
>> That being said, a deficiency in dselect probably doesn’t
>> warrant tipping the scale against enabling wheezy-backports
>> by default (if the problem exists post-lenny at all, anyway,
>> see above), it’s just another data point to consider, and,
>> possibly document (if the problem indeed still exists).
>
> What I want to do with enabling wheezy-backports by default in installation
> is, it can solve some problems with stable release.
>
> In my point of view, most of dselect lovers would use their Wheezy system
> by upgrading from Squeeze, (or use Jessie or Sid). So, if we turn -backports
> on, it wouldn't affect them. Also, if it would be note in Release Note,
> that's fine and they will disable -backports by hand.
>
> My proposal don't satisfy all users (I know), but it'll bring huge benefit(*)
> to users by default, IMHO. And users can disable it manually if they don't
> want to do so.
>
> *) since we're in web browser ages and users can get lastest browsers
> from -backports as they want.
>
> Even if it's late for 7.0, it is still worth to consider to introduce it in
> point release, IMO.
Hi,
While activating backports by default can be discussed forever, I'm
quite sure that adding an option in our installer so that having
backports activated is just one click away would be a nice option to
have, always. Has this been considered? Who is maintaining that part?
Thomas
Reply to: