Hi,
Holger Wansing wrote (Wed, 14 Jun 2023 21:50:18 +0200):
> Paul Gevers wrote (Wed, 14 Jun 2023 21:19:00 +0200):
> > Also, on the topic of arch-specific builds, I not convinced it's worth a
> > lot of effort. The amount of arch specific pieces is rather limited, so
> > I wouldn't mind if we drop that altogether. Currently, we don't do a
> > great service to people that need to support multiple architectures,
> > because they need to *search* for the delta's, so I wouldn't be
> > surprised if it is even better if we drop it.
>
> From the technical side, I managed to get the arch-specific builds done in
> the meantime basically; so no problem anymore there - theoretically.
>
> On the other side, I also thought about the arch-specific differences, and
> given they are only rather small, my assumption was, that it's maybe not worth
> it to differentiate between archs, when it comes to filtering out content
> of r-n depending on the architecture.
> But even if we leave that point out, there are some arch-dependent links like
> http://mirrors.kernel.org/debian/dists/bookworm/main/binary-amd64/...
> in chapter 4.3.1
> https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#network
>
> So, we still need to build the release-notes differentiated by archs
> (based on the current content).
>
>
>
> However, that does not mean, we could not change our base rules, so that
> filtering out chapters based on architecture is no longer used.
> I would vote for this solution, yes.
Thinking a bit more about this, I wonder if we could indeed get rid of
architecture-dependent r-n at all.
If all paragraphs/chapters are visible for all archs anyway, there are
only two situations where the arch shortname (amd64, i386 etc.) is used
in URLs. That is in
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#network
and
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#localmirror
For example, suppose your closest Debian mirror is
http://mirrors.kernel.org.
If you inspect that mirror with a web browser, you will notice that the main
directories are organized like this:
http://mirrors.kernel.org/debian/dists/bookworm/main/binary-amd64/...
http://mirrors.kernel.org/debian/dists/bookworm/contrib/binary-amd64/...
To configure APT to use a given mirror, add a line like this (again,
assuming you are using main and contrib):
deb http://mirrors.kernel.org/debian bookworm main contrib
So, the arch-dependent directories on the mirrors are mentioned here, but the
arch part is not really relevant here. We could just skip the last part of
the URL and point to
http://mirrors.kernel.org/debian/dists/bookworm/main/..
and that's it. The same counts for the second occurrence of arch shortname.
That gives us the possibility, to simplify the whole r-n thing to only build
one generic release-notes variant for all archs, in the different languages,
and we are done.
How does that sound?
Holger
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
