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
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
Reply to: