Discussion:
[tor-dev] the consequences of deprecating debian alpha repos with every new major branch
nusenu
2018-06-30 14:42:00 UTC
Permalink
Hi,

tldr:
- more outdated relays
(that is a claim I'm making and you could
easily proof me wrong by recreating the 0.3.3.x alpha
repos and ship 0.3.3.7 in them and see how things evolve
after a week or so)
- more work for the tpo website maintainer
- less happy relay operators [3][4]
- more work for repo maintainers? (since a new repo needs to be created)



When the tor 0.3.4 alpha repos (deb.torproject.org) first appeared on 2018-05-23
I was about to submit a PR for the website to include it in the sources.list
generator [1] on tpo but didn't do it because I wanted to wait for a previous PR to be merged first.
The outstanding PR got merged eventually (2018-06-28) but I still did not submit a PR to
update the repo generator for 0.3.4.x nonetheless and here is why.

Recently I was wondering why are there so many relays running tor version 0.3.3.5-rc? (see OrNetStats or Relay Search)
(> 3.2% CW fraction)

Then I realized that this was the last version the tor-experimental-0.3.3.x-*
repos were shipping before they got abandoned due to the new 0.3.4.x-* repos
(I can no longer verify it since they got removed by now).

Peter made it clear in the past that the current way to
have per-major-version debian alpha repos (i.e. tor-experimental-0.3.4.x-jessie)
If you can't be bothered to change your sources.list once or twice a
year, then you probably should be running stable.
but maybe someone else would be willing to invoke a
"ln" commands everytime a new new alpha repo is born.

tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie

once 0.3.5.x repos are created the link would point to

tor-alpha-jessie -> tor-experimental-0.3.5.x-jessie


It is my opinion that this will help reduce the amount of relays running
outdated versions of tor.

It will certainly avoid having to update the tpo website, which isn't a big task
and could probably be automated but it isn't done currently.

"..but that would cause relay operators to jump from i.e. 0.3.3.x to 0.3.4.x alphas
(and break setups)!"
Yes, and I think that is better than relays stuck on an older version because
the former repo no longer exists and operators still can choose the old repos
which will not jump to newer major versions.



[1] https://www.torproject.org/docs/debian.html.en#ubuntu
[2] https://trac.torproject.org/projects/tor/ticket/14997#comment:3
[3] https://lists.torproject.org/pipermail/tor-relays/2018-June/015549.html
[4] https://trac.torproject.org/projects/tor/ticket/26474
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
Iain Learmonth
2018-07-01 14:57:05 UTC
Permalink
Hi,
Post by nusenu
but maybe someone else would be willing to invoke a
"ln" commands everytime a new new alpha repo is born.
tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie
As an alternative strategy, symbolic links for old alpha repositories
point to the current stable repository. If you're not updating your
sources.list you end up on the stable branch. I think this would mean
"less surprises" than jumping to a new alpha branch.

Thanks,
Iain.
teor
2018-07-03 05:49:47 UTC
Permalink
Signed PGP part
Hi,
Post by nusenu
but maybe someone else would be willing to invoke a
"ln" commands everytime a new new alpha repo is born.
tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie
But then operators get updated to a new major version when they’re not
expecting it. (We could document that if you select “alpha”, you should
expect to get breaking updates every so often.)
As an alternative strategy, symbolic links for old alpha repositories
point to the current stable repository. If you're not updating your
sources.list you end up on the stable branch. I think this would mean
"less surprises" than jumping to a new alpha branch.
I opened a ticket with the old experimental -> stable suggestion:
https://trac.torproject.org/projects/tor/ticket/26621

But what do we do with `tor-experimental-0.3.3.x-jessie -> jessie` when
0.3.4 is stable?

Delete it?
But then operators don't get updates.

Keep it?
But then operators get updated to a new major version when they’re not
expecting it.

Maybe there is no good solution to this problem.
What’s the least worse solution?

T
Peter Palfrader
2018-07-03 06:52:13 UTC
Permalink
Post by teor
Maybe there is no good solution to this problem.
What’s the least worse solution?
Stop shipping alpha versions where people can find them easily?
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `- https://www.debian.org/
Peter Palfrader
2018-07-03 06:51:38 UTC
Permalink
Post by Iain Learmonth
Hi,
Post by nusenu
but maybe someone else would be willing to invoke a
"ln" commands everytime a new new alpha repo is born.
tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie
As an alternative strategy, symbolic links for old alpha repositories
point to the current stable repository.
apt will complain if the Suite/Codename in the Release file doesn't
match what it expects. symlinks don't change anything.
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `- https://www.debian.org/
Peter Palfrader
2018-07-03 06:54:58 UTC
Permalink
Post by Peter Palfrader
Post by Iain Learmonth
Hi,
Post by nusenu
but maybe someone else would be willing to invoke a
"ln" commands everytime a new new alpha repo is born.
tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie
As an alternative strategy, symbolic links for old alpha repositories
point to the current stable repository.
apt will complain if the Suite/Codename in the Release file doesn't
match what it expects. symlinks don't change anything.
Also, jftr, users who have just the experimental sources.list entry
without the corresponding non-experimental one are already doing it
wrong, not following documented best practice.
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `- https://www.debian.org/
teor
2018-07-03 09:47:12 UTC
Permalink
Post by Peter Palfrader
Post by Peter Palfrader
Post by Iain Learmonth
Hi,
Post by nusenu
but maybe someone else would be willing to invoke a
"ln" commands everytime a new new alpha repo is born.
tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie
As an alternative strategy, symbolic links for old alpha repositories
point to the current stable repository.
apt will complain if the Suite/Codename in the Release file doesn't
match what it expects. symlinks don't change anything.
Also, jftr, users who have just the experimental sources.list entry
without the corresponding non-experimental one are already doing it
wrong, not following documented best practice.
The generator at:
https://www.torproject.org/docs/debian.html.en
creates lines for the alpha and stable series when the
alpha is selected. (And it creates nightly and stable for nightly.)

So relays automatically transition to stable once the alpha series
disappears. I've closed #26621, because we don't need to do
anything more.

T

Loading...