Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Support for NotAutomatic/ButAutomaticUpgrades headers in Debian feed Release files
-
Hello Inedo Support/Product Team,
I would like to request an enhancement for ProGet’s Debian feeds: the ability to configure and emit the standard APT “suite behavior” headers in the generated Release/InRelease files, specifically:
NotAutomatic
ButAutomaticUpgradesUse case
We operate Debian feeds in ProGet and would like to offer a “backports” for distribution. we are using these headers to prevent unintended mass upgrades from that suite, while still allowing automatic upgrades for packages that were explicitly installed from it. This is important to safely expose newer versions without clients accidentally upgrading large parts of their systems.If this option already exists to set these headers, how can I implement it?
Best regards
-
Hi @geraldizo_0690,
Hello,
I'm not all that familiar with Debian/APT... but I briefly researched this, and it seems like this involves adding values like this at the top of the
Releasefile like this:NotAutomatic: yes ButAutomaticUpgrades: yesIs that it really? And this setting would impact the entire feed... but have no real relation/impact to connectors or packages?
If that's the case, how would you envision configuring this? I'm thinking on the Feed Properties page, but perhaps as a checkbox? How do other products/tools do it in your experience?
Thanks,
Steve
-
Yes. These headers are set at the beginning of the Release files before they are signed.
For example:Origin: Debian Backports Label: Debian Backports Suite: oldstable-backports Codename: bookworm-backports Changelogs: https://metadata.ftp-master.debian.org/changelogs/@CHANGEPATH@_changelog Date: Thu, 08 Jan 2026 20:25:04 UTC Valid-Until: Thu, 15 Jan 2026 20:25:04 UTC NotAutomatic: yes ButAutomaticUpgrades: yes Acquire-By-Hash: yes No-Support-for-Architecture-all: Packages Architectures: all amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x Components: main contrib non-free-firmware non-free Description: Debian bookworm - Backports SHA256: 74f76b59db4f4eff71484ba88d926cbfe9fb98e10f20688ed897e6402e68830a 392369 contrib/Contents-allI would recommend providing this capability when creating a Debian connector.
Ultimately, it only affects the Release files. The feeds and the connectors themselves are not affected by it and it has no impact in their functionality. For example, the Components header is already provided there as well.The only impact is on the clients via APT. With these metadata, APT would be configured regarding how it should install or upgrade packages.
The possible headers / metadata fields can be found here:
https://manpages.debian.org/unstable/apt-utils/apt-ftparchive.1.en.html (in release section)The attached image shows what such a capability could look like:

-
Hi @geraldizo_0690,
Thanks for the pointers -- now as an FYI, these settings would have to be a Feed-level setting, but the drop-downs would be the same.
FYI, here's the code we use to generate the Release file --- I'm not sure what those other header values do, but we probably wouold just want to add the two you suggested.
What do you think?
I suspect this will be a quick, opt-in change!
private void WriteReleaseFile(Stream output) { using var writer = new StreamWriter(output, InedoLib.UTF8Encoding, leaveOpen: true) { NewLine = "\n" }; writer.WriteLine($"Suite: {this.Distro}"); writer.WriteLine($"Codename: {this.Distro}"); writer.WriteLine(FormattableString.Invariant($"Date: {this.Generated:ddd', 'dd' 'MMM' 'yyyy' 'HH':'mm':'ss' UTC'}")); // NotAutomatic: yes <-- add here // ButAutomaticUpgrades: yes <-- add here writer.WriteLine($"Architectures: {string.Join(' ', this.indexes.Select(i => i.Architecture).Distinct(StringComparer.OrdinalIgnoreCase))}"); writer.WriteLine($"Components: {string.Join(' ', this.indexes.Select(i => i.Component).Distinct(StringComparer.OrdinalIgnoreCase))}"); var desc = FeedCache.GetFeed(this.feedId)?.Feed_Description; if (!string.IsNullOrWhiteSpace(desc)) writer.WriteLine($"Description: {desc.ReplaceLineEndings(" ")}"); writeHashes("MD5Sum:", i => i.MD5); writeHashes("SHA1:", i => i.SHA1); writeHashes("SHA256:", i => i.SHA256); writeHashes("SHA512:", i => i.SHA512); void writeHashes(string name, Func<IndexHashData, byte[]> getHash) { writer.WriteLine(name); foreach (var i in this.indexes) { writer.WriteLine($" {Convert.ToHexString(getHash(i.Uncompressed)).ToLowerInvariant()} {i.Uncompressed.Length,16} {i.Component}/binary-{i.Architecture}/Packages") writer.WriteLine($" {Convert.ToHexString(getHash(i.GZip)).ToLowerInvariant()} {i.GZip.Length,16} {i.Component}/binary-{i.Architecture}/Packages.gz"); } } }
-
Thank you very much for considering my request. I truly appreciate the time and attention you’ve given to review it. Your willingness to listen to user feedback means a lot, and I’m grateful that this suggestion has been taken into account.
-
Hi @geraldizo_0690 ,
Thanks! And we appreciate your ideas/suggestion and detailed guidance on how to implement it.
It seems really simple and should be available in the upcoming maintenance release (next Friday) via PG-3196 -- we can also let you know when a prerelease is available if you wanted to try it sooner than that.
Cheers,
Alana