[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: third-party packages adding apt sources

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

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.


Reply to: