Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #230463 > unrolled thread

Re: How automatic are backport package updates?

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: How automatic are backport package updates? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-09 07:00 +0100
    Re: How automatic are backport package updates? Thorsten Glaser <t.glaser@tarent.de> - 2021-01-09 15:00 +0100
      Re: How automatic are backport package updates? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-10 10:10 +0100
        Re: How automatic are backport package updates? Greg Wooledge <wooledg@eeg.ccf.org> - 2021-01-11 14:10 +0100
          Re: How automatic are backport package updates? songbird <songbird@anthive.com> - 2021-01-11 16:40 +0100
            Re: How automatic are backport package updates? Michael Grant <mgrant@grant.org> - 2021-01-12 16:30 +0100
              Re: How automatic are backport package updates? Dan Ritter <dsr@randomstring.org> - 2021-01-12 16:40 +0100
                Re: How automatic are backport package updates? Michael Grant <mgrant@grant.org> - 2021-01-12 17:10 +0100
                  Re: How automatic are backport package updates? Dan Ritter <dsr@randomstring.org> - 2021-01-12 17:30 +0100
                  Re: How automatic are backport package updates? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-12 20:30 +0100
                Re: How automatic are backport package updates? Michael Grant <mgrant@grant.org> - 2021-02-12 18:10 +0100
                  Re: How automatic are backport package updates? Tixy <tixy@yxit.co.uk> - 2021-02-12 18:20 +0100
                  Re: How automatic are backport package updates? "Andrew M.A. Cater" <amacater@einval.com> - 2021-02-13 15:40 +0100
                    Re: How automatic are backport package updates? Michael Grant <mgrant@grant.org> - 2021-02-13 16:50 +0100
                      Re: How automatic are backport package updates? songbird <songbird@anthive.com> - 2021-02-13 17:40 +0100
                        Re: How automatic are backport package updates? Michael Grant <mgrant@grant.org> - 2021-02-13 18:00 +0100
                          Re: How automatic are backport package updates? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-02-13 18:10 +0100
                          Re: How automatic are backport package updates? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-02-13 18:30 +0100
                        Re: How automatic are backport package updates? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-02-13 18:30 +0100
                      Re: How automatic are backport package updates? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-02-13 18:00 +0100
                        Re: How automatic are backport package updates? Michael Grant <mgrant@grant.org> - 2021-02-13 18:20 +0100
                      Re: How automatic are backport package updates? Greg Wooledge <wooledg@eeg.ccf.org> - 2021-02-15 14:30 +0100
                        Re: How automatic are backport package updates? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-02-16 10:20 +0100
              Re: How automatic are backport package updates? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-12 21:00 +0100
          Re: How automatic are backport package updates? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-11 20:30 +0100
            Re: How automatic are backport package updates? Michael Stone <mstone@debian.org> - 2021-01-11 21:00 +0100
              Re: How automatic are backport package updates? Brian <ad44@cityscape.co.uk> - 2021-01-11 22:00 +0100
                Re: How automatic are backport package updates? Michael Stone <mstone@debian.org> - 2021-01-12 01:20 +0100
              Re: How automatic are backport package updates? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-12 09:00 +0100

Page 2 of 2 — ← Prev page 1 [2]

#231701

[Multipart message — attachments visible in raw view] — view raw

On Sat, Feb 13, 2021 at 06:58:36PM +0200, Andrei POPESCU wrote:
> On Sb, 13 feb 21, 10:47:41, Michael Grant wrote:
> > 
> > I completely understand the desire for stability and reliability.  But
> > it seems like having to wait up to 2 years for some major new feature
> > to get into Debian can be daunting, especially when it gets into
> > Testing.  I was wondering, is there, or has anyone given any thought
> > to something in between Testing+Backports and Stable+Security that is
> > something like Stable at each dot release, thus reducing this window
> > down to 3 months as opposed to 2 years?
> 
> Yes, it's called Ubuntu ;)

I see I made an error in my paragraph above.  I meant to say something
in between Testing+Security and Stable+Backports+Security (though as
has been said, you can't apply Security patches to Testing.)

Huh, I did not know that this is what Ubuntu was based on.  I always
thought the 6-month releases were based on the dot releases of Debian.

Maybe I should consider moving to Ubuntu Server?  Hmm, that sounds
like a nightmare waiting to happen.

Michael Grant

[toc] | [prev] | [next] | [standalone]

#231725

On Sat, Feb 13, 2021 at 10:47:41AM -0500, Michael Grant wrote:
> One comment though, in the 10+ years of running Debian Testing, I have
> to say that Testing is actually very reliable, way more reliable than
> it's name implies!

This can be true for many users.  It can also be catastrophically false
for a few users.

> I initially moved to Testing because there were some packages that I
> needed which were not in Backports and were regularlly maintained in
> Testing.

To be fully clear: nothing is "maintained in testing".  That's not how
testing works at all.  It's a mis-perception on your part.

There is an automated software system that will copy a package from sid
into testing when certain conditions are met.  Those conditions include:

 1) There isn't a (hard) freeze on testing currently.
 2) The package in unstable has no release-critical bugs.
 3) The package's dependencies are all met in testing.
 4) The package has been in unstable for N days (the value of N varies
    based on the importance of the package and other factors).

