Le jeudi, 6 décembre 2018, 19.03:57 h CET Paul Elliott a écrit :
> You guys must be developing under sid, and never checking that your
> releases will actually build under the various stable releases.
Exactly. And it allows removing _a lot_ of unneeded complexity. As hplip
packager, I provide new upstream releases tailored towards the _next_ stable
release. The "staging" area for this is `unstable`. It will then migrate to
`testing` (aka `buster`).
Backporting these new upstream releases is a _different_ and _additional_
work. There's absolutely zero requirement for packages uploaded to `unstable`
to build without modifications on other releases.
> But your branches are still named for the various stable versions,
> that is, debian/stretch-backports, debian/stretch, debian/jessie-backports,
> debian/jessie.
Yes. These build on the corresponding target suites. They don't necessarily
integrate the latest upstream releases (nor should they).
> But you never check that these commits will actually build for these
> versions.
No, we don't. Doing so would be _a lot_ of unneeded work.
But upon request, packages can be adapted to target specific suites; that's
precisely what *-backports suites are. That's why I uploaded a _modified_
hplip 3.18.10+dfsg0-3 to the `stretch-backports` suite. That upload was
accepted today and is in the process of being built for all architectures.
https://buildd.debian.org/status/package.php?p=hplip&suite=stretch-backports
Stretch users will be able to get the latest hplip by using the `stretch-
backports` suite additionally to their standard APT setup.
Cheers,
OdyXAttachment:
signature.asc
Description: This is a digitally signed message part.