Add support for Debian repos and new versioned repo structure.

[olifre]

This PR adds two features:

• Initial support for Debian and Ubuntu. Just adding the repositories is sufficient. We are using at least schedds on Ubuntu successfully. This adds puppetlabs/apt as a dependency.
• Adapting to the new repository structure of HTCondor.

HTCondor restructured their repositories with 8.8 from the old previous / stable / development to versioned subdirectories. This means updates are significantly less surprising as compared to the past workflow when stable contained 8.4 and was suddenly replaced by 8.6 over night.

For backwards compatibility, the flag versioned_repositories is false by default, and the "old" repositories are still used. To accomodate the new URLs, condor_major_version (defaulting to 8.8 which is the first version in a versioned repository) can be set.

Things are still a bit awkward upstream, i.e. 8.7 is not versioned yet, so dev_repositories still has some relevance. For Debian / Ubuntu, though, I only implemented the versioned_repositories and from the repository path, the notion of stable and development is gone there since that's essentially contained in 8.7 or 8.8.

[kreczko]

@olifre sorry for the delays seems that I am the only one left that still merges.

Would you be interested in elevated permissions for this repo? I've just added automated deployment to PuppetForge so only PRs & tags need to be taken care off.

[olifre]

Would you be interested in elevated permissions for this repo? I've just added automated deployment to PuppetForge so only PRs & tags need to be taken care off.

Took me a long time to answer here... Even though my time is also very limited and I only get to open PRs if we need something which is missing, I think it would be helpful to be allowed to merge PRs since it might reduce load on you. However, I also a strong fan of having a second pair of eyes checking code before it goes in, and since (often) most PRs are by myself, this rule would be violated 😉. That's what's making me unsure about it.

So after the automation, you basically only have to commit 7062f1f and everything happens automatically?
Is the changelog entry / commit message (partially) autogenerated with some tooling, or done manually?

[kreczko]

However, I also a strong fan of having a second pair of eyes checking code before it goes in, and since (often) most PRs are by myself, this rule would be violated wink. That's what's making me unsure about it.

That's very good :). I was not implying to merge your own PRs, just the others, e.g. from @ccnifo .
Ideally, I would like to add @ccnifo to the maintainers as well, if they are interested.

So after the automation, you basically only have to commit 7062f1f and everything happens automatically?
Is the changelog entry / commit message (partially) autogenerated with some tooling, or done manually?

A new release can be created by

export RELEASE=X.Y.Z
export CHANGELOG_GITHUB_TOKEN=<your github token> # for creating the changelog
make release

make release will update the version number in the relevant places, run github_changelog_generator and printout a set of git commands that need to be run:

"Check everything and if OK, execute"
git add -u
git commit -m "tagged version ${RELEASE}"
git push upstream master
git tag v${RELEASE}
git push upstream v${RELEASE}

with $RELEASE filled in.

Some of this is available in the README, if more clarity is required I can add it there.

[olifre]

I was not implying to merge your own PRs, just the others, e.g. from @ccnifo . Ideally, I would like to add @ccnifo to the maintainers as well, if they are interested.

Perfect - then I'm all for it! 👍

I did indeed completely miss the Makefile. Yes, that fully explains it ;-). Thanks!