On Thu, 19 May 2016 11:46:53 -0400
Paul Tagliamonte <paultag@debian.org> wrote:
> [cc'ing devel, since this is a rant that involves technical topics,
> and god knows I only go on so many rants a year these days]
First off, I have gone down the road of trying to setup apt sources in
from the install of another package. It's messy and I've moved to a
simple policy (as upstream): document it, recommend it and tell users
they are expected to do it - themselves. It's a one-off cost and is
easy to setup across large install bases with tools like salt, ansible
and puppet etc.
> > Sometimes there is good reason their
> > package doesn't belong in Debian but sometimes it is more about
> > inertia in Debian or the upstream isn't aware about backports and
> > thinks their package will be stuck at a particular version forever
>
> Frankly, I have a hell of a lot of sympathy for this.
>
> Backports are a whole thing. People have to be actively aware of them.
> Users have to be told to add a new thing in the sources by hand, and
> install something explicitly. It's calories, and explaining a Debian
> process to a user isn't fun. Why would upstreams want to do this?
Because it helps them? This is particularly true when the package
(and/or dependencies need Architecture: any support or where the
dependency chain is anything more than 1 level deep or wide.
> My claim, as I'll outline below, is, if the upstream wants to give the
> user an up-to-date software package, and they have to teach them how
> to add a new archive, they'll give them an archive *they control*,
> because they're now on the hook for delivering through that channel.
> Upstream wants to spend as little time as they can with this, so they
> make it easy - they make a deb.
Except in the case you describe below, that is not easy because
the .deb becomes a chain of .debs to cover all the dependencies.
> Backports are present when a package is in testing, and backports are
> a single channel. Backports are not for upstream's releases, whenever
> they want to ship a thing.
? I backport upstream releases all the time. As soon as the package is
in testing. I do this because I have users who expect to get the new
release from backports - principally because that's what upstream have
*taught* the users to expect.
There is a channel that is used internally and is offered to others but
the recommendation is to use backports. That channel requires adding a
key to apt - that is actually sufficient to get most people looking at
backports instead.
> We have zero procedure in place for the following:
>
> - Totally unsupported very old version of ${FOO} in stable,
> maintainer isn't patching bugs, bugs are going to upstream, and
> upstream is annoyed Debian has out of date, perhaps insecure thing X.
He who does the backport does the backports of dependencies or the
backport won't be accepted. Once a backport is through backports-NEW,
updating it is not hard. If the first-in-line maintainer isn't active,
then those who depend on the package have to step up. That's the point
enforced by auto-removals. Fix package F or your package A will be
auto-removed due to the chain A, B, C, D, E and F.
Now it could be easier, as I've just found, to use sbuild to create
backports which build-depend on other backports without having to
change the build-dep-resolver but it's all do-able.
> - Leaf package ${BAR} has a robust upstream community, where
> releases are very well tested, with a mature stable/unstable release
> cycle. Our stable release freeze was off by a few months, so we've
> been shipping their 'oldstable' in our 'stable' for years. The
> maintainers are annoyed we don't use the latest stable in our
> stable.
LEAF does the work of getting the dependencies in a fit state and then
does the backport and tells users to use it.
It's the same amount of work overall.
> Largely, I think the first situation is a common one that our culture
> has forced people to group-think "Well, that's bad and the system is
> working as intended". We can't let software change on our stable
> installs, so this situation is bad, but the intent of stable.
Part of the benefit of stable is to have most of the packages stable,
get security and important updates as part of stable and then
cherry-pick from backports for the few packages that are the
"frontline" packages of that box.
> The second one is harder to say that with, since upstream is making
> assertions (just as strong as us) on some things. Be it protocol
> stability, API stability, or whatever.
>
> We're mostly approximating #2 by stacking up patches from their next
> stable, and applying them to our stable. We're basically shipping the
> new version with the old version number, without as much testing as
> the real version, and only confusing ourselves (patches are a bitch),
> users (I have version 1.2), and upstreams (why doesn't Debian trust
> the release process), causing tension everywhere. Look at OpenSSL,
> it's nuts. (God bless the OpenSSL team for doing this, and finding a
> way to keep DDs happy -- or rather -- merely quiet, as well as
> upstreams and users).
>
> So, your question, why do people try to make it easy to get the latest
> stable software is answered simply with "because we're not". We are
> the problem. No one wants to do this. Maintianing an archive sucks.
> No one wants to maintain a Debian archive. It's just the least work
> to deliver something supportable and maintainable to users.
However, as soon as it becomes more complex than my package A depends
on some out of date package B then an archive becomes essential.
> Go to any mature project, they have a way to bypas the archive, and
> get the latest stable from upstream. This is a huge failure. Upstreams
> aren't becoming DDs and updating packages, dispite the fact they can
> package and maintain things.
>
> Hell, teams packaging Mozilla-soft and PostgreSQL are DDs maintaining
> *external archives* because it's easier.
>
> The issue is, we have a model of software delivery that's slowly
> growing more and more distant from the realities of shipping software
> today. Why is this? What can we do? What do our users want? What do
> our users *expect*?
As long as upstream are positive about telling users what method to
use, it doesn't really matter to users in many cases.
I'm in favour of expecting maintainers to do more updating and less
ITPs. It's depressing the constant stream of random fluff coming
through as ITPs when the work that users and upstreams want to see
happen is *updates*. That doesn't just mean doing uscan && uupdate &&
debuild && dput. It means managing the dependencies, getting backports
in order and keeping on top of the auto-removals.
> Making it hard to install a new archive will only lead to more
> workarounds, more FAQs telling users to dismiss warnings, and more
> upstreams hell-bent on working against us, because we keep making
> their lives harder.
Why is backports seen as a new archive? It's part of the archive, it's
not separate. Backports that aren't up to being in the archive should
be replaced but backports are a respectable part of the archive and
should be seen as such across Debian.
There should be no place for users worrying about whether it is "safe"
or "wise" to add backports and install packages from backports.
Packages which may have a history that has caused such reactions need
to be brought in line.
> This is a 100% larger conversation, and it's not about a hacky deb,
> it's about how our place in the software ecosystem has been evolving,
> and we need to evolve with it, or we'll find ourselves part of the
> problem we were trying to solve in the first place.
Work with upstream to persuade them that we can get our own house in
order and get updates of the dependencies they need into backports so
that their stable releases can also go into backports.
Stop packaging so much new stuff and fix more of the stuff we've been
collectively ignoring because legacy packaging is hard to fix.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Attachment:
pgpuKNMbSRByT.pgp
Description: OpenPGP digital signature