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.