Skip to content

Conversation

@benaryorg
Copy link

@benaryorg benaryorg commented Oct 30, 2025

Technically this also adds Ubuntu support but I have not tested that one
at all. Using this on Debian works as expected given the code is
basically copied over from the rpm section with suffixes changed. At
time of writing it does not seem like Debian has any tool similar to
this despite having feature requests for something similar from at least
2001.


Above is the commit message verbatim.

Several notes which don't really fit into the commit message:

  • An unsigned sample .deb file for testing is available from my CI (source for the .deb (IPv6-only)).
  • I'm not using Debian (or any other dpkg based distro) myself, so I won't be packaging this at a wider scope.
    • If anyone else wants to package this, I want to thoroughly encourage you to do so.
  • Not sure whether other distros should be added to the OS_FAMILY section, suggestions welcome.
  • Similarly, if the inclusion of /etc/default/etc-update doesn't make sense, please say something.
  • As a former long-time Gentoo user, a general heartfelt Thanks to everyone!

off-topic meta

And a small aside which is absolutely out of scope for this PR, but I just happened to notice; ./DEVELOPING states:

The headline should be capped at 70 characters, the detailed text at 72.

Personally I'd suggest uncapping the detailed commit message body line width (not the headline tho!) unless there is an actual technical blocker.
Basically every tool I know does proper line-breaks, and making modifications in the middle of the text won't require having to re-pack (vim's gq for instance) again afterwards.
IMHO it just looks cleaner if you're already using a similar text formatting to mine.

I don't want to invite a discussion within this PR about this however, just throwing it out there.

@benaryorg
Copy link
Author

Ah, I see.
The runner is dpkg based and the tests thus far relied on that not being handled so it would fallback to assuming it was Gentoo.…

There currently isn't a way to override the etc-update behaviour, so the two options would really be:

  • overwrite /etc/os-release within the runner (not pretty, and might break other things)
  • add an override, such as an ETC_UPDATE_OS_FAMILY envvar overriding the check if present

I'll opt for the latter and push a commit for fixing this.

@benaryorg
Copy link
Author

The man-page currently doesn't include a mention of the os-release handling, and the flag is highly specific for the CI, so I don't know whether it warrants adding this to the man-page but I can certainly do so if this is considered appropriate.

This allows tests on CI runners to run the *etc-update* tests for
arbitrary target distributions.

Signed-off-by: benaryorg <[email protected]>
Technically this also adds Ubuntu support but I have not tested that one
at all. Using this on Debian works as expected given the code is
basically copied over from the *rpm* section with suffixes changed. At
time of writing it does not seem like Debian has any tool similar to
this despite having feature requests for something similar from at least
2001.

Signed-off-by: benaryorg <[email protected]>
@benaryorg
Copy link
Author

Oh damn, I only saw the thumbs up reactions and assumed this was meant as a "please add something to the man-page", and totally overlooked the existing approval.
Since the last push the man-page now has some information on the detection.
(I also swapped the commits around so that each commit individually does pass all the tests rather than chronologically breaking and then fixing them)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants