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) will not change [2]:
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
Hi,
On 30/06/18 15:42, nusenu wrote:
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.
On 2 Jul 2018, at 00:57, Iain Learmonth irl@torproject.org wrote:
Signed PGP part Hi,
On 30/06/18 15:42, nusenu wrote:
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
On Tue, 03 Jul 2018, teor wrote:
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?
On Sun, 01 Jul 2018, Iain Learmonth wrote:
Hi,
On 30/06/18 15:42, nusenu wrote:
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.
On Tue, 03 Jul 2018, Peter Palfrader wrote:
On Sun, 01 Jul 2018, Iain Learmonth wrote:
Hi,
On 30/06/18 15:42, nusenu wrote:
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.
On 3 Jul 2018, at 16:54, Peter Palfrader weasel@torproject.org wrote:
On Tue, 03 Jul 2018, Peter Palfrader wrote:
On Sun, 01 Jul 2018, Iain Learmonth wrote:
Hi,
On 30/06/18 15:42, nusenu wrote: 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
looks like someone decided to solve this.
apparently there are alpha release repos available now that do not contain branch names
https://deb.torproject.org/torproject.org/dists/:
[DIR] tor-experimental-bookworm/ 2021-12-20 22:21 - [DIR] tor-experimental-bullseye/ 2021-12-20 22:21 - [DIR] tor-experimental-buster/ 2021-12-20 22:21 - [DIR] tor-experimental-focal/ 2021-12-20 22:21 - [...]
thank you! nusenu
-
Iain Learmonth -
nusenu -
Peter Palfrader -
teor