In the case of your package, what probably happened is the Debian
developer who maintains that package was actively working on it, so
it received regular uploads to unstable (sid).  Then, because the
package's dependencies were already satisfied in testing, and likely
did not change during the uploads to sid, the package was free to
"trickle down" to testing N days after the upload, consistently.

This will not always be the case.  What happens frequently in testing is
that a gargantuan package suite (like GNOME or other desktop environment)
will be held up by one bug, and will be stuck that way for months or
years, even if there are uploads being made to sid.  No new versions will
trickle down to testing until that one bug is resolved, and then suddenly
the whole thing comes gushing down all at once.

[toc] | [prev] | [next] | [standalone]

#231732

[Multipart message — attachments visible in raw view] — view raw

On Lu, 15 feb 21, 08:20:39, Greg Wooledge wrote:
> On Sat, Feb 13, 2021 at 10:47:41AM -0500, Michael Grant wrote:
> > One comment though, in the 10+ years of running Debian Testing, I have
> > to say that Testing is actually very reliable, way more reliable than
> > it's name implies!
> 
> This can be true for many users.  It can also be catastrophically false
> for a few users.
> 
> > I initially moved to Testing because there were some packages that I
> > needed which were not in Backports and were regularlly maintained in
> > Testing.
> 
> To be fully clear: nothing is "maintained in testing".  That's not how
> testing works at all.  It's a mis-perception on your part.
> 
> There is an automated software system that will copy a package from sid
> into testing when certain conditions are met.  Those conditions include:
> 
>  1) There isn't a (hard) freeze on testing currently.
>  2) The package in unstable has no release-critical bugs.

That is, the package in unstable doesn't introduce *new* RC bugs. It 
will migrate if it still has the same RC bugs as the version in testing.

>  3) The package's dependencies are all met in testing.
>  4) The package has been in unstable for N days (the value of N varies
>     based on the importance of the package and other factors).
> 
> In the case of your package, what probably happened is the Debian
> developer who maintains that package was actively working on it, so
> it received regular uploads to unstable (sid).  Then, because the
> package's dependencies were already satisfied in testing, and likely
> did not change during the uploads to sid, the package was free to
> "trickle down" to testing N days after the upload, consistently.
> 
> This will not always be the case.  What happens frequently in testing is
> that a gargantuan package suite (like GNOME or other desktop environment)
> will be held up by one bug, and will be stuck that way for months or
> years, even if there are uploads being made to sid.  No new versions will
> trickle down to testing until that one bug is resolved, and then suddenly
> the whole thing comes gushing down all at once.

Security fixes will also get stuck if a dependency is not ready to 
migrate.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#230608

[Multipart message — attachments visible in raw view] — view raw

On Ma, 12 ian 21, 10:23:23, Michael Grant wrote:
> Let's say I want to run 'testing' to be more on the edge to get the 
> latest and greatest of packages and to incrementally always be on top 
> of updates rather than having to do large release updates.  But from 
> time to time there is a security update to a package which is newer, 
> or if something specific is broken, I may want to go back to a 
> specific version of something.  What should I put in my sources.list?

Obviously you need unstable in your sources.list to be able to pull 
packages from there, though you must pin unstable to a lower value 
depending on how you intend to handle such packages.

How to do that is left as an exercise for the reader ;)

I would recommend some value between 2 and 99, so that such packages are 
automatically updated once a newer version is available in testing.

You should probably avoid 1 as it is the default value for experimental 
(should you ever need that too) and 100 would cause those packages to 
continue tracking unstable, even when not necessary anymore.

Older versions of packages are available from the local APT cache or 
https://snapshot.debian.org, in most cases it shouldn't be necessary to 
add anything to sources.list.

> I read all the argments here for running stable vs sid and I kind of 
> like being in the middle.  I update my systems every few weeks or more 
> if necessary.  I used to run stable+backports but there were things 
> that just took ages to get into backports, or never made it into 
> backports, but installing them from testing would suck in so many 
> dependencies that I would end up running testing or some weird hybrid.  
> I am considering changing things around though and going back to 
> running stable + backports and occasionally pulling something in from 
> testing but I am not sure yet, the dependency nightmare still looms in 
> my mind.  Honestly I have been running testing for about 10 years now 
> in production and have had very few problems.
> 
> As I read about this, it seems like it's not going to be possible to 
> run testing and pull in security fixes.  Is it correct that security 
> fixes can only be applied to stable releases?

Stable and oldstable (only for one year after the stable release) are 
the only distributions with official security support from Debian.

Security support for testing is definitely possible (it was actually 
done for a while), provided there are enough people willing to do the 
work. At the moment this is done only on a best effort basis, by 
prioritising the package migration from unstable.

However, there is no guarantee updated package are even uploaded to 
unstable in a timely matter, or the package migration could be blocked 
for reasons that you might not be able to circumvent just by forcing the 
update.

Debian stable exists and works the way it is for a reason ;)

> Or are the backports now so well up to date with testing that I 
> shouldn't worry about this and move back to a stable release?

Just to make sure there is no misunderstanding: backports is meant only 
to augment stable with a few, select packages.

Packages in backports are only tested in combination with stable and 
their dependencies from backports. There are no checks on how 
(apparently) unrelated backports might interact between themselves. 
There might be hidden issues, conflicts, etc.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#230579

[Multipart message — attachments visible in raw view] — view raw

On Lu, 11 ian 21, 08:06:50, Greg Wooledge wrote:
> On Sun, Jan 10, 2021 at 11:03:54AM +0200, Andrei POPESCU wrote:
> > In my experience 'apt upgrade' is sufficient for most (1 in 10 or even 
> > more) upgrades, even on unstable.
> 
> I think you made a typo somewhere in there.

None that I can spot, care to elaborate?


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#230580

On Mon, Jan 11, 2021 at 09:26:11PM +0200, Andrei POPESCU wrote:
>On Lu, 11 ian 21, 08:06:50, Greg Wooledge wrote:
>> On Sun, Jan 10, 2021 at 11:03:54AM +0200, Andrei POPESCU wrote:
>> > In my experience 'apt upgrade' is sufficient for most (1 in 10 or even
>> > more) upgrades, even on unstable.
>>
>> I think you made a typo somewhere in there.
>
>None that I can spot, care to elaborate?

1 in 10 is not most...

[toc] | [prev] | [next] | [standalone]

#230581

On Mon 11 Jan 2021 at 14:54:52 -0500, Michael Stone wrote:

> On Mon, Jan 11, 2021 at 09:26:11PM +0200, Andrei POPESCU wrote:
> > On Lu, 11 ian 21, 08:06:50, Greg Wooledge wrote:
> > > On Sun, Jan 10, 2021 at 11:03:54AM +0200, Andrei POPESCU wrote:
> > > > In my experience 'apt upgrade' is sufficient for most (1 in 10 or even
> > > > more) upgrades, even on unstable.
> > > 
> > > I think you made a typo somewhere in there.
> > 
> > None that I can spot, care to elaborate?
> 
> 1 in 10 is not most...

Completely piffling! And not a typo. The sense of the comment is
abundantly clear.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#230583

On Mon, Jan 11, 2021 at 08:56:25PM +0000, Brian wrote:
>On Mon 11 Jan 2021 at 14:54:52 -0500, Michael Stone wrote:
>> On Mon, Jan 11, 2021 at 09:26:11PM +0200, Andrei POPESCU wrote:
>> > > > In my experience 'apt upgrade' is sufficient for most (1 in 10 or even
>> > > > more) upgrades, even on unstable.
>> > >
>> > > I think you made a typo somewhere in there.
>> >
>> > None that I can spot, care to elaborate?
>>
>> 1 in 10 is not most...
>
>Completely piffling! And not a typo. The sense of the comment is
>abundantly clear.

No, it really isn't. In itself the sentence is contradictory. The text 
could be intended to mean that it is sufficient for most or that it 
isn't sufficient for most; the numbers could be intended to mean that 1 
in 10 succeeds or that 1 in 10 fails or maybe there should have been a 
number other than 1. Maybe there's a typo, or maybe it was meant to be 
ironic in a way that's non-obvious enough that a typo is more likely. 
I'm honestly not sure what was intended.

[toc] | [prev] | [next] | [standalone]

#230587

[Multipart message — attachments visible in raw view] — view raw

On Lu, 11 ian 21, 14:54:52, Michael Stone wrote:
> On Mon, Jan 11, 2021 at 09:26:11PM +0200, Andrei POPESCU wrote:
> > On Lu, 11 ian 21, 08:06:50, Greg Wooledge wrote:
> > > On Sun, Jan 10, 2021 at 11:03:54AM +0200, Andrei POPESCU wrote:
> > > > In my experience 'apt upgrade' is sufficient for most (1 in 10 or even
> > > > more) upgrades, even on unstable.
> > > 
> > > I think you made a typo somewhere in there.
> > 
> > None that I can spot, care to elaborate?
> 
> 1 in 10 is not most...
 
Ugh...

(considering I looked at it thrice: once before sending, a second time 
when receiving via the list and a third time at Greg's comment)

Indeed I meant 'apt upgrade' succeeds in most cases.

The cases that need 'full-upgrade' are maybe 1 in 10, possibly less 
(didn't actually count), at least with my set of packages.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web