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

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

Apt sources.list

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

Contents

  Apt sources.list <paulf@quillandmouse.com> - 2023-04-15 14:20 +0200
    Re: Apt sources.list Brian <ad44@cityscape.co.uk> - 2023-04-15 14:30 +0200
      Re: Apt sources.list Greg Wooledge <greg@wooledge.org> - 2023-04-15 15:00 +0200
        Re: Apt sources.list Alain D D Williams <addw@phcomp.co.uk> - 2023-04-15 15:40 +0200
          Re: Apt sources.list <tomas@tuxteam.de> - 2023-04-15 15:50 +0200
            Re: Apt sources.list Alain D D Williams <addw@phcomp.co.uk> - 2023-04-15 16:10 +0200
              Re: Apt sources.list <tomas@tuxteam.de> - 2023-04-15 16:20 +0200
          Re: Apt sources.list Brian <ad44@cityscape.co.uk> - 2023-04-15 16:10 +0200
          Re: Apt sources.list Charles Curley <charlescurley@charlescurley.com> - 2023-04-15 16:50 +0200
          Re: Apt sources.list <paulf@quillandmouse.com> - 2023-04-15 17:10 +0200
            Re: Apt sources.list Dan Ritter <dsr@randomstring.org> - 2023-04-15 18:40 +0200
              Re: Apt sources.list <tomas@tuxteam.de> - 2023-04-15 19:50 +0200
                Re: Apt sources.list davidson <davidson@freevolt.org> - 2023-04-16 01:00 +0200
                  Re: Apt sources.list Greg Wooledge <greg@wooledge.org> - 2023-04-16 01:20 +0200
                    Re: Apt sources.list The Wanderer <wanderer@fastmail.fm> - 2023-04-16 01:30 +0200
                      Re: Apt sources.list Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-16 02:30 +0200
                    Re: Apt sources.list davidson <davidson@freevolt.org> - 2023-04-16 02:20 +0200
                    Re: Apt sources.list Tim Woodall <debianuser@woodall.me.uk> - 2023-04-16 21:10 +0200
                      Re: Apt sources.list Jeffrey Walton <noloader@gmail.com> - 2023-04-16 23:00 +0200
                        Re: Apt sources.list Jeffrey Walton <noloader@gmail.com> - 2023-04-17 03:30 +0200
                          Re: Apt sources.list <tomas@tuxteam.de> - 2023-04-17 06:50 +0200
                            Re: Apt sources.list Jeffrey Walton <noloader@gmail.com> - 2023-04-17 17:10 +0200
                  Re: Apt sources.list <tomas@tuxteam.de> - 2023-04-16 07:40 +0200
                  Re: Apt sources.list Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2023-04-16 14:10 +0200
            Re: Apt sources.list Alain D D Williams <addw@phcomp.co.uk> - 2023-04-15 20:30 +0200
              Re: Apt sources.list Brian <ad44@cityscape.co.uk> - 2023-04-15 20:40 +0200
              Re: Apt sources.list Andy Smith <andy@strugglers.net> - 2023-04-15 22:00 +0200
            Re: Apt sources.list Charles Curley <charlescurley@charlescurley.com> - 2023-04-15 20:50 +0200
            Re: Apt sources.list Jeffrey Walton <noloader@gmail.com> - 2023-04-16 02:40 +0200
              Re: Apt sources.list <paulf@quillandmouse.com> - 2023-04-16 14:50 +0200
      Re: Apt sources.list <paulf@quillandmouse.com> - 2023-04-15 16:50 +0200
      Re: Apt sources.list "Andrew M.A. Cater" <amacater@einval.com> - 2023-04-15 18:50 +0200
        Re: Apt sources.list Brian <ad44@cityscape.co.uk> - 2023-04-15 21:20 +0200
          Re: Apt sources.list "Andrew M.A. Cater" <amacater@einval.com> - 2023-04-15 22:20 +0200
            Re: Apt sources.list songbird <songbird@anthive.com> - 2023-04-16 00:00 +0200
            Re: Apt sources.list Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-16 06:20 +0200
              Re: Apt sources.list David Wright <deblis@lionunicorn.co.uk> - 2023-04-16 07:00 +0200
              Re: Apt sources.list "Andrew M.A. Cater" <amacater@einval.com> - 2023-04-16 13:20 +0200
                Re: Apt sources.list Frank <zuiderduin@gmx.com> - 2023-04-16 16:40 +0200
                  Re: Apt sources.list John Hasler <john@sugarbit.com> - 2023-04-16 18:20 +0200
            Re: Apt sources.list Frank <zuiderduin@gmx.com> - 2023-04-16 07:20 +0200
              Re: Apt sources.list David Wright <deblis@lionunicorn.co.uk> - 2023-04-16 16:40 +0200
        Re: Apt sources.list <paulf@quillandmouse.com> - 2023-04-15 22:10 +0200
    Re: Apt sources.list Tixy <tixy@yxit.co.uk> - 2023-04-15 18:20 +0200
      Re: Apt sources.list Frank <zuiderduin@gmx.com> - 2023-04-15 22:00 +0200
        Re: Apt sources.list Vincent Lefevre <vincent@vinc17.net> - 2023-04-18 16:40 +0200
          Re: Apt sources.list Frank <zuiderduin@gmx.com> - 2023-04-18 19:50 +0200
            Re: Apt sources.list Jeffrey Walton <noloader@gmail.com> - 2023-04-18 20:00 +0200
              Re: Apt sources.list Vincent Lefevre <vincent@vinc17.net> - 2023-04-20 12:20 +0200
                Re: Apt sources.list Greg Wooledge <greg@wooledge.org> - 2023-04-20 13:30 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#257319

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

On Sun, Apr 16, 2023 at 09:20:22PM -0400, Jeffrey Walton wrote:

[...]

> > Corporations don't need browser cooperation for Data Loss Prevention
> > (DLP) (but they already have it). Corporations just run an
> > interception proxy, like NetSkope. The NetScope Root CA is loaded into
> > every browser trust store. The application will terminate all traffic,
> > inspect it, and forward the request if it looks innocuous.
> 
> To be clear... The NetSkope Root CA is loaded into browsers for
> computers owned by the corporation. I.e., part of the corporation's
> standard image.

Heh. You made me search for it in my browser's root CA store ;-)

Anyway, your points are all valid. I do recommend to have a look
at the browser's default root CA store before saying "you're safe
with TLS". This is just marketing. TLS is but one tool.

Don't get me wrong: I think widespread use of TLS is a Good Thing.
But going about it as if it was Redemption is paternalistic to the
point of being counterproductive.

Security is a process, not a product, as Schneier says.

Cheers
-- 
t

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

#257326

On Mon, Apr 17, 2023 at 12:45 AM <tomas@tuxteam.de> wrote:
>
> On Sun, Apr 16, 2023 at 09:20:22PM -0400, Jeffrey Walton wrote:
>
> [...]
> > > Corporations don't need browser cooperation for Data Loss Prevention
> > > (DLP) (but they already have it). Corporations just run an
> > > interception proxy, like NetSkope. The NetScope Root CA is loaded into
> > > every browser trust store. The application will terminate all traffic,
> > > inspect it, and forward the request if it looks innocuous.
> >
> > To be clear... The NetSkope Root CA is loaded into browsers for
> > computers owned by the corporation. I.e., part of the corporation's
> > standard image.
>
> Heh. You made me search for it in my browser's root CA store ;-)
>
> Anyway, your points are all valid. I do recommend to have a look
> at the browser's default root CA store before saying "you're safe
> with TLS". This is just marketing. TLS is but one tool.

Yeah, I call it the "CA Zoo." The Browsers will let just about anyone
into the store. All you need to do is check the boxes. If interested
in the day-to-day operations, subscribe to Mozilla's
dev-security-policy list at
https://groups.google.com/a/mozilla.org/g/dev-security-policy. It is
where CAs come to join the store.

There are some efforts to reduce the risk from the CA Zoo. For
example, VISA restricts the list as detailed at
https://developer.visa.com/pages/trusted_certifying_authorities .
VISA's list is 41 in size. It is better than the 150+ in Mozilla's and
Chrome's lists.

> Don't get me wrong: I think widespread use of TLS is a Good Thing.
> But going about it as if it was Redemption is paternalistic to the
> point of being counterproductive.
>
> Security is a process, not a product, as Schneier says.

Jeff

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

#257271

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

On Sat, Apr 15, 2023 at 10:54:10PM +0000, davidson wrote:

[...]

> What's wrong, Tomas? Don't you want to watch pornographic videos and
> conduct your banking with the same application?

I'm glad I don't have to use the browser for any of those.

Cheers
-- 
t

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

#257280

On 15/04/2023 19:54, davidson wrote:
> On Sat, 15 Apr 2023 tomas@tuxteam.de wrote:
>> On Sat, Apr 15, 2023 at 12:18:57PM -0400, Dan Ritter wrote:
>>> It's nice not to be telling everyone who can sniff a plaintext
>>> connection which packages you are installing,
>>
>> Without doubt, this is an advantage of a TLS connection. If you
>> do care about that, here would be one reason.
> 
> In case you wish to obscure what software you *install*, but need not
> conceal the software you *download*:
> 
>   Step one: Make a list of the packages you want, and then augment it
>   with as many plausible alternatives and red herrings as you like.
> 
>   Step two:
>   $ apt-get -d install <many packages>
> 
> This downloads the packages only, so you can download packages you
> will *not* install, along with ones you will. Then install the proper
> subset you want installed, without the '-d' option.

This consumes more resources than using TLS, and increased resource 
usage was one the arguments made against the need for TLS everywhere.


-- 
BOFH excuse #377:

Someone hooked the twisted pair wires into the answering machine.

Eduardo M KALINOWSKI
eduardo@kalinowski.com.br

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

#257239

On Sat, Apr 15, 2023 at 11:00:52AM -0400, paulf@quillandmouse.com wrote:

> Okay. Let's open this can of worms. The ONLY reason https is used on
> most sites is because Google *mandated* it years ago. ("Mandate" means
> we'll downgrade your search ranking if you don't use https.) There is
> otherwise no earthly reason to have an encrypted connection to a web
> server unless there is some exchange of private information between you
> and the server.

Where I live (England) I do not care if "the authorities" see what I have
installed on my machine. If I lived in a totalitarian state†† there are some
packages that might raise my profile on some "radar".

†† There are several - I will not mention names as I wish to keep politics out
of this list.

> Reading through all of Google's explanations, I've never seen a
> satisfactory explanation for this change. With that in mind, I believe
> the Debian gods did the right thing in leaving their web connections
> "insecure". Though, in truth, the integrity of Debian server contents
> wouldn't be changed in the slightest whether the connection was
> encrypted or not.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

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

#257240

On Sat 15 Apr 2023 at 19:21:17 +0100, Alain D D Williams wrote:

> On Sat, Apr 15, 2023 at 11:00:52AM -0400, paulf@quillandmouse.com wrote:
> 
> > Okay. Let's open this can of worms. The ONLY reason https is used on
> > most sites is because Google *mandated* it years ago. ("Mandate" means
> > we'll downgrade your search ranking if you don't use https.) There is
> > otherwise no earthly reason to have an encrypted connection to a web
> > server unless there is some exchange of private information between you
> > and the server.
> 
> Where I live (England) I do not care if "the authorities" see what I have
> installed on my machine. If I lived in a totalitarian state†† there are some
> packages that might raise my profile on some "radar".
> 
> †† There are several - I will not mention names as I wish to keep politics out
> of this list.

Very coy :). *You* brought politics up in your first paragraph.

-- 
Brian.

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

#257245

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

On Sat, Apr 15, 2023 at 07:21:17PM +0100, Alain D D Williams wrote:
> On Sat, Apr 15, 2023 at 11:00:52AM -0400, paulf@quillandmouse.com wrote:
> 
> > Okay. Let's open this can of worms. The ONLY reason https is used on
> > most sites is because Google *mandated* it years ago. ("Mandate" means
> > we'll downgrade your search ranking if you don't use https.) There is
> > otherwise no earthly reason to have an encrypted connection to a web
> > server unless there is some exchange of private information between you
> > and the server.
> 
> Where I live (England) I do not care if "the authorities" see what I have
> installed on my machine. If I lived in a totalitarian state†† there are some
> packages that might raise my profile on some "radar".

I am sad to have to type such an obvious point, but the https
feature exists for everyone, not just you. It is great that you are
privileged enough to not feel like you are under threat from your
own government (whether you have accurately estimated that risk is
another conversation) but not everyone is so privileged.

You did not ask if the feature made sense *for you*, you just asked
about the feature. Even if you *had* asked if it made sense for you,
no one would be able to answer as only you can decide what your
threat model is.

What you have said above is almost literally, "I don't have anything
to hide therefore I don't need privacy", but you've said it in such
a way as to imply that no one needs this particular feature.
Disappointing.

Your literal question was if there was any reason NOT to change
every APT URL to https. The objective answer is that not all Debian
mirrors support https! It seems like your real question was more
like, "is there any point to doing this" which you got a lot of
response to.

The hiding of the content of what is requested is a real feature
that some people want.

I haven't yet seen it mentioned in this thread but there are even
people who refute that argument. They say that an advanced attacker
in the middle will use traffic analysis and the publicly known sizes
of all Debian packages to easily work out which packages are
requested even without their names being visible.

Still, it not being in the clear makes this harder, and some people
want that.

By the way, in terms of malware distribution it is easier to
compromise a real Debian developer and get them to upload the bad
package in an entirely proper way. THis has already happened at
least once, though not to a stable release AFAIK. Unlike tampering
of in-flight downloads which has never been reported.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

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

#257241

On Sat, 15 Apr 2023 11:00:52 -0400
<paulf@quillandmouse.com> wrote:

> Okay. Let's open this can of worms. The ONLY reason https is used on
> most sites is because Google *mandated* it years ago. ("Mandate" means
> we'll downgrade your search ranking if you don't use https.) There is
> otherwise no earthly reason to have an encrypted connection to a web
> server unless there is some exchange of private information between
> you and the server.

 I disagree. If everyone only encrypted the traffic they wanted kept
 private, the bad guys would know that decrypting a stream would yield
 sensitive information. If we all encrypt a lot of our traffic,
 sensitive and otherwise, we reduce the advantage of cracking encrypted
 traffic.

There is no such thing as absolute security. There is only relative
security. The object, then, is to make yourself more secure than other
people. The bad guys will leave you alone and go after easier pickings.
Of course, the easier pickings should wise up and up their game as
well, leading to a nice virtuous spiral.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#257262

On Sat, Apr 15, 2023 at 11:09 AM <paulf@quillandmouse.com> wrote:
> On Sat, 15 Apr 2023 14:01:27 +0100
> Alain D D Williams <addw@phcomp.co.uk> wrote:
> > On Sat, Apr 15, 2023 at 08:52:06AM -0400, Greg Wooledge wrote:
> > While we are talking about this, is there any reason why all the
> > http: should not be https: ?
> >
> > I have done this on my own machine without ill effect.
>
> Okay. Let's open this can of worms. The ONLY reason https is used on
> most sites is because Google *mandated* it years ago. ("Mandate" means
> we'll downgrade your search ranking if you don't use https.) There is
> otherwise no earthly reason to have an encrypted connection to a web
> server unless there is some exchange of private information between you
> and the server.
>
> Reading through all of Google's explanations, I've never seen a
> satisfactory explanation for this change. With that in mind, I believe
> the Debian gods did the right thing in leaving their web connections
> "insecure". Though, in truth, the integrity of Debian server contents
> wouldn't be changed in the slightest whether the connection was
> encrypted or not.

The change came after Snowden released his cache of documents and the
world learned how pervasive snooping is by the US government. There's
nothing special about the US government, and we know other governments
were doing it, too.

I think Snowden accelerated HTTPS adoption or pushed it over the top.
The browsers were interested in encrypting communications for years
because of the "free ISPs". The ones like NetZero that provided no
cost dialup or broadband, but monitored connections and injected
JavaScript into web pages.

