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 1 of 2  [1] 2  Next page →

#230463 — Re: How automatic are backport package updates?

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

[this is more suitable for debian-user, adding Cc: accordingly]

On Vi, 08 ian 21, 23:21:32, Gregg Nemas wrote:
> Micha,
> 
> Thanks for your efforts.
> 
> I am considering switching to Debian Stable from Fedora (which no
> longer supports 32-bit systems) and was wondering whether Debian
> Stable + Backports might be a reasonable approximation.

Availability in backports of any given package from testing is subject 
to Someone (not necessarily the "regular" Maintainer) doing the work. 
There is no guarantee.

In practice several important packages are updated quite regularly: 
linux, systemd, etc.

You might want to check the history of specific packages you are 
interested in at https://tracker.debian.org.

> The only other
> 32-bit choices seem to be the rolling distributions Tumbleweed and
> Archlinux32 (which does not seem to be getting updated much), or
> switching to Debian Unstable.

Debian unstable can be quite usable, provided that you are willing to 

  1. Invest the time to familiarise yourself with APT and friends (dpkg, 
  aptitude, apt-listbugs, etc.), the Debian Bug Tracking System (BTS), 
  etc.

  2. Can deal with unexpected issues, ranging from some package randomly 
  crashing to an unbootable system (rare, but does happen).

After all, unstable users are something like beta testers for the 
distribution ;)

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

[toc] | [next] | [standalone]

#230478

On Sat, 9 Jan 2021, Andrei POPESCU wrote:

> In practice several important packages are updated quite regularly: 
[…]

Note that packages being updated is not always a good thing.
Having the stability of a tested set to rely on is also
appreciated. It’s also more important to have the security
and important bug fixes in stable (even if backporting is
easier) and for users to look at the Debian revisions and
the security tracker (not just the upstream versions).

I’m also telling application developers to please not just
pip/npm/… install something because they do NOT necessarily
need “that” newer version RIGHT NOW, they can use the older
one that’s available for stable users as well.

> > switching to Debian Unstable.

That, or testing. Debian testing is delayed and often gets
security updates the latest (though, if time for security
updates is your metric, an LTS or ELTS distro, that is,
jessie or stretch currently, is your best bet unfortunately)
but you will suffer from less package uninstallability problems.

In practice (see below) unstable suffices.

> Debian unstable can be quite usable, provided that you are willing to 
> 
>   1. Invest the time to familiarise yourself with APT and friends (dpkg, 
>   aptitude, apt-listbugs, etc.), the Debian Bug Tracking System (BTS), 

Right, but the #1 maxime for “sudo apt-get --purge dist-upgrade” in
unstable is to never just press Enter (also to *not* run unattended-
updates). Other than that, and the “let’s better skip updating right
now”, unstable has been *extremely* usable as a to-go daily distro
for years.

>   2. Can deal with unexpected issues, ranging from some package randomly 
>   crashing to an unbootable system (rare, but does happen).

Right, rare but happens.

> After all, unstable users are something like beta testers for the 
> distribution ;)

Yes and no… it depends on the package maintainers (DDs, DMs, etc.)
but having run primarily unstable (stable only on “important” VMs
or servers) for years now, I’ve found that less and less true.

Nowadays it’s more like, unstable is the equivalent of those rolling
distros (Arch/Void/CentOS Stream/…) and stable is the equivalent of
something like RHEL (except it offers about 30 times the amount of
software to install). So, for people who are really GNU/Linux users,
not GUI/DE users, I tend to recommend unstable first.

(I also have chroots with various other releases to fulfill specific
needs… had one for KDE 3 for a long time, and I have one with stable
now for a software that needs Python 2, and to test backports, and
nōn-Debian distros, to test or run stuff there, if not on a VM.)

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*************************************************

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*************************************************

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

#230521

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

[removing -backports from Cc:]

On Sb, 09 ian 21, 14:48:43, Thorsten Glaser wrote:
> On Sat, 9 Jan 2021, Andrei POPESCU wrote:
> 
> > Debian unstable can be quite usable, provided that you are willing to 
> > 
> >   1. Invest the time to familiarise yourself with APT and friends (dpkg, 
> >   aptitude, apt-listbugs, etc.), the Debian Bug Tracking System (BTS), 
> 
> Right, but the #1 maxime for “sudo apt-get --purge dist-upgrade” in
> unstable is to never just press Enter (also to *not* run unattended-
> updates). Other than that, and the “let’s better skip updating right
> now”, unstable has been *extremely* usable as a to-go daily distro
> for years.

In my experience 'apt upgrade' is sufficient for most (1 in 10 or even 
more) upgrades, even on unstable.

Only when APT mentions packages being kept on hold it is necessary to 
*try* 'apt full-upgrade' or 'apt-get dist-upgrade'.

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

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

#230565

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.

> Only when APT mentions packages being kept on hold it is necessary to 
> *try* 'apt full-upgrade' or 'apt-get dist-upgrade'.

Do note that "apt upgrade" includes the option to install new packages
if necessary, whereas "apt-get upgrade" does not.  This is an important
difference between the two.

You can get that behavior from apt-get by adding the --with-new-pkgs
option, but it's hard to remember and hard to type.  I suspect most
apt-get users just bump it up to "apt-get dist-upgrade" whenever there's
a new kernel ABI or whatever.

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

#230571

Greg Wooledge wrote:
...
> You can get that behavior from apt-get by adding the --with-new-pkgs
> option, but it's hard to remember and hard to type.  I suspect most
> apt-get users just bump it up to "apt-get dist-upgrade" whenever there's
> a new kernel ABI or whatever.

  correct.  since i preload my shell commands when i login for
me the difference is between !2 and !3, !4 does the purge of
autoinstalled packages and !1 does the apt-get update.

  these commands go in my .bashrc for root.

=====
history -c
history -s "apt-get update& fetchnews&"
history -s "apt-get upgrade"
history -s "apt-get dist-upgrade"
history -s "apt-get autoremove --purge"
=====

  after i've seen a new kernel come through i clean up the oldest
one so i don't have that hanging around wasting space.

  i don't run unstable though for much these days other than noting
when a new firefox release comes along.


  songbird

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

#230602

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

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?

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?

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?

Michael Grant

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

#230603

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?

Are you running a production system?

That is, are you running a Debian system which is essential to
your business or personal activities, so that having to recover
from a disaster would be a significant hardship?

If so, you should be running buster, and considering moving to
the next stable release no sooner than a few weeks after the
transition to bullseye. You should accept security updates as
soon as is convenient for you, on an ongoing basis. Backports
are to solve specific issues.

If you are running a system for fun, or if there is no real
issue with protracted unavailability, testing is a fine thing
to be running. You should expect a little chaos every time you
update.

Only stable gets security updates. Testing may get security
updates when they come from upstream, but it's not guaranteed.

-dsr-

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

#230604

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

On Tue, Jan 12, 2021 at 10:35:05AM -0500, Dan Ritter wrote:
> Are you running a production system?

Yes, I guess you could call it production.  It's my family & friends server.  In all the time I have been running Debian Testing, I have never once suffered a serious or protracted disaster as you envision.  Maybe I'm lucky!  Little things, yes, like the systemd thing the other day.  On very rare occasions, I have had to pin a package.

> If so, you should be running buster, and considering moving to
> the next stable release no sooner than a few weeks after the
> transition to bullseye. You should accept security updates as
> soon as is convenient for you, on an ongoing basis. Backports
> are to solve specific issues.

Hence using buster as an example of today (understand should substitute bullseye after that release):

deb http://httpredir.debian.org/debian buster main non-free contrib
deb-src http://httpredir.debian.org/debian buster main non-free contrib

deb http://security.debian.org/debian-security buster/updates main contrib non-free
deb-src http://security.debian.org/debian-security buster/updates main contrib non-free

deb http://deb.debian.org/debian buster-backports main contrib non-free
deb-src http://deb.debian.org/debian buster-backports main contrib non-free

Is it then possible to add the /testing line to be able to occasionally pull in specific packages from testing?  I think I would need a preferences.d/something.pref file.

deb     http://mirrors.linode.com/debian/   testing main contrib non-free
deb-src http://mirrors.linode.com/debian/   testing main contrib non-free

Clearly if the package I wanted to install from testing would suck in a lot of dependencies, then I likely would not do that, but I don't want it to suck things in from testing automatically otherwise, I am then running testing.

Is this setup possible or am I really just going to have to be patient if something isn't in backports?

Michael Grant

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

#230605

Michael Grant wrote: 
> On Tue, Jan 12, 2021 at 10:35:05AM -0500, Dan Ritter wrote:
> > Are you running a production system?
> 
> Yes, I guess you could call it production.  It's my family & friends server.  In all the time I have been running Debian Testing, I have never once suffered a serious or protracted disaster as you envision.  Maybe I'm lucky!  Little things, yes, like the systemd thing the other day.  On very rare occasions, I have had to pin a package.
> 
> > If so, you should be running buster, and considering moving to
> > the next stable release no sooner than a few weeks after the
> > transition to bullseye. You should accept security updates as
> > soon as is convenient for you, on an ongoing basis. Backports
> > are to solve specific issues.
> 
> Is it then possible to add the /testing line to be able to occasionally pull in specific packages from testing?  I think I would need a preferences.d/something.pref file.
> 
> deb     http://mirrors.linode.com/debian/   testing main contrib non-free
> deb-src http://mirrors.linode.com/debian/   testing main contrib non-free
> 
> Clearly if the package I wanted to install from testing would suck in a lot of dependencies, then I likely would not do that, but I don't want it to suck things in from testing automatically otherwise, I am then running testing.
> 
> Is this setup possible or am I really just going to have to be patient if something isn't in backports?

Yes. See

https://blog.randomstring.org/2016/08/17/debian-backports-pinning/

which gives examples for jessie and jessie-backports, but can
easily be translated into buster and testing, if that's what you
want.

With testing set to priority between 1 and 99, it will only
install packages if you explicitly ask for them, say

apt install -t testing packagename

The caution regarding dependencies that you have mentioned is spot-on.

-dsr-

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

#230607

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

On Ma, 12 ian 21, 11:03:06, Michael Grant wrote:
> On Tue, Jan 12, 2021 at 10:35:05AM -0500, Dan Ritter wrote:
> > Are you running a production system?
> 
> Yes, I guess you could call it production.  It's my family & friends 
> server.  In all the time I have been running Debian Testing, I have 
> never once suffered a serious or protracted disaster as you envision.  

Is this server accessible from the internet? If so, you really, really 
should be running stable on it. Really.

> Maybe I'm lucky!  Little things, yes, like the systemd thing the other 
> day.  On very rare occasions, I have had to pin a package.
> 
> > If so, you should be running buster, and considering moving to
> > the next stable release no sooner than a few weeks after the
> > transition to bullseye. You should accept security updates as
> > soon as is convenient for you, on an ongoing basis. Backports
> > are to solve specific issues.
> 
> Hence using buster as an example of today (understand should substitute bullseye after that release):
> 
> deb http://httpredir.debian.org/debian buster main non-free contrib
> deb-src http://httpredir.debian.org/debian buster main non-free contrib
> 
> deb http://security.debian.org/debian-security buster/updates main contrib non-free
> deb-src http://security.debian.org/debian-security buster/updates main contrib non-free
> 
> deb http://deb.debian.org/debian buster-backports main contrib non-free
> deb-src http://deb.debian.org/debian buster-backports main contrib non-free
> 
> Is it then possible to add the /testing line to be able to 
> occasionally pull in specific packages from testing?  I think I would 
> need a preferences.d/something.pref file.
> 
> deb     http://mirrors.linode.com/debian/   testing main contrib non-free
> deb-src http://mirrors.linode.com/debian/   testing main contrib non-free
> 
> Clearly if the package I wanted to install from testing would suck in 
> a lot of dependencies, then I likely would not do that, but I don't 
> want it to suck things in from testing automatically otherwise, I am 
> then running testing.
> 
> Is this setup possible or am I really just going to have to be patient 
> if something isn't in backports?

Anything is possible (hey, it's a big world), though not necessarily a 
good idea.

Installing packages from testing on stable is completely different than 
installing stable-backports on stable, even if the packages in 
stable-backports do come from testing.

The packages in stable-backports have been recompiled for stable by 
someone with experience in Debian packaging, at a minimum. Depending on 
the package additional changes might be needed as well, due to different 
packages / versions of other packages in stable compared to testing.

If you really, really need a package from testing that is not available 
in stable-backports the first thing to do is to ask for a backport on 
debian-backports (with Cc: to the package Maintainer, in case they might 
be willing to provide it).

Of course, this implies the package provides valuable new *features* 
that are otherwise not available in stable. Bugs in stable should be 
fixed via stable-updates (point releases).

In case no one is willing to provide a backport you can try doing the 
backport yourself, e.g. by recompiling the package yourself in a clean 
stable chroot. If successful you could even look for a sponsor to upload 
the package to stable-backports ;)

See https://backports.debian.org/Contribute/ for more details.

If none of the above is feasible and you really, really need the 
versions in testing (for a server? care to provide more details?), in my 
not so humble opinion you are better of running testing, with select 
packages from unstable (for security reasons only).

This will involve tracking potential security issues yourself, as the 
DSAs don't cover issues that are only present in testing and/or unstable 
(though they do cover security issues that are present in stable and 
also in unstable, so it's a start).

Hope this helps,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#231654

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

Replying to this message that's just over a month old now.  Now that
10.8 just came out, is this a good time to jump off the testing repo
and onto stable for my production box?  Is this one of those rare
moments when testing and stable line up?  Or should I continue to wait
for Bullseye?

On Tue, Jan 12, 2021 at 10:35:05AM -0500, Dan Ritter wrote:
> 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?
> 
> Are you running a production system?

Yes.

> That is, are you running a Debian system which is essential to
> your business or personal activities, so that having to recover
> from a disaster would be a significant hardship?

Well, yes, though I do have daily snapshots.

> If so, you should be running buster, and considering moving to
> the next stable release no sooner than a few weeks after the
> transition to bullseye. You should accept security updates as
> soon as is convenient for you, on an ongoing basis. Backports
> are to solve specific issues.
> 
> If you are running a system for fun, or if there is no real
> issue with protracted unavailability, testing is a fine thing
> to be running. You should expect a little chaos every time you
> update.
> 
> Only stable gets security updates. Testing may get security
> updates when they come from upstream, but it's not guaranteed.

I thought all security updates were tested in testing, committed to
testing, and then also committed to stable-security.  I had not
noticed that testing was not getting security updates, I thought it
was, maybe again, it was just luck that the packages I noticed needed
security updates were the ones I mentally track most like sendmail,
dovecot, spamassassin...

Michael Grant

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

#231655

On Fri, 2021-02-12 at 12:05 -0500, Michael Grant wrote:
> Replying to this message that's just over a month old now.  Now that
> 10.8 just came out, is this a good time to jump off the testing repo
> and onto stable for my production box?  Is this one of those rare
> moments when testing and stable line up?  Or should I continue to
> wait
> for Bullseye?

'stable' is currently and alias for 'buster' and 'testing' is for
'bullseye'. So if your /etc/apt/sources.list currently refers to
'testing' and you want to stick with bullseye when it's released then
change sources.list now, so it says 'bullseye' instead of 'testing'.

Don't change it to 'stable' because that's a 2 year old release and you
system wouldn't like that!

Once bullseye is released then the aliases will suddenly change, so
stable = bullseye and testing = bookworm.

-- 
Tixy

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

#231692

On Fri, Feb 12, 2021 at 12:05:44PM -0500, Michael Grant wrote:
> Replying to this message that's just over a month old now.  Now that
> 10.8 just came out, is this a good time to jump off the testing repo
> and onto stable for my production box?  Is this one of those rare
> moments when testing and stable line up?  Or should I continue to wait
> for Bullseye?
> 

The below is my opinion: it is informed by watching other folk have problems over the years.

TLDR; - If you are running a production system - run Debian's latest stable release. Stable 
gets security support and backported fixes for security issues.

Release overview:
================

Debian releases trickle down over a period of years: Unstable (code name Sid) -> Testing -> Stable.
[There is also an Experimental repository - but I'll leave that out for the sake of brevity].

Fictious example: Take the case of a brand new package Foo which, we'll say, is a personal productivity
 app. and updates regularly but on a fairly long timescale.

Debian unstable == codename "Sid"
---------------------------------

If package foo is introduced today, it will go into Sid in source code form and be built there. Sid is never
expected to be released in this form and receives no formal security or other support. If you run Sid, you're
expected to be experienced enough to fix any problems yourself. Major upgrades of something like a desktop
environmnent can sit in Sid for many months until all the components are ready and all dependencies are 
sorted out. Package churn can be severe and unpredictable.

After a short while with no major problems, and a minimal amount of testing, package foo can pass to Testing. 

Debian testing == codename "Bullseye" == Debian 11 when released.
----------------------------------------------------------------

"Testing" is preparation for the next large scale release of Debian.Testing effectively collects packages for
a couple of years until a freeze period and eventual release. [Debian 11 (code name Bullseye) - is at that
 stage at the moment: the freeze period has started relatively recently - it may be released in June 2021 or 
so following further freeze stages, all other things being equal.] 

At this point, package foo will not go into current stable: it will only be prepared for the NEXT release of
Debian months or years away.

There is a backports repository. This is a way to run a small number of packages from Debian testing on a
stable system. This might, for example, be an updated kernel because 5.10.x runs on your brand new hardware
whereas 4.19.x won't run the hardware correctly. These packages are built against the versions of the packages
in Debian stable (otherwise they won't run there) but provide new/different versions to those supported in stable.
No security support as such - if you're running backports, you are very much on your own / out as an edge case

If enough users of Debian stable really wanted package foo, it could, conceivably be put here into the backports
repository, but if it wasn't originally released as part of stable, you can't readily slipstream something straight
into Stable..

Package version numbers:
-----------------------

Very well established packages might have the same or subtly different versions from Sid all the way down to stable. 
It could be that there's version 4.x newly released in Sid, 3.x in Testing and 2.x in Stable for example with the 
different versions reflecting different codebases. 

Stable release == Debian 10 (Buster) as at 20200213
==============

As of today: Debian's latest stable release is Debian 10 - codename Buster - and the point release is Debian 10.8 (released on
February 8th, 2021). In due course, there will likely be a 10.9 - updates which roll up security updates / changes etc. occur
approximately every three months.

If you run a stable system, and keep it regularly updated, then the point releases will be very small changes as they occur.

"Frankendebian"
---------------

You shouldn't cherry pick between releases because that leads to instability. Likewise "I'll just pull XYZ from Ubuntu and
expect it to work on Debian X" will occasionallly work but more often than not produce impossible problems fo dependency 
and version instability which require significant unpicking.

All best, as ever,

Andy C.


> On Tue, Jan 12, 2021 at 10:35:05AM -0500, Dan Ritter wrote:
> > 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?
> > 
> > Are you running a production system?
> 
> Yes.
> 
> > That is, are you running a Debian system which is essential to
> > your business or personal activities, so that having to recover
> > from a disaster would be a significant hardship?
> 
> Well, yes, though I do have daily snapshots.
> 
> > If so, you should be running buster, and considering moving to
> > the next stable release no sooner than a few weeks after the
> > transition to bullseye. You should accept security updates as
> > soon as is convenient for you, on an ongoing basis. Backports
> > are to solve specific issues.
> > 
> > If you are running a system for fun, or if there is no real
> > issue with protracted unavailability, testing is a fine thing
> > to be running. You should expect a little chaos every time you
> > update.
> > 
> > Only stable gets security updates. Testing may get security
> > updates when they come from upstream, but it's not guaranteed.
> 
> I thought all security updates were tested in testing, committed to
> testing, and then also committed to stable-security.  I had not
> noticed that testing was not getting security updates, I thought it
> was, maybe again, it was just luck that the packages I noticed needed
> security updates were the ones I mentally track most like sendmail,
> dovecot, spamassassin...
> 
> Michael Grant

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

#231695

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

On Sat, Feb 13, 2021 at 02:32:56PM +0000, Andrew M.A. Cater wrote:
> The below is my opinion: it is informed by watching other folk have problems over the years.
> 
> TLDR; - If you are running a production system - run Debian's latest stable release. Stable 
> gets security support and backported fixes for security issues.
> 
> Release overview:
> ================
> 
> Debian releases trickle down over a period of years: Unstable (code name Sid) -> Testing -> Stable.
> [There is also an Experimental repository - but I'll leave that out for the sake of brevity].
> 
> Fictious example: Take the case of a brand new package Foo which, we'll say, is a personal productivity
>  app. and updates regularly but on a fairly long timescale.
> 
> Debian unstable == codename "Sid"
> ---------------------------------
> 
> If package foo is introduced today, it will go into Sid in source code form and be built there. Sid is never
> expected to be released in this form and receives no formal security or other support. If you run Sid, you're
> expected to be experienced enough to fix any problems yourself. Major upgrades of something like a desktop
> environmnent can sit in Sid for many months until all the components are ready and all dependencies are 
> sorted out. Package churn can be severe and unpredictable.
> 
> After a short while with no major problems, and a minimal amount of testing, package foo can pass to Testing. 
> 
> Debian testing == codename "Bullseye" == Debian 11 when released.
> ----------------------------------------------------------------
> 
> "Testing" is preparation for the next large scale release of Debian.Testing effectively collects packages for
> a couple of years until a freeze period and eventual release. [Debian 11 (code name Bullseye) - is at that
>  stage at the moment: the freeze period has started relatively recently - it may be released in June 2021 or 
> so following further freeze stages, all other things being equal.] 
> 
> At this point, package foo will not go into current stable: it will only be prepared for the NEXT release of
> Debian months or years away.
> 
> There is a backports repository. This is a way to run a small number of packages from Debian testing on a
> stable system. This might, for example, be an updated kernel because 5.10.x runs on your brand new hardware
> whereas 4.19.x won't run the hardware correctly. These packages are built against the versions of the packages
> in Debian stable (otherwise they won't run there) but provide new/different versions to those supported in stable.
> No security support as such - if you're running backports, you are very much on your own / out as an edge case
> 
> If enough users of Debian stable really wanted package foo, it could, conceivably be put here into the backports
> repository, but if it wasn't originally released as part of stable, you can't readily slipstream something straight
> into Stable..
> 
> Package version numbers:
> -----------------------
> 
> Very well established packages might have the same or subtly different versions from Sid all the way down to stable. 
> It could be that there's version 4.x newly released in Sid, 3.x in Testing and 2.x in Stable for example with the 
> different versions reflecting different codebases. 
> 
> Stable release == Debian 10 (Buster) as at 20200213
> ==============
> 
> As of today: Debian's latest stable release is Debian 10 - codename Buster - and the point release is Debian 10.8 (released on
> February 8th, 2021). In due course, there will likely be a 10.9 - updates which roll up security updates / changes etc. occur
> approximately every three months.
> 
> If you run a stable system, and keep it regularly updated, then the point releases will be very small changes as they occur.
> 
> "Frankendebian"
> ---------------
> 
> You shouldn't cherry pick between releases because that leads to instability. Likewise "I'll just pull XYZ from Ubuntu and
> expect it to work on Debian X" will occasionallly work but more often than not produce impossible problems fo dependency 
> and version instability which require significant unpicking.
> 
> All best, as ever,
> 
> Andy C.

Thanks Andy, Tixy, Andrei, Dan and others who have chimed in on this.

You all have convinced me to move to stable+backports.

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!

I initially moved to Testing because there were some packages that I
needed which were not in Backports and were regularlly maintained in
Testing.  I'm afraid I don't recall which packages anymore, I think it
might have been Sendmail.  Back then I thought (perhaps mistakenly)
that Testing was getting security fixes.  

Let me add to your recommendations above:

For the packages in Testing which don't make it into Backports, one
can first try to try to install the package from Testing, but if it
attempts to bring in other dependencies from Testing, stop.  If you
can't wait for the next release of Debian or someone to do a backport,
then the next best option is to try and build a backport yourself.
Pull down the source from Testing and use dbuild and build a local
package on Stable and apt install it.  This often works unless the
package depends on kernel or other specific things in the next Debian
release.

That process is detailed here:

https://wiki.debian.org/SimpleBackportCreation

Building packages has definitely gotten easier.

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?

Michael Grant

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

#231697

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, but since Debian is run by volunteers and many of
them are very busy it has been talked about but not beyond 
that.  the idea of rolling releases, always releasable, and 
some other phrases has been discussed, but until enough 
people get together to actually do it and prove that it 
works and will be supported it won't happen.  unstable is
perhaps the closest currently coming to that idea, but
the freeze process pushes development off into experimental
or upstream until the freeze is done and then the whole
cycle comes up again.

  to me the freeze should just be a snapshot that is 
worked from off to the side and then unstable can 
continue to be worked on and security fixes and such
can keep working through to testing.

  i suggest the acronym tasty for that snapshot (as in
tasty-freeze :) - you can use the other concepts of
soft-serve or hard-freeze and such to go along and if
you want more scoops or sprinkles added, etc.).  :)


  songbird

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

#231699

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

On Sat, Feb 13, 2021 at 11:31:16AM -0500, songbird wrote:
>   yes, but since Debian is run by volunteers and many of
> them are very busy it has been talked about but not beyond 
> that.  the idea of rolling releases, always releasable, and 
> some other phrases has been discussed, but until enough 
> people get together to actually do it and prove that it 
> works and will be supported it won't happen.  unstable is
> perhaps the closest currently coming to that idea, but
> the freeze process pushes development off into experimental
> or upstream until the freeze is done and then the whole
> cycle comes up again.

I understood that Unstable == Sid from Andrew's detailed message in
this thread and it's also on confirmed on this page:
https://wiki.debian.org/DebianUnstable.

I was not thinking this would cause more (or significantly more
anyway) work than we already do.  Dot releases are tested.  It might
even be *less* work as upgrades would be incremental and smaller
rather than large.

Thinking back, this is one of the beauties of Testing is that things
happen incrementally over time.  Sure, I may have to fix something
here and there but that often turns out to be easier and less
stressful than doing a major upgrade and having to set aside an entire
weekend.

Michael Grant

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

#231700

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

On Sb, 13 feb 21, 11:57:42, Michael Grant wrote:
> On Sat, Feb 13, 2021 at 11:31:16AM -0500, songbird wrote:
> >   yes, but since Debian is run by volunteers and many of
> > them are very busy it has been talked about but not beyond 
> > that.  the idea of rolling releases, always releasable, and 
> > some other phrases has been discussed, but until enough 
> > people get together to actually do it and prove that it 
> > works and will be supported it won't happen.  unstable is
> > perhaps the closest currently coming to that idea, but
> > the freeze process pushes development off into experimental
> > or upstream until the freeze is done and then the whole
> > cycle comes up again.
> 
> I understood that Unstable == Sid from Andrew's detailed message in
> this thread and it's also on confirmed on this page:
> https://wiki.debian.org/DebianUnstable.
> 
> I was not thinking this would cause more (or significantly more
> anyway) work than we already do.  Dot releases are tested.  It might
> even be *less* work as upgrades would be incremental and smaller
> rather than large.
> 
> Thinking back, this is one of the beauties of Testing is that things
> happen incrementally over time.  Sure, I may have to fix something
> here and there but that often turns out to be easier and less
> stressful than doing a major upgrade and having to set aside an entire
> weekend.

It depends a lot on your particular setup. Many users appreciate the 
non-changing of stable and often go on using a particular release even 
beyond it's EOL (against all advice).

Ubuntu started out with timed releases every 6 months (based on Debian 
sid), but later introduced the LTS. Clearly there is demand for both 
approaches.

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

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

#231702

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

On Sb, 13 feb 21, 11:57:42, Michael Grant wrote:
> 
> I was not thinking this would cause more (or significantly more
> anyway) work than we already do.  Dot releases are tested.  It might
> even be *less* work as upgrades would be incremental and smaller
> rather than large.

https://wiki.debian.org/ReleaseProposals

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

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

#231703

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

On Sb, 13 feb 21, 11:31:16, songbird wrote:
> 
>   to me the freeze should just be a snapshot that is 
> worked from off to the side and then unstable can 
> continue to be worked on and security fixes and such
> can keep working through to testing.

This can already be done, e.g. by uploading to 
'testing-proposed-updates' instead. The problem with this is that 
packages fixing bugs in testing will see less testing than packages in 
unstable, which is why the Release Team requests all updates to go via 
unstable instead and uses testing-proposed-updates only as a last 
resort.

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

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

#231698

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

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 ;)


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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web