Bug#959471: base-files: Support for parametrized files

2026-05-29 Thread Santiago Vila 
> > (BTW, I guess you do not manage this package under a VCS?)
> 
> Now that you do, I've updated and rebased the patch against your repo,
> and published the changes at:
> 
>   https://salsa.debian.org/guillem/base-files/-/commits/pu/parametrize

[...]

Hello Guillem.

This is still very intrusive and I still don't like it...

Last time I had to update base-files for a new release, the things
that had to be changed were done in their own commits, easy to
identify in the git history. I see that as an improvement over the
previous status, when all the changes were mixed in a single shot.

So, after base-files is finally in git, and for something which
is done once or twice every two years, I think this is not such
a big deal to justify the added complexity.

[ I'm still keeping the bug open in either case ]

Thanks.

Bug#959471: base-files: Support for parametrized files

2026-05-12 Thread Guillem Jover 
Hi!

On Sat, 2020-05-02 at 19:20:49 +0200, Guillem Jover wrote:
> Source: base-files
> Source-Version: 11
> Severity: wishlist
> Tags: patch

> This package requires both changes in Debian between freeze and
> non-freeze times, and also is one of the first ones that need
> modifications when creating a derivative.
> 
> To make handling both these cases, I've prepared the attached patch
> which tries to parametrize everything that is changed in Debian during
> the release cycle so that it's easier to maintain. And so that
> derivatives can have an easier time deriving too.
> 
> The new workflow for Debian would require only touching three variables
> in params/debian. For a derivative, it would require adding a new
> params/ file and changing the params/default symlink to point
> to that. This would massively reduce the amount of changes needed in
> derivatives, as seen in .
> 
> 
> I've tried to document all variables in params/debian so that they are
> easy to understand. I've also switched from #SUBST# to @SUBST@ as that
> works better within a Makefile.
> 
> 
> Let me know what you think, and whether you'd like to see anything
> changed?
> 
> (BTW, I guess you do not manage this package under a VCS?)

Now that you do, I've updated and rebased the patch against your repo,
and published the changes at:

  https://salsa.debian.org/guillem/base-files/-/commits/pu/parametrize

Which includes the main change, plus a couple of demonstration changes
to see how this could work during the Debian freeze, or for a derivative.
(These are not intended to be applied, just to make sure.)

I've tested the main change by creating .deb packages before and after
and running diffoscope on the reproducible output.

And I'm attaching the commits here for your convenience.

Thanks,
Guillem
From 60ff4b7736152c33c9c2fadef17649832672424f Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Wed, 13 May 2026 04:37:47 +0200
Subject: [PATCH 1/3] Parametrize files

This should help both Debian and its derivatives, as now all these
should be able to do most of the work by just adding a new params/
file and updating the params/default symlink. Without needing to
make sure no instance to replace gets missed.

We switch from #SUBST# to @SUBST@ as that works better within a
Makefile, except for substitutions handled natively by debhelper.
We use the builtin dpkg substvar vendor:Name where possible.

The intention here is that the only things that would normally need
changing would be under params/. For a derivative a new params file
would need to be added under params/ and the params/default symlink
updated.

The changes should produce the same reproducible .deb output before
and after, as can be checked with diffoscope.

Closes: #959471
---
 debian/README   | 10 +++---
 debian/base-files.dirs  |  1 +
 debian/base-files.docs  |  2 --
 debian/base-files.links |  1 -
 debian/control  |  8 ++---
 debian/copyright|  4 +--
 debian/gen-vendor.mk| 14 +
 debian/postinst |  4 +--
 debian/rules| 64 +-
 debian/timestamps   |  1 -
 etc/debian_version  |  1 -
 etc/issue   |  2 +-
 etc/issue.net   |  2 +-
 etc/os-release  | 17 +-
 origins/debian  |  3 --
 params/debian   | 69 +
 params/default  |  1 +
 share/dot.bashrc|  2 +-
 share/info.dir  |  2 +-
 share/motd  |  4 +--
 20 files changed, 170 insertions(+), 42 deletions(-)
 delete mode 100644 debian/base-files.docs
 create mode 100644 debian/gen-vendor.mk
 delete mode 100644 etc/debian_version
 delete mode 100644 origins/debian
 create mode 100644 params/debian
 create mode 12 params/default

diff --git a/debian/README b/debian/README
index 16c7427..d14823a 100644
--- a/debian/README
+++ b/debian/README
@@ -4,10 +4,10 @@ Frequently Asked Questions about base-files
 * Questions about /etc/issue and /etc/debian_version:
 
 Q. I upgraded my system to the testing distribution and now my /etc/issue
-says "forky/sid". Should it not read "forky" or "testing"?
+says "@OSCODENAME_TESTING@/sid". Should it not read "@OSCODENAME_TESTING@" or "testing"?
 
 Q. I upgraded my system to the unstable distribution and now my /etc/issue
-says "forky/sid". Should it not read "sid" or "unstable"?
+says "@OSCODENAME_TESTING@/sid". Should it not read "sid" or "unstable"?
 
 A. That would be nice, but it is not possible because of the way the
 testing distribution works. Packages uploaded for unstable reach
@@ -17,9 +17,9 @@ testing. You should consider the testing and unstable distributions as
 two sides of the same coin. Since the base-files package in testing
 was initially uploaded for unstable, the only sensible /etc/issue to
 have is one that is both valid for testing and unstable, hence
-"forky/sid" (or whatever is appropriate).
+"@OSCODENAME_TES

Bug#959471: base-files: Support for parametrized files

2020-05-02 Thread Guillem Jover 
Source: base-files
Source-Version: 11
Severity: wishlist
Tags: patch

Hi!

This package requires both changes in Debian between freeze and
non-freeze times, and also is one of the first ones that need
modifications when creating a derivative.

To make handling both these cases, I've prepared the attached patch
which tries to parametrize everything that is changed in Debian during
the release cycle so that it's easier to maintain. And so that
derivatives can have an easier time deriving too.

The new workflow for Debian would require only touching three variables
in params/debian. For a derivative, it would require adding a new
params/ file and changing the params/default symlink to point
to that. This would massively reduce the amount of changes needed in
derivatives, as seen in .


I've tried to document all variables in params/debian so that they are
easy to understand. I've also switched from #SUBST# to @SUBST@ as that
works better within a Makefile.


Let me know what you think, and whether you'd like to see anything
changed?

(BTW, I guess you do not manage this package under a VCS?)

Thanks,
Guillem
From f3bc14192d80a40c7376bced5e7af27f23de099c Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 19 Jan 2020 01:10:40 +0100
Subject: [PATCH] Parametrize files

This should help both Debian and its derivatives, as now all these
should be able to do most of the work by just adding a new params/
file and updating the params/default symlink.

We switch from #SUBST# to @SUBST@ as that works better within a
Makefile.

The intention here is that the only things that would normally need
changing would be under params/. For a derivative a new params file
would need to be added under params/ and the params/default symlink
updated.
---
 debian/README   | 10 ++---
 debian/base-files.dirs  |  1 +
 debian/base-files.docs  |  2 -
 debian/base-files.links |  1 -
 debian/clean|  1 +
 debian/control  |  8 ++--
 debian/copyright.in |  6 +--
 debian/current-md5sums-obsolete |  4 +-
 debian/gen-vendor.mk| 14 +++
 debian/postinst.in  |  4 +-
 debian/rules| 72 -
 etc/debian_version  |  1 -
 etc/issue   |  2 +-
 etc/issue.net   |  2 +-
 etc/os-release  | 16 +---
 origins/debian  |  3 --
 params/debian   | 68 +++
 params/default  |  1 +
 share/dot.bashrc|  2 +-
 share/info.dir  |  2 +-
 share/motd  |  4 +-
 21 files changed, 180 insertions(+), 44 deletions(-)
 delete mode 100644 debian/base-files.docs
 create mode 100644 debian/gen-vendor.mk
 delete mode 100644 etc/debian_version
 delete mode 100644 origins/debian
 create mode 100644 params/debian
 create mode 12 params/default

diff --git a/debian/README b/debian/README
index 1618655..5a51013 100644
--- a/debian/README
+++ b/debian/README
@@ -4,10 +4,10 @@ Frequently Asked Questions about base-files
 * Questions about /etc/issue and /etc/debian_version:
 
 Q. I upgraded my system to the testing distribution and now my /etc/issue
-says "bullseye/sid". Should it not read "bullseye" or "testing"?
+says "@OSCODENAME_TESTING@/sid". Should it not read "@OSCODENAME_TESTING@" or "testing"?
 
 Q. I upgraded my system to the unstable distribution and now my /etc/issue
-says "bullseye/sid". Should it not read "sid" or "unstable"?
+says "@OSCODENAME_TESTING@/sid". Should it not read "sid" or "unstable"?
 
 A. That would be nice, but it is not possible because of the way the
 testing distribution works. Packages uploaded for unstable reach
@@ -17,9 +17,9 @@ testing. You should consider the testing and unstable distributions as
 two sides of the same coin. Since the base-files package in testing
 was initially uploaded for unstable, the only sensible /etc/issue to
 have is one that is both valid for testing and unstable, hence
-"bullseye/sid" (or whatever is appropriate).
+"@OSCODENAME_TESTING@/sid" (or whatever is appropriate).
 
-Q. Why "bullseye/sid" and not "testing/unstable" as it used to be?
+Q. Why "@OSCODENAME_TESTING@/sid" and not "testing/unstable" as it used to be?
 
 A. The codename is a little bit more informative, as the meaning of
 "testing" changes over time.
@@ -31,7 +31,7 @@ not a reliable way to know that anymore. Looking at the contents of
 your /etc/apt/sources.list file is probably a much better way.
 
 Q. There is a new point release and I've just upgraded my system.
-The /etc/debian_version file now says 10.x but /etc/issue still says 10.
+The /etc/debian_version file now says @[email protected] but /etc/issue still says @OSVERSION_ID_STABLE@.
 Is this ok?
 
 A. Yes. The release managers asked me not to touch /etc/issue, as that's
diff --git a/debian/