Re: third-party packages adding apt sources
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, May 19, 2016 at 11:46:53AM -0400, Paul Tagliamonte 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]
You didn't actually do this.
> > 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.
So do I, but I disagree with your solution. Here's how I see it:
Debian stable is for users who want a rock solid system. It is out of date by
the nature of how it is built. Users who want to get the newest versions of
their software should not be running stable; testing is probably better for
them.
When programs get packaged outside of unstable, we should look at why that
happens, and try to convince the packager to do it inside Debian instead.
(This convincing may take the form of adding features to our system that solve
their problems.)
When users or upstreams complain that the version in stable isn't up to date,
we should explain to the users that they probably want to use testing. If this
is a common problem for upstreams, our user documentation about this is not
sufficiently clear.
When users want to run stable with one or two packages cherry-picked from
backports, that is something which we may want to make easier for them.
> 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?
Agreed, we should make this easier; allow DDs and the package uploader to
trigger building a backport for any package that is in testing by sending an
e-mail, perhaps?
And aside from that, I agree that it should be easier to install a system that
includes backports in the sources.list.
> 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.
Yes. I do this myself for some experimental packages that I don't consider
ready for the general public yet. That is IMO a valid reason for having a
private repository. "Doing it right is too hard" is not; that is something we
should fix.
> 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.
If we make it easy for them to become DDs or DMs and for uploaders to trigger
backports builds, backports can be what upstream wants.
> 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.
Yes, this is a different problem. We may want to shield upstream from
bugreports for those packages somehow.
IMO it would be good to recommend our users to file all bugs with us, and leave
it to the maintainer to pass them to upstream. I have upstreams that follow
our bug tracker, which is great. But if they don't, it should be up to me to
decide whether the report is worth their time.
> - 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.
If the bugreports go through us, they shouldn't have a problem with this. It
is up to the users to choose who they trust. If they trust upstream not to
break things (which for some upstreams is totally justified, but for others it
isn't), they can get the new package from backports (assuming that we made that
easy, so the new version is in there). If they only trust us, they use the
older version and there is nothing wrong with that. If upstream doesn't want
that to happen, tough luck. It's our job to give users what they want, not to
force onto them what upstream wants.
> 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.
I think it is the intent of stable, and it's good. There are some improvements
to be made, especially in terms of shielding upstream from irrelevant bug
reports and making backports easier to use both for upstream and users, but
other that I don't see a problem. Perhaps educating users about whether they
should be using stable or testing is also a part of this.
> 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.
It's up to the users to judge these assertions. If they want to trust them, we
should make it easy to use the packages through backports. But if the user
wants to trust Debian only, including its freeze process, that means they want
the old version and we should provide exactly that.
> Hell, teams packaging Mozilla-soft and PostgreSQL are DDs maintaining
> *external archives* because it's easier.
This indicates that our procedures are too hard. That needs to be fixed.
Maybe people from those teams are reading this and can comment on it?
> 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.
Yes. But I'm reluctant to throw away our stable release process. If it's not
for everyone (and it isn't), we should be more clear about that.
Thanks,
Bas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJXPew6AAoJEJzRfVgHwHE61u0P/jxrzL0Rc2XAAzU2Wo5JZdj5
BErMfNczOxBmsE92PBPdW35tT+7PdzlGRZQI11yMuZHOBq/C/EM5TGAnIyJrsisM
etUBIdY8w6qYnj79vbi5RqfbqcCyQkmb/RYtXsB0Wjfj0k8VHE5r4NCCU9ySFYBq
pjbY2WokeTmtOyFENcLFNFgtMPHqCfhLSoA+/YmnYfLpiX7nGzVD5J+YGS+sDLxf
4KfDnOylxXwzywE/tnE+l8w82RoT7hPHnW+0JqEwFenVhaNhKJunsfB++o0k7owx
kNtPRO96Z2e8/V794E/Ke83gUS5vFyOPPsiEVawvsN0IUX9WTGP0ymg+E28Y8Wb5
5Z5hAljXZVt/oRm34Ukb5BdHFDsssvsuBivZ0HTCvEfMKYETpev1SYN0gpx8v232
vpvHcBZr1AKXQ2rpWDxrPrLcNpyarDF13KILKBXLyRDdYWZttwECA931YWw21Ztj
SDH0bGC7Cb3/DGO7lz/vpOFhjrs4nUi+6eEkZtSYyoRoZ0/ovEnYg1Y+6/oRVmRQ
3nLTVz1TZnYT4nMna0DG9J9bxRsTqXM1fd1mslIg4c1Z6VUxW40Ukd+wDVxPJlaV
mK9K5WrLM4dYPlvgHBRSKfdTOEcZ/DSjdSMyYy+1cGNrJWz04ia9VjieKU87SiVu
IrYJcfdy2Rfuicap08dQ
=4m3S
-----END PGP SIGNATURE-----
Reply to: