Re: [HTCondor-users] HTCondor 8.8.6 Released

[Steffen Grunewald <steffen.grunewald@xxxxxxxxxx>]

Hello Tim,

On Tue, 2019-11-19 at 22:00:13 +0000, Tim Theisen wrote:
> Thank you for the feedback Steffen.
> 
> How do other projects handle the version number such that a dist upgrade
> will pull new packages that match the rest of the system. Do you have an
> example or document that you could point to?

Most projects I'm aware are either Debian-agnostic (IOW they don't care too
much about packaging), or follow the "Big Debian" approach, submitting to
unstable. (The best docs I've found for this are the usual suspects, both
Debian's official guides and the - old but still valuable - Krafft book.)
More below (as I understand it - I've never tried to become a DM or DD myself).

> The Debian Jessie package is being built using CPack (not the Debian
> build tools). We have no desire to change this since jessie is close to
> end-of-life and we have limited effort available.

I was just wondering, because without an extra build-dep on python3-all-dev
I couldn't build Jessie packages from source (but after adding that, all is
fine - even though the error message looked rather unrelated).
But you're right, Jessie is very outdated now, and I've thought about
abandoning it (and its package builders) multiple times. It's just a nice
exercise that doesn't require much extra effort but can teach me a lot.

> I am working on getting HTCondor back into sid and this work will
> resolve the issues building on bullseye.

This would be the "Big Debian" way - and packages submitted to the official
repository would live without any extra version tags.
Older distros (Buster, Stretch) would have to receive backports.
That is, for version 8.8.7 to come, you'd provide 8.8.7-1 to unstable (which
would migrate to testing/Bullseye after a few days, depending on the urgency).
So Bullseye would have its proper, original version.
A Buster version would have to be versioned "before" that - by naming it
8.8.7-1~bpo10+1, Stretch would be -1~bpo9+1, etc.
(Regarding the bp* string: "bpo" has been agreed on for official backports,
while inofficial ones may use anything that sorts before thta string; I'm
preferring "bp" for my own backports, which may later be overridden either
by an official one, or by a dist-upgrade. And yes, ~bpo10 sorts after ~bpo9
but before the empty string.)
While backporting, over-ambitious dependencies or compatibility levels may
become showstoppers, so please be careful with those.

LSC software is often written on a random platform, thus I may have to create
individual versions (by adding a "+deb10u0" suffix to the build number).
This currently applies to "my" HTCondor builds in general, too, although you
currently provide original tarballs that support both Stretch and Buster -
the result are individual (and properly upgradeable) builds.

I'm curious how you'd support a Python3-only Bullseye (the transition is
still ongoing, and I presume you'll want to wait for it to be finished before
putting too much effort in a proper source package to upload to Big D?)


Hoping that this hasn't produced too big a confusion,

cheers, Steffen


-- 
Steffen Grunewald, Cluster Administrator
Max Planck Institute for Gravitational Physics (Albert Einstein Institute)
Am Mühlenberg 1 * D-14476 Potsdam-Golm * Germany
~~~
Fon: +49-331-567 7274
Mail: steffen.grunewald(at)aei.mpg.de
~~~