Not only did it happen with HTTPS, it also happened in mail protocols.
Google stopped accepting plain text SMTP connections, too.

I think the browsers did a pretty good job of forcing folks to use
encrypted channels. I think it helped secure content for most users.

One size did not fit all. I watched some browser engineers bully folks
on the Web Crypto mailing list pushing the "HTTPS Everywhere" agenda.
One fellow bullied was Mark Watson who tried to argue NetFlix only
needed encrypted comms part of the time (like login and streaming
content). The Google engineers' treatment of folks with non-conforming
viewpoints was awful.

Jeff

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

#257282

On Sat, 15 Apr 2023 20:30:11 -0400
Jeffrey Walton <noloader@gmail.com> wrote:

> On Sat, Apr 15, 2023 at 11:09 AM <paulf@quillandmouse.com> wrote:
> > On Sat, 15 Apr 2023 14:01:27 +0100
> > Alain D D Williams <addw@phcomp.co.uk> wrote:
> > > On Sat, Apr 15, 2023 at 08:52:06AM -0400, Greg Wooledge wrote:
> > > While we are talking about this, is there any reason why all the
> > > http: should not be https: ?
> > >
> > > I have done this on my own machine without ill effect.
> >
> > Okay. Let's open this can of worms. The ONLY reason https is used on
> > most sites is because Google *mandated* it years ago. ("Mandate"
> > means we'll downgrade your search ranking if you don't use https.)
> > There is otherwise no earthly reason to have an encrypted
> > connection to a web server unless there is some exchange of private
> > information between you and the server.
> >
> > Reading through all of Google's explanations, I've never seen a
> > satisfactory explanation for this change. With that in mind, I
> > believe the Debian gods did the right thing in leaving their web
> > connections "insecure". Though, in truth, the integrity of Debian
> > server contents wouldn't be changed in the slightest whether the
> > connection was encrypted or not.
> 
> The change came after Snowden released his cache of documents and the
> world learned how pervasive snooping is by the US government. There's
> nothing special about the US government, and we know other governments
> were doing it, too.
> 

OMG! The U.S. government spying on people??!! They only have at least
one government agency which does only that-- the NSA. And everyone's
known about this forever.

What's even funnier is Google pushing this change, since there's no
nosier company on Earth than those guys. Their treasure trove of user
data probably rivals the NSA's.

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

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

#257227

On Sat, 15 Apr 2023 13:23:05 +0100
Brian <ad44@cityscape.co.uk> wrote:

> On Sat 15 Apr 2023 at 08:11:17 -0400, paulf@quillandmouse.com wrote:
> 
> > Folks:
> > 
> > Here is my sources.list file:
> > 
> > ---
> > 
> > deb http://debian.uchicago.edu/debian/ bookworm main contrib
> > non-free deb-src http://debian.uchicago.edu/debian/ bookworm main
> > contrib non-free
> > 
> > deb http://security.debian.org/debian-security bookworm-security
> > main contrib non-free deb-src
> > http://security.debian.org/debian-security bookworm-security main
> > contrib non-free
> > 
> > ---
> > 
> > According to https://www.debian.org/releases/, bookworm at this
> > time is "testing". But when the next release comes, bookworm will
> > still be bookworm, but "testing" will be bookworm "plus". I'd like
> > to follow testing, regardless of the status of Debian official
> > releases.
> > 
> > So... in my sources.list, if I change "bookworm" to "testing", will
> > it do that, and (other than the instabilities of testing) is there
> > any liability to it?
> 
> bookworm to testing is exactly what you want.
> 

Thanks for your advice. I ran apt update with no issues.

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

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

#257232

On Sat, Apr 15, 2023 at 01:23:05PM +0100, Brian wrote:
> On Sat 15 Apr 2023 at 08:11:17 -0400, paulf@quillandmouse.com wrote:
> 
> > Folks:
> > 
> > Here is my sources.list file:
> > 
> > ---
> > 
> > deb http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > deb-src http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > 
> > deb http://security.debian.org/debian-security bookworm-security main
> > contrib non-free deb-src http://security.debian.org/debian-security bookworm-security main contrib non-free
> > 
> > ---
> > 
> > According to https://www.debian.org/releases/, bookworm at this time is
> > "testing". But when the next release comes, bookworm will still be
> > bookworm, but "testing" will be bookworm "plus". I'd like to follow
> > testing, regardless of the status of Debian official releases.
> > 

I would really not advise that. The changes as one distribution rolls to 
stable and the next one becomes testing are quite major - also, things
change (like sources.list files).

I would suggest that you remain on bookworm until bookworm is released as
stable. At that point (and only then) change bookworm to trixie and carry
on. As soon as bookworm is released, there will be massive churn.

Stable, testing, unstable are mutable: distribution code names are not.
There's a reason why Debian switched to codenames early - there never was
a Debian 1.0 - https://en.wikipedia.org/wiki/Debian_version_history
and https://wiki.debian.org/DebianReleases

With every good wish, as ever,

Andy Cater
> > So... in my sources.list, if I change "bookworm" to "testing", will it
> > do that, and (other than the instabilities of testing) is there any
> > liability to it?
> 
> bookworm to testing is exactly what you want.
> 
> -- 
> Brian.
> 

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

#257242

On Sat 15 Apr 2023 at 16:45:40 +0000, Andrew M.A. Cater wrote:

> On Sat, Apr 15, 2023 at 01:23:05PM +0100, Brian wrote:
> > On Sat 15 Apr 2023 at 08:11:17 -0400, paulf@quillandmouse.com wrote:
> > 
> > > Folks:
> > > 
> > > Here is my sources.list file:
> > > 
> > > ---
> > > 
> > > deb http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > > deb-src http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > > 
> > > deb http://security.debian.org/debian-security bookworm-security main
> > > contrib non-free deb-src http://security.debian.org/debian-security bookworm-security main contrib non-free
> > > 
> > > ---
> > > 
> > > According to https://www.debian.org/releases/, bookworm at this time is
> > > "testing". But when the next release comes, bookworm will still be
> > > bookworm, but "testing" will be bookworm "plus". I'd like to follow
> > > testing, regardless of the status of Debian official releases.
> > > 
> 
> I would really not advise that. The changes as one distribution rolls to 
> stable and the next one becomes testing are quite major - also, things
> change (like sources.list files)

That's correct. The same applies to unstable, which I have run for many years.

> I would suggest that you remain on bookworm until bookworm is released as
> stable. At that point (and only then) change bookworm to trixie and carry
> on. As soon as bookworm is released, there will be massive churn.

OK. But how is testing one day before the release of bookworm significantly
different from trixie a day afterwards?

-- 
Brian.

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

#257249

On Sat, Apr 15, 2023 at 08:14:11PM +0100, Brian wrote:
> On Sat 15 Apr 2023 at 16:45:40 +0000, Andrew M.A. Cater wrote:
> 
> > I would suggest that you remain on bookworm until bookworm is released as
> > stable. At that point (and only then) change bookworm to trixie and carry
> > on. As soon as bookworm is released, there will be massive churn.
> 
> OK. But how is testing one day before the release of bookworm significantly
> different from trixie a day afterwards?
> 

"Testing" one day before bookworm release -> bookworm.

On release day, bookworm -> "stable", "unstable" -> testing == trixie
Trixie is copied, essentially as the kickstarter for new "unstable".
"Unstable" == Forky. 

The pent up changes that have been waiting while the freeze has been on
all come out at once, potentially.

It might not be very much, but it could be a bunch of stuff, size, effects
unknown. Bookworm has been frozen-ish since January ...

It's as nothing to the "feels larger" shock to people who keep their 
Debian pinned to "stable" and suddenly get ~2.2 years worth of (possibly
incompatible) changes in a day, however, and then wonder what hit them.

All best, as ever,

Andy Cater

All best, as ever

> -- 
> Brian.
> 

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

#257251

Andrew M.A. Cater wrote:
...
> On release day, bookworm -> "stable", "unstable" -> testing == trixie
> Trixie is copied, essentially as the kickstarter for new "unstable".
> "Unstable" == Forky. 

  Unstable == Sid  Forky will happen sometime in the future
when they start talking about freezing testing again.


  songbird

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

#257267

> On release day, bookworm -> "stable",

So far so good.

> "unstable" -> testing == trixie

Really?  I thought there was always a delay for packages to move from
unstable to testing.


        Stefan

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

#257268

On Sun 16 Apr 2023 at 00:10:33 (-0400), Stefan Monnier wrote:
> > On release day, bookworm -> "stable",
> 
> So far so good.
> 
> > "unstable" -> testing == trixie
> 
> Really?  I thought there was always a delay for packages to move from
> unstable to testing.

Well, I suppose it gives the naïve user a few days for thinking they
got away with it unscathed.

Cheers,
David.

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

#257279

On Sun, Apr 16, 2023 at 12:10:33AM -0400, Stefan Monnier wrote:
> > On release day, bookworm -> "stable",
> 
> So far so good.
> 
> > "unstable" -> testing == trixie
> 
> Really?  I thought there was always a delay for packages to move from
> unstable to testing.
> 

Let's try this again because release day is "special" in the sense
that all the links move down.

Release day -1 (with luck, sometime in late May or early June 2023)

"Oldstable" == Buster == Debian 10
"Stable" == Bullseye == Debian 11
"Stable-updates / Stable backports" -> the Bullseye target
"Testing" == Bookworm (== Debian 12) [FROZEN for several months]
"Unstable" == Sid (== Trixie == will be Debian 13)
"Experimental == RC-Buggy" - stuff that's too unstable for Sid / not
targetted for Testing eventually

Release day when someone pushes the magic switch and the symlinks move :)

"Oldoldstable" == Buster == Debian 10
"Oldstable" == Bullseye == Debian 11
"Stable" == Bookworm == Debian 12
"Testing-proposed-updates" is empty because that's been frozen for months
[If there is anything in it, that now becomes stable updates for next
point release for Bookworm]
"Stable backports" for Buster are removed.
"Stable-backports" for Bookworm is created as is a new T-P-U if needed.
"Testing" == "Previous contents of Unstable" (== Trixie / Debian 13)
"Unstable" == Sid == empty /some of the contents of RC-Buggy (some of which will == Debian 14 eventually as Forky)
"Experimental == RC-Buggy"

The moves are instantaneous in one sense: once they're done, then the normal 
routine applies and updates intended for Trixie will be placed into Unstable
and then move through downwards from then on.

On release day, essentially Bookworm remains frozen and the codebase doesn't
move again unless getting updates from either debian-security
or stable backports (if that's what people want). No new code goes in at all.

Testing is now an entirely separate distro which should be developing from
now and will be released in ~two years.

Hence the suggestion to ride with Bookworm until release day precisely and
change at that point to Trixie: using the codenames is always preferable
> 
>         Stefan
>

All the very best, as ever,

Andy 

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

#257294

Op 16-04-2023 om 13:12 schreef Andrew M.A. Cater:
> Release day when someone pushes the magic switch and the symlinks move :)

[snip]

> "Testing" == "Previous contents of Unstable" (== Trixie / Debian 13)

Are you kidding? No way! Unstable is never pushed into testing just like 
that. There are packages that will never move to testing at all!

> "Unstable" == Sid == empty /some of the contents of RC-Buggy (some of which will == Debian 14 eventually as Forky)

And this doesn't make sense either.

Regards,
Frank

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

#257305

Frank writes:
> Are you kidding? No way! Unstable is never pushed into testing just
> like that. There are packages that will never move to testing at all!

That's correct.

Immediately after the release Testing and Stable are identical. Unstable
is unchanged.  When the freeze is lifted packages that have been waiting
in Unstable begin to flow into Testing.

Packages that have been bug-free in Unstable for ten days are linked
into Testing provided all dependencies can be met and that no freeze is
in effect.  They are *not* removed from Unstable.  Packages that have
migrated to Testing remain in Unstable until they are replaced by new
uploads.
-- 
John Hasler 
john@sugarbit.com
Elmwood, WI USA

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web