Hello Paul, On Samstag, 21. Mai 2016 14:07:53 CEST Paul Wise wrote: > On Fri, May 20, 2016 at 1:34 PM, Vincent Bernat wrote: > > Totally agree. Our standards are far too high for many upstreams. > > I don't understand the disconnect here. Are upstreams not interested > in software quality to the extent we are?
I know one quite popular example where some upstream people even objected having the software packaged in Debian: Unfit upstream / RM: owncloud -- ROM; PHP 7.0 Transition https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816376 I think similar can be said for many web applications that are just developed at a very high pace. Combine that with an upstream policy not to support skipping updates between major versions… by supporting redoing older update steps and you have something that is compatible with Debian stable standards. Now I know other web apps where this works better, like Wordpress, that now even has a wonderfully working backport. Still this has brought up a principal issue that is still unsolved. I know of some other upstreams that provided packages themselves for… whatever reasons, might be a good idea to ask them. So for example basically all log analysis and indexing software that seems to be so popular in the last time: - Elasticsearch: newer versions than in unstable - Logstash - Kibana - Fluentd - Graylog Also things like OpenNebula where I have been involved a bit failed in Debian due to lack of manpower combined with that some effort to work together did not play out probably due to lack of manpower on upstream side as well. Instead they just do a stuff it all in one or a few packages no matter what. Which is similar to how Owncloud upstream does packages. It is basically like a huge tarball, all just stuff in /var/html, including config files and be done with it. Logstash packages at least have their config files in /etc, yet all else in /opt/logstash or so. I suspect one of the reasons is the perceived simplicity of just doing it yourself without having to abide to all the rules, to have the package lintian clean (I never checked those against lintian tough), and to generally get more work done in less time, even if that work has a lower quality than what is usually accepted into Debian. > > I am always flabestered by the popularity of fpm to build Debian > > packages (and by the increasing popularity of pleaserun by the same > > author on the same concepts). It provides a way to easily build a Debian > > package from a directory but produces somewhat crippled/incomplete > > packages and is no help to us since it's completely outside of any of > > our tools. It also handles RPM (and now other package formats), but I > > don't think this would explain its popularity alone. > > I think we probably need to get dpkg-buildpackage to automatically run > some of these: > > https://wiki.debian.org/AutomaticPackagingTools I am very happy about Maxy´s work to automate Plasma 5 and KDE Frameworks 5 packaging. Here there is a similar issue: Upstream has way faster release cycles and additionally they splitted up their stuff into a lot more single projects. With KDE 3, a bit less with KDE SC 4 it was a number of larger packages that you could even still count easily enough with your fingers. With Plasma 5 and KDE Frameworks 5 upstream provides literally hundreds of tarballs and git repos to package in order to get a full desktop experience. According to cd /usr/share/doc/libkf<TAB><TAB> I have 213 library packages installed on my system. Maxy went to a great extent of automating things, which in some cases can lead to this: karchive (5.22.0-1) unstable; urgency=medium [ Automatic packaging ] * Update symbols files from buildds logs (5.21.0-1). * Update symbols files. * Update build-deps and deps with the info from cmake -- Maximiliano Curia <[…]> Thu, 19 May 2016 00:19:49 +0200 In other cases it is a mix of manual and automatic work: karchive (5.21.0-1) experimental; urgency=medium [ Maximiliano Curia ] * Replace the "Historical name" ddeb-migration by its "Modern, clearer" replacement dbgsym-migration. * Add upstream metadata (DEP-12) * debian/control: Update Vcs-Browser and Vcs-Git fields * Update acc test script * uscan no longer supports more than one main upstream tarball being listed [ Automatic packaging ] * Update build-deps and deps with the info from cmake * Update symbols files. * Bump Standards-Version to 3.9.8 -- Maximiliano Curia <[…]> Thu, 05 May 2016 15:04:24 +0200 I am aware of similar efforts for a lot of different things like haskell packages, where Joachim Breitner and other teams upload literally hundreds of packages in a single day. I don´t know whether someone has an overview on whats available and what is used in the different packaging teams. But I do think the wiki page you linked is not complete. I wonder about a landing page for upstreams interested in working with the Debian project to provide packages within the official Debian repos. Sure there is new maintainers guide and debian-mentors mailing list, but is there any official page where upstream can see whom to approach for help and where to learn how to interact efficiently with Debian developers and maintainers in order to learn the process for doing it within Debian? Maybe something similar to what the KDE project has started the other way around: They have started a new effort to communicate and interact with distro people, where packagers can raise their concerns and needs, ask questions. And where KDE developers can also say what they want from distributions. Maybe create a landing page and mailing list for upstreams to voice what they need and why they do things the way they do (package on their own)? At least it provided the opportunity to learn why upstreams do it the way they do. Thanks, -- Martin