Re: stable update of dpkg (>= 1.17.2) and apt (>= 0.9.16.1) for build profiles
Hi!
On Thu, 2014-05-01 at 12:35:19 +0200, Philipp Kern wrote:
> On Thu, May 01, 2014 at 05:29:39AM +0200, Guillem Jover wrote:
> > Much of our infrastructure code comes from unpackaged projects (?),
> > which makes this an awkward requirement, I guess it's the price of
> > reusing existing packaged code by the unpackaged projects. :/
>
> There is a general problem that you want to make changes and you have
> only one live host where the software is primarily run. Or it does
> not support upgrades properly. (Sort of true for wanna-build; even
> though there are people trying to run it separately — like d-p.o —,
> but it is painful.)
>
> For sbuild and buildd, they are actually packaged and available on
> https://buildd.debian.org/apt/ but they are forked because we need to
> be able to be on a stable codebase and be able to make changes
> quickly on top of that. Maintenance of buildd in unstable is tied to
> sbuild and stuff tended to break too often. It's hard to tie our
> cycle to backports which relies on testing migration of newer versions
> in unstable that were never even smoke-tested for our use. It's kind of
> a chicken-egg problem on how to bootstrap package use in absence of
> regression tests. I'd be very nice but I don't see how that'd work with
> the kind of policies we have. Any urgent change would still require a
> repo to push from to all the buildds, for instance.
Ah yeah, when I wrote unpackaged, please read not packaged in the
official suites. And don't get me wrong, I see why the policies and
update origins need to be different (between the more conservative
stable updates and the more dynamic infra changes), it's just that it
seems awkward when they clash because the latter makes use of code
from the former. On the other hand going back to duplicating all that
code does not look like a good way forward either.
> > In this case one would have expected to be able to use build profiles
> > right away after the required infra changes (at least I think it
> > would have been possible in the past?), because they don't affect the
> > dist-upgrade path, but it seems there's new restricting factors now.
>
> I don't think the requirements for stable updates were any more lax in
> the past (in fact they were much stricter), or that people were more
> tolerant to do incompatible changes. There was, as far back as I
> remember, always the notion that things need to land in stable before
> they can be used.
Oh, sorry, what I meant was that because my impression is that less
stuff used to rely on packages coming from the official suites, it was
easier to update the code for this kind of things, due to the possibly
different policies. For example I don't think dak used to rely on
lintian long time ago (?). But perhaps my impression is wrong, and
now that I think about it, each and every change to the source side
of things have always also required a release cycle, AFAIR.
(As an aside, I actually also think the requirements for stable updates
are a bit more lax today than they used to be, in the good way though,
not in the sloppy or intrusive changes way.)
> dist-upgrade path was a primary motivator, but handling of packages,
> even source packages, with stable tooling, was as important. See things
> like xz compression where we also needed to wait.
Right, or the new source package formats.
In any case let me (at least try to) be as much clear as possible,
I'm actually a bit conflicted about this myself.
On one hand I think it would be nice to be able to start deploying
this kind of changes in a faster way, as long as the changes are not
too intrusive or scary, or have very exhaustive test coverage.
On the other hand, I appreciate and I guess I've internalized somewhat
the model of stable is stable, so no new big features or intrusive
changes, which has a very nice appeal to it, and I would by default not
leave that mental model if it was not for reasoned external requests.
Also one of the prices of native packages is that they are bound to the
release criteria of the distribution and its “distribution channel”,
even if otherwise their release criteria as a project could include
the possibility for targetted feature backports and similar, or
extended maintenance of old branches, for example. But then the most
relevant “distribution channel” and environment for a native package
is the distribution itself, so…
Anyway, as it still is not entirely clear to me if the release team
would be fine with such backport, and I can be easily swayed either
way, I'll drop the exercise here, until further state changes.
Thanks,
Guillem
Reply to: