Re: third-party packages adding apt sources
Daniel Pocock writes ("Re: third-party packages adding apt sources"):
> On 19/05/16 19:04, Ian Jackson wrote:
> > Debian proper has a very high bar for inclusion. Obviously there are
> > perhaps some packages which are close to suitable for inclusion, but
> > the vast majority of things that aren't in Debian proper are outside
> > it for real, nontrivial reasons (whether of technical quality of the
> > binaries, technical quality of the source, or political/ethical
> > reasons).
>
> Do you think that if these upstreams became involved in other ways - for
> example, if we proactively invited them to MiniDebConfs and other events
> - we might bridge the gap to help them understand our way of thinking,
> whether it is technical or otherwise?
I think you are missing my point. You seem to have the assumption
that for many of the people providing packages in third-party repos,
they don't have what I'm calling real and nontrivial reasons.
Hell, I even have .debs I distribute myself outside Debian (although I
haven't gone to the trouble of setting up reprepro).
> Sure, some of them will never change, some of them have no capacity to
> think long-term but there are others who simply don't quite understand
> and may go the extra mile if they get to know us a little better.
The problem is not one of lack of understanding. These out-of-Debian
repos are not going to be abolished by an outreach and education
programme.
Let me go into more detail about a few of the kinds of real,
nontrivial reasons, I'm talking about:
1. Proper source format. I wrote:
> > Providing a proper Debian source package is also a lot more work than
> > writing some kind of ad-hoc build system that spits out a .deb or
> > three.
Packages with ad-hoc source build systems are never going to be in
Debian proper, for obvious reasons. They wouldn't fit. That's not
something we can fix.
But writing a proper build system for an ad-hoc Debian source package
is a fair amount of work. I did it recently for a moderately easy
package I encountered in Raspbian, and it took /me/ most of a day.
That upstream didn't do it is quite understandable. Doing so was not
in their `long-term' interests, as you put it: the effort for them to
learn how to do it, and then do it, and then debug it, and then deal
with the transitional pain, was simply not worth it to them. And
probably not to their userbase, either.
We in Debian can improve this situation by making proper Debian source
packages easier to build. For example, we can:
* Provide build tools which require less boilerplate, are less
fragile, and are more automatic. Yay dh(1).
* Provide _shorter_ intro documentation.
* Provide better source code management systems - that are less
prehistoric than .dsc 1.0 (non-native) and less "omg wtf bbq"
than .dsc "3.0 (quilt)". (non-crazy git integration, dgit)
But there are still going to be plenty of people for whom it's a
better use of their time to do something else but tart up the source
for their .deb builds.
2. ABI/API
The package I mention above didn't take the care with API/ABI, split
library packaging, and so on, that would be expected in Debian. This
was tolerable in the original Raspbian context.
I sent the upstream patches to fix this but there are compatibility
implications with changing the packaging arrangements. Thinking about
this stuff, and planning for it, and anticipating the needs of the
users, is nontrivial.
For quite a few packages, the levels of compatibility and
upgradeability we would expect in Debian are simply not worth the
effort. I don't think in Debian we would want to relax this, do we ?
3. Freedom
This is the killer reason to provide a third-party apt repository.
A software provider who provides packages outside Debian does not need
our permission to do so; they do not need our help to provide new
versions; they do not need to confirm to our release rules.
Of course in Debian our focus is freedom for our users, so there are
limits to how much freedom we want to make available to upstreams and
third-party packagers: we want to avoid becoming complicit in efforts
to control users. But users often choose (for reasons that seem good
to those users - and, often, reasons that /are/ good for those users)
to want to run non-free software. So even when it concerns non-free
software we need to respect and support that decision, while avoiding
encouraging it.
I don't think an outreach campaign by Debian, encouraging people to do
work in Debian rather than outside, is going to significantly change
the way software providers make decisions about licensing, release
schedules, or whatever.
> Another thing comes to mind: making sure that even if the user
> explicitly allows some other repository, they are protected from package
> updates that come along and replace other things like apt itself, libc,
> bash, gnupg, ...
This has to be an optional feature. The user might specifically want
that !
Ian.
Reply to: