Add support for deb822 APT sources

[jps-help]

Summary

Adds a new defined type, apt::source_deb822, and corresponding EPP template for managing deb822 APT sources.

Works alongside the existing apt::source type.

TO DO

• Currently only supports specifying 'Signed-By' as a space-separated list of absolute file paths, but the deb822 spec also allows for writing the GPG ASCII armored key in-line with the .sources file.
• Unlike the existing apt::source type, doesn't currently support generating associated apt::keyring resources. Need to be created separately.
• Proper spec tests.

Additional Context

• deb822 APT sources have been supported by APT since v1.1
• Ubuntu 24.04 will ship with the Ubuntu repo configured in the newer deb822 style
• This module doesn't currently have a method for managing deb822 .sources files

Related Issues (if any)

Mention any related issues or pull requests.

Checklist

• [ ] 🟢 Spec tests.
• [ ] 🟢 Acceptance tests.
• [x] Manually verified. (For example puppet apply)

[jps-help]

Inline ASCII GPG keys are still not working, but not necessary for an initial implementation.

Same with generating apt::keyring resources from within the apt::source_deb822 resource. But I don't really think this is necessary at all since you can just create the keyring resource separately.

Spec tests are done.

I'm happy with the state of this PR. Happy to hear people's thoughts/suggestions.

[bastelfreak]

@jps-help thanks for the PR! Can you please rebase against main to get rid of the merge commit?

[jamesps-ebi]

@jps-help thanks for the PR! Can you please rebase against main to get rid of the merge commit?

The fork has been rebased. Should be good to go.

[jamesps-ebi]

Woops... I have accidentally reset my fork force pushed while testing another PR.

Luckily I still have my original deb822 branch. I'll fix and push again.

[jps-help]

What exactly is your reason to add an additional resource instead of extending the apt::source resource

I think the main reason is just because of how different the two styles are. If you look at the current apt::source, many of the parameters take a single value, whereas, with deb822 parameters like suites and components can accept an array of values. Sure we could just have one .sources file per suite or component of a repo, like with the current method, but I think it defeats the purpose of the newer deb822 style.

There might be a way we can extend the current type, I'm open to suggestions. My main focus was simply to add the new functionality without breaking the existing type at all.

[rrotter]

I'd suggest keeping this under apt::source for several reasons:

• apt::source_deb822 would be a good name if this was an experimental interface, but deb822 is not "another way" it's the "new way", and (I think) will eventually be the only way. It should be presented as the default rather than an alternative, and especially not an alternative with a longer snake_cased_name.
• Having two resource types makes deleting sources worse. Imagine needing code like:

  apt::source_deb822 { 'testing123': ensure => 'absent' }
  apt::source { 'testing123': ensure => 'absent' }

• complicates migration: ideally upgrading to deb822 would be a one-line change to an existing apt::source; like adding 'type' => 'deb822' or better still a zero-line change like omitting 'type' => 'legacy' this latter suggestion would probably need to wait for a major release since it's a breaking change)

There might be a way we can extend the current type, I'm open to suggestions.

Indeed, I'd suggest adding an Enum['legacy','deb822'] that probably defaults to 'legacy' for now. I like the idea of using the modern names for the fields (suites vs release, etc), but we could have both, and have one be an alias for the other. Could accept either an array or a string in the new name and continue accepting only a string in the old field name. That way there's the option of taking advantage of everything new that deb822 offers, but also the option of just switching over with at little change as possible.

edit: also, using any of the new field names should implicitly force deb822, and trying to combine the new fields with the legacy source would be an error. See the handling of keyrings in the apt::source: key field for an example.

[jps-help]

@rrotter All very good points. Let me take this back to the drawing board and try to implement with all these suggestions.

I think we will need a lot of new logic to handle the switch between the two versions, but in the end hopefully will be a better experience!

[jps-help]

Okay... I have merged some new changes that integrate the deb822 functionality into the existing apt::source type.

This is very much a work-in-progress and has several points to consider:

• I made the decision to add new parameter names for deb822 resources so they match with the content of the actual .sources file. This allows us to use different data types for those where appropriate.
• We might be able to allow an easy transition if we can find a way to have the new parameters use the old parameters as default values. I played with this but didn't implement because I found a few issues with that.
• Maintainers need to decide on the appropriate way to deprecate the existing method. Currently this change leaves the default as the current method. I tested a resource created using the current forge version, then upgrading to this version and saw no changes to the resource.
• I added a switch source_format which controls this behaviour. The default is 'legacy', and the new format is 'deb822' but maybe this should be 'list' and 'sources'? Or are we assuming there won't be any major change to apt sources for a long time?

Comments are greatly appreciated.

TLDR; I used a case statement to separate the functionality and added a new Enum parameter to control it.

Also I left the separate manifest for apt::source_deb822 but can clean that up later.