[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Activating t-p-u by default (was: Re: For those who care about their packages in Debian)



* David Kalnischkies [2010-08-28 16:23 +0200]:
> 2010/8/26 Carsten Hey <carsten@debian.org>:
> > * David Kalnischkies [2010-08-26 17:43 +0200]:
> >> Long story short:
> >> If you want to get updates from an archive only if you pushed a version
> >> previously from it: 100 => pin > 500.
> >
> > Wouldn't adding a new field to Release files similar to 'Not-Automatic'
> > but pin to 101 instead of 1 if this new field is set to yes an option
> > for apt/Squeeze+1?  This has been reported in #186767.
>
> Well, yes and no.
> Technical more or less no problem, but…
>
> As far as i understand t-p-u i don't understand why the default should
> be < 500.  ...

I also don't think t-p-u should be pinned between 100 and 500 per
default, but nobody disagreed and I would prefer a different approach
that does not involve activating t-p-u per default (as suggested in
another mail in this thread).

> The problem with this is also, which is why i don't think it would be
> suitable for backports, is that these archives mixing minor only-bugfix
> releases and new groundbreaking upstream releases…

Mixing is the only way to handle backports.org without additional people
working on it (a lot of people ...).

> E.g.: I maybe want to get bugfix releases for iceweasel through backports
> automatically, but what i don't want is an automatic 3.6 -> 4.0 upgrade,
> but such pinning i need to define by hand anyway.

You won't get security fixes this way.  A user could decide on case by
case basis if he or she wants to upgrade, but this requires a deep
understanding of security issues and should IMHO not be default.  Users
that are aware of these issues could of course still change the pinning
to the value they consider to be useful for them.

> Regarding the bug: What do you do if two non-debian archives provide such
> a package -- and, do they "fight" against each other now that they can by
> changing their DefaultPriority?

I think the proposed DefaultPriority was a wrong approach, there should
be one below 100 (NotAutomatic), one between 100 and 500 (the one that
we are discussing right now) and the default 500 "normal" archives have.

> The cleaner way for the user would it be to declare: I don't want to
> get this package from this archive ever and i care only for these
> packages from this archive, ignore the rest. You can say that with -1
> and Co, but it is a bit harder than needed…

All I want is sane defaults, users that use their systems in non-default
ways should configure their systems, not most users.

> So, again in short:
> I don't see a reason backports shouldn't be pinned to 1 by default and
> t-p-u by default not pinned at all to get the default 500 pin…

We both aren't the ones to decide this in case of backports.org. I asked
Alexander Wirt what he would think about such a feature.  First response
was that it must be available in stable to be used, then he said that it
would not be uninteresing (in German "sicher faend ich das nicht
uninteressant").


Regards
Carsten


Reply to: