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

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

How Buster release may affect Unstable?

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

Contents

  How Buster release may affect Unstable? Default User <hunguponcontent@gmail.com> - 2019-07-01 19:30 +0200
    Re: How Buster release may affect Unstable? Brian <ad44@cityscape.co.uk> - 2019-07-01 20:00 +0200
      Re: How Buster release may affect Unstable? Default User <hunguponcontent@gmail.com> - 2019-07-01 21:40 +0200
        Re: How Buster release may affect Unstable? Dan Ritter <dsr@randomstring.org> - 2019-07-01 22:10 +0200
        Re: How Buster release may affect Unstable? Joe <joe@jretrading.com> - 2019-07-01 22:30 +0200
          Re: How Buster release may affect Unstable? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-01 22:50 +0200
          Re: How Buster release may affect Unstable? deloptes <deloptes@gmail.com> - 2019-07-01 23:20 +0200
            Re: How Buster release may affect Unstable? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-01 23:30 +0200
          Re: How Buster release may affect Unstable? Curt <curty@free.fr> - 2019-07-02 10:40 +0200
            Re: How Buster release may affect Unstable? Curt <curty@free.fr> - 2019-07-02 19:50 +0200
        Re: How Buster release may affect Unstable? Ansgar <ansgar@debian.org> - 2019-07-01 23:30 +0200
          Re: How Buster release may affect Unstable? <tomas@tuxteam.de> - 2019-07-02 09:20 +0200
        Re: How Buster release may affect Unstable? Dave Sherohman <dave@sherohman.org> - 2019-07-02 11:40 +0200
          Re: How Buster release may affect Unstable? Default User <hunguponcontent@gmail.com> - 2019-07-02 18:30 +0200
            Re: How Buster release may affect Unstable? Francisco M Neto <fmneto@fmneto.com.br> - 2019-07-05 16:00 +0200
              Re: How Buster release may affect Unstable? Dave Sherohman <dave@sherohman.org> - 2019-07-08 09:50 +0200
    Re: How Buster release may affect Unstable? Matthew Crews <mailinglists@mattcrews.com> - 2019-07-02 00:00 +0200
      Re: How Buster release may affect Unstable? <tomas@tuxteam.de> - 2019-07-02 09:30 +0200
        Re: How Buster release may affect Unstable? Joe <joe@jretrading.com> - 2019-07-02 09:40 +0200

#210560 — How Buster release may affect Unstable?

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

Hi.

Easy question, maybe hard to answer . . .

Is someone has an existing conventional Unstable setup (nothing exotic in
hardware or software), what if any special actions should be taken before,
during, or after the impending release of the new Stable?

(inb4:
1 - RTFM
2 - RTF release notes)

[toc] | [next] | [standalone]

#210562

On Mon 01 Jul 2019 at 13:24:48 -0400, Default User wrote:

> Hi.
> 
> Easy question, maybe hard to answer . . .
> 
> Is someone has an existing conventional Unstable setup (nothing exotic in
> hardware or software), what if any special actions should be taken before,
> during, or after the impending release of the new Stable?
> 
> (inb4:
> 1 - RTFM
> 2 - RTF release notes)

The question doesn't really make sense. The situation is that packages
in buster came from unstable. That is, unstable affects and determines
buster, not the other way round. Any use of unstable obliges a user to
keep on top of changes there.

-- 
Brian.

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

#210566

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

On Mon, Jul 1, 2019, 13:51 Brian <ad44@cityscape.co.uk> wrote:

> On Mon 01 Jul 2019 at 13:24:48 -0400, Default User wrote:
>
> > Hi.
> >
> > Easy question, maybe hard to answer . . .
> >
> > Is someone has an existing conventional Unstable setup (nothing exotic in
> > hardware or software), what if any special actions should be taken
> before,
> > during, or after the impending release of the new Stable?
> >
> > (inb4:
> > 1 - RTFM
> > 2 - RTF release notes)
>
> The question doesn't really make sense. The situation is that packages
> in buster came from unstable. That is, unstable affects and determines
> buster, not the other way round. Any use of unstable obliges a user to
> keep on top of changes there.
>
> --
> Brian.
>



Well, a recent thread about encrypted file systems got me to thinking.

What if a new Stable release introduces a major change to the existing
distribution technology or methodology?

For example, a new default filesystem is introduced.  Or something like
systemd infects the distribution or its rate of metastasis accelerates,
etc.  Or an important package management system or communication protocol
is superseded or falls into disuse, or is simply abandoned by its
developers or maintainers.

I was wondering if an existing Unstable setup could diverge so far from
Stable that major surgery would be necessary, or even complete replacement
with Stable, followed by conversion to contemporaneous Unstable.

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

#210570

Default User wrote: 
> On Mon, Jul 1, 2019, 13:51 Brian <ad44@cityscape.co.uk> wrote:
> 
> What if a new Stable release introduces a major change to the existing
> distribution technology or methodology?
> 
> For example, a new default filesystem is introduced.  Or something like
> systemd infects the distribution or its rate of metastasis accelerates,
> etc.  Or an important package management system or communication protocol
> is superseded or falls into disuse, or is simply abandoned by its
> developers or maintainers.
> 
> I was wondering if an existing Unstable setup could diverge so far from
> Stable that major surgery would be necessary, or even complete replacement
> with Stable, followed by conversion to contemporaneous Unstable.

Debian basically holds to two promises: it will be possible to upgrade
in-place from one stable major version to the next stable major version;
and, inside a stable major version, changes are made for security and
bug fixing but not for the sake of new features.

Let's look at the scenarios you presented, through three fairy-tales
of complete fiction which bear no resemblance to any form of reality
whatsoever:

1. Oracle implodes into a corporate black hole, leaving behind a
bankruptcy administrator who sells the rights to ZFS and all related
technologies and patents to the Free Software Foundation for $20 and
a stick of fruit-flavored gum. Everyone decides that ZFS should be the
new default filesystem.

In this case, the Debian Installer would soon gain support for creating
zpools and zfs, and new installs would use it by default. Existing
installs would not be affected.

2. Lennart Poettering is anointed of heaven and a voice from the
sky booms "All shall use systemd, pulseaudio and avahi!". No
problem, all those packages are in Debian already.

3. Debian maintains the .deb format itself, so it can't be superseded
(though it can be improved, and there's a versioning scheme.) Let's say
that all of the OpenBSD hackers simultaneously upload themselves into
cyberspace and stop supporting OpenSSH. There are other folks who can
do that job, and the license is permissive, so it's legal. I imagine we
probably get three competing SSH implementations, which isn't actually
bad, since they aren't SSH if they can't interoperate.

Now, an individual machine can, certainly, fall into an unstable trap
where something majorish is both installed and can't be upgraded out
of. At that point, I would strongly consider my previous life choices,
and also write down the config, backup the data, and start again with
a new machine.

-dsr-

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

#210574

On Mon, 1 Jul 2019 15:34:55 -0400
Default User <hunguponcontent@gmail.com> wrote:


> 
> Well, a recent thread about encrypted file systems got me to thinking.
> 
> What if a new Stable release introduces a major change to the existing
> distribution technology or methodology?
> 
> For example, a new default filesystem is introduced.  

That's happened a couple of times in my experience. Nothing changes on
an upgraded system, you are just offered the new one as a default on a
new installation. The old default will not be dropped for at least one
more release cycle, usually much longer with something as fundamental as
a filesystem.

> Or something
> like systemd infects the distribution or its rate of metastasis
> accelerates, etc.  Or an important package management system or
> communication protocol is superseded or falls into disuse, or is
> simply abandoned by its developers or maintainers.

Presumably, apt-get will be dropped one day, but apt is already the
preferred system, with more functionality than apt-get.

> 
> I was wondering if an existing Unstable setup could diverge so far
> from Stable that major surgery would be necessary, or even complete
> replacement with Stable, followed by conversion to contemporaneous
> Unstable.

Debian's main selling point is that a Stable can *always* be upgraded
in place to the next version, so that kind of incompatibility does not
arise. You may need to use a new configuration file for some
applications: keeping the old one often works, but not always. You
can't rely on an upgrade going perfectly on a first try, it's always
worth trying it on a spare machine if at all possible, but there's
always a way of doing it.

Some packages are dropped (i.e. not just a new version introduced) but
the obsolete package will not be removed without explicit permission. It
just wouldn't be available to a new installation.

Certainly, Unstable moves away from a new Stable until it is pretty
much the next Stable, which usually involves major changes. But the
old way of doing things can usually be used for a while. Do expect
rapid and large changes in Unstable and Testing when a new Stable is
born, there's always a backlog of new packages that are *not*
compatible with the former Testing. This also happens when Testing is
frozen.

-- 
Joe

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

#210575

On Mon, Jul 01, 2019 at 09:25:17PM +0100, Joe wrote:
> Presumably, apt-get will be dropped one day, but apt is already the
> preferred system, with more functionality than apt-get.

For GNU's sake, _dselect_ is still packaged!

I can't imagine apt-get going anywhere, so long as Debian lives.  Not in
my lifetime at least.

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

#210577

Joe wrote:

> Presumably, apt-get will be dropped one day, but apt is already the
> preferred system, with more functionality than apt-get.

AFAIK apt is frontend to apt-get, or I am wrong?

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

#210578

On Mon, Jul 01, 2019 at 11:18:18PM +0200, deloptes wrote:
> Joe wrote:
> 
> > Presumably, apt-get will be dropped one day, but apt is already the
> > preferred system, with more functionality than apt-get.
> 
> AFAIK apt is frontend to apt-get, or I am wrong?

They're both front-ends to the APT libraries that do the actual work.

apt-get is older, and has now been declared to be the stable CLI for
writing scripts.

apt is newer, and has been declared the preferred interactive command,
with evolving features.

Of course, if you don't like some of the evolving features, you can still
use apt-get interactively.

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

#210588

On 2019-07-01, Joe <joe@jretrading.com> wrote:
>
> Debian's main selling point is that a Stable can *always* be upgraded
> in place to the next version, so that kind of incompatibility does not

Then it will fail to live up to the marketing for the brave 600 or so
Debian users (according to Popularity Contest) regularly employing
ecryptfs-utils:

 The ecryptfs-utils package is not part of buster due to an unfixed
 serious bug (#765854). At the time of writing this paragraph, there was
 no clear advice for users of eCryptfs, except not to upgrade.

And yet the serious unfixed bug doesn't appear to even belong to
ecryptfs-utils per se, but rather to systemd:

 https://github.com/systemd/systemd/issues/8598
 systemd-user doesn't properly close its PAM session #8598

 The systemd --user instance that is started when a user first logs in (if
 pam_systemd is enabled) starts a subprocess "(sd-pam)" that opens a PAM session
 for the user, using the "systemd-user" service name. See setup_pam() in
 src/core/execute.c.

 However, this PAM session is not properly closed. 

Which results, in my understanding of the thing, in a Private directory
not being unmounted at user logout (ecryptfs-umount-private believing
one session is still remaining) and "bug" #765854.

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

#210614

On 2019-07-02, Curt <curty@free.fr> wrote:
> On 2019-07-01, Joe <joe@jretrading.com> wrote:
>>
>> Debian's main selling point is that a Stable can *always* be upgraded
>> in place to the next version, so that kind of incompatibility does not
>
> Then it will fail to live up to the marketing for the brave 600 or so
                                                              1066

Oops. One thousand and sixty-six regular users of ecryptfs-utils. We are
legion. It's 'encfs' with only 600 or so regular users (622, to be exact).

> Debian users (according to Popularity Contest) regularly employing
> ecryptfs-utils:

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

#210579

Default User <hunguponcontent@gmail.com> writes:
> Or something like
> systemd infects the distribution or its rate of metastasis accelerates,

I think we should make systemd mandatory; it would help make Debian a
more welcoming distribution by making toxic people hopefully finally go
away.

Ansgar

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

#210585

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

On Mon, Jul 01, 2019 at 11:27:40PM +0200, Ansgar wrote:
> Default User <hunguponcontent@gmail.com> writes:
> > Or something like
> > systemd infects the distribution or its rate of metastasis accelerates,

This was definitely toxic...

> I think we should make systemd mandatory; it would help make Debian a
> more welcoming distribution by making toxic people hopefully finally go
> away.

... and this was as much.

Please, folks. Just be civilised. Can't be that hard.

Cheers
-- t

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

#210593

On Mon, Jul 01, 2019 at 03:34:55PM -0400, Default User wrote:
> What if a new Stable release introduces a major change to the existing
> distribution technology or methodology?
> 
> For example, a new default filesystem is introduced.  Or something like
> systemd infects the distribution or its rate of metastasis accelerates,
> etc.  Or an important package management system or communication protocol
> is superseded or falls into disuse, or is simply abandoned by its
> developers or maintainers.
> 
> I was wondering if an existing Unstable setup could diverge so far from
> Stable that major surgery would be necessary, or even complete replacement
> with Stable, followed by conversion to contemporaneous Unstable.

I think the core misunderstanding here is that you seem to be assuming
that, when a new stable comes out, a new unstable is created to go with
it.

This is not the case.  *NOTHING* ever goes from stable into unstable.
*EVERYTHING* in stable[1] got there by way of unstable (with a stop off
in testing along the way).  If a major change happens in stable, then it
already happened some months or years ago in unstable:

- New filesystems start in unstable, then move to stable.

- systemd for Debian was first implemented in unstable, then made its
  way into stable.

- If apt were to somehow be replaced, that process would happen in
  unstable and the new package management tools would first appear
  there, before migrating into stable.

So, no, a new stable release would never break unstable.  Any breakage
that may happen would be flowing in the other direction (something
coming from unstable breaks stable), and even that is extremely rare.


[1] ...except security updates, which have their own path into stable
that doesn't pass through unstable, but they're not going to be
introducing major changes anyhow.

-- 
Dave Sherohman

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

#210612

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

On Tue, Jul 2, 2019, 05:38 Dave Sherohman <dave@sherohman.org> wrote:

> On Mon, Jul 01, 2019 at 03:34:55PM -0400, Default User wrote:
> > What if a new Stable release introduces a major change to the existing
> > distribution technology or methodology?
> >
> > For example, a new default filesystem is introduced.  Or something like
> > systemd infects the distribution or its rate of metastasis accelerates,
> > etc.  Or an important package management system or communication protocol
> > is superseded or falls into disuse, or is simply abandoned by its
> > developers or maintainers.
> >
> > I was wondering if an existing Unstable setup could diverge so far from
> > Stable that major surgery would be necessary, or even complete
> replacement
> > with Stable, followed by conversion to contemporaneous Unstable.
>
> I think the core misunderstanding here is that you seem to be assuming
> that, when a new stable comes out, a new unstable is created to go with
> it.
>
> This is not the case.  *NOTHING* ever goes from stable into unstable.
> *EVERYTHING* in stable[1] got there by way of unstable (with a stop off
> in testing along the way).  If a major change happens in stable, then it
> already happened some months or years ago in unstable:
>
> - New filesystems start in unstable, then move to stable.
>
> - systemd for Debian was first implemented in unstable, then made its
>   way into stable.
>
> - If apt were to somehow be replaced, that process would happen in
>   unstable and the new package management tools would first appear
>   there, before migrating into stable.
>
> So, no, a new stable release would never break unstable.  Any breakage
> that may happen would be flowing in the other direction (something
> coming from unstable breaks stable), and even that is extremely rare.
>
>
> [1] ...except security updates, which have their own path into stable
> that doesn't pass through unstable, but they're not going to be
> introducing major changes anyhow.
>
> --
> Dave Sherohman
>




Okay.

This is pretty much what I was thinking, and is as expected.

Thank you to those who gave helpful, constructive replies.

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

#210773

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

On Tue, 2019-07-02 at 12:23 -0400, Default User wrote:
> 
> 
> On Tue, Jul 2, 2019, 05:38 Dave Sherohman <dave@sherohman.org> wrote:
> > I think the core misunderstanding here is that you seem to be assuming
> > that, when a new stable comes out, a new unstable is created to go with
> > it.

	Well... maybe? I mean, certain developers or maintainers may be aware of
the release cycle and delay their uploads into unstable until after the new
stable is released. In that case, Sid should experience an unusually high number
of updates over the next few weeks.

-- 
[]'s,

Francisco M Neto

GPG: 4096R/D692FBF0

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

#210965

On Fri, Jul 05, 2019 at 10:35:05AM -0300, Francisco M Neto wrote:
> On Tue, 2019-07-02 at 12:23 -0400, Default User wrote:
> > On Tue, Jul 2, 2019, 05:38 Dave Sherohman <dave@sherohman.org> wrote:
> > > I think the core misunderstanding here is that you seem to be assuming
> > > that, when a new stable comes out, a new unstable is created to go with
> > > it.
> 
> 	Well... maybe? I mean, certain developers or maintainers may be aware of
> the release cycle and delay their uploads into unstable until after the new
> stable is released. In that case, Sid should experience an unusually high number
> of updates over the next few weeks.

Yes, true, there will be (are?) a lot of new uploads to unstable in the
wake of the new stable release, but my impression was that the OP might
have been thinking that stretch-unstable is going to be discontinued and
replaced with a brand new buster-unstable (based on the stable buster
release), which isn't the case.  sid remains sid forever and will never
be replaced with a different unstable.

-- 
Dave Sherohman

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

#210580

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

On 7/1/19 10:24 AM, Default User wrote:
> Hi.
> 
> Easy question, maybe hard to answer . . . 
> 
> Is someone has an existing conventional Unstable setup (nothing exotic
> in hardware or software), what if any special actions should be taken
> before, during, or after the impending release of the new Stable?

Be ready for Unstable to become...well, unstable again.

Right now Unstable is mostly frozen due to the imminent release of
Buster. Shortly (immediately?) after Buster is released, Unstable will
be unfrozen, and the good 'ol Debian Sid everyone knows and loves will
be back.

Remember: the purpose of Debian Unstable is to be a development platform
to develop the NEXT Stable. Breakage can, and will, occur on occasion,
and system stability is not guaranteed.

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

#210586

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

On Mon, Jul 01, 2019 at 11:51:10PM +0200, Matthew Crews wrote:
> On 7/1/19 10:24 AM, Default User wrote:
> > Hi.
> > 
> > Easy question, maybe hard to answer . . . 
> > 
> > Is someone has an existing conventional Unstable setup (nothing exotic
> > in hardware or software), what if any special actions should be taken
> > before, during, or after the impending release of the new Stable?
> 
> Be ready for Unstable to become...well, unstable again.
> 
> Right now Unstable is mostly frozen due to the imminent release of
> Buster. Shortly (immediately?) after Buster is released, Unstable will
> be unfrozen, and the good 'ol Debian Sid everyone knows and loves will
> be back.

Officially, only "testing" gets really frozen, but still unstable might
be seen as "slush" during that time. Quoting from [1]:

  6.5.1 What about "testing"? How is it `frozen'?

  When the "testing" distribution is mature enough, the release
  manager starts `freezing' it [...]

  After a while, the "testing" distribution becomes truly `frozen'
  [...]

  When a "testing" release becomes `frozen', "unstable" tends
  to partially freeze as well. This is because developers are
  reluctant to upload radically new software to unstable

So expect those "reluctant developers" to go a bit wild after
the release :-)

Cheers

[1] https://www.debian.org/doc/manuals/debian-faq/ch-ftparchives#s-frozen

-- t

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

#210587

On Tue, 2 Jul 2019 09:21:59 +0200
<tomas@tuxteam.de> wrote:

> On Mon, Jul 01, 2019 at 11:51:10PM +0200, Matthew Crews wrote:
> > On 7/1/19 10:24 AM, Default User wrote:  
> > > Hi.
> > > 
> > > Easy question, maybe hard to answer . . . 
> > > 
> > > Is someone has an existing conventional Unstable setup (nothing
> > > exotic in hardware or software), what if any special actions
> > > should be taken before, during, or after the impending release of
> > > the new Stable?  
> > 
> > Be ready for Unstable to become...well, unstable again.
> > 
> > Right now Unstable is mostly frozen due to the imminent release of
> > Buster. Shortly (immediately?) after Buster is released, Unstable
> > will be unfrozen, and the good 'ol Debian Sid everyone knows and
> > loves will be back.  
> 
> Officially, only "testing" gets really frozen, but still unstable
> might be seen as "slush" during that time. Quoting from [1]:
> 
>   6.5.1 What about "testing"? How is it `frozen'?
> 
>   When the "testing" distribution is mature enough, the release
>   manager starts `freezing' it [...]
> 
>   After a while, the "testing" distribution becomes truly `frozen'
>   [...]
> 
>   When a "testing" release becomes `frozen', "unstable" tends
>   to partially freeze as well. This is because developers are
>   reluctant to upload radically new software to unstable
> 
> So expect those "reluctant developers" to go a bit wild after
> the release :-)
> 

They haven't exactly been quiet during the freeze. Tens of megabytes a
day on my workstation, often over 100. But yes, major architecture
changes tend to be kept in the pipeline until after release.

-- 
Joe

[toc] | [prev] | [standalone]

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

csiph-web