❦ 21 mai 2016 14:07 +0800, Paul Wise <pabs@debian.org> :
>> 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?
Many of them don't consider packaging quality as important. As long as
the package does its job, they are fine. Notably, packages generated
with fpm have many downside but they mostly work and people are
happy. The main feature of fpm is being easy, not producing good quality
packages. In our cases, good quality packages are the main feature we
want. Being easy is a plus.
>> 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
A meta tool "package me this" would be interesting. However note that
many of those tools are too complex for many upstreams because they
don't want to package each dependency one by one. For example,
dh-make-golang is fully automatic but you need to run it on each
dependency. That's fine because those tools are for building packages
that should be fit to go into our archive.
>> And there is also the lost cause of vendoring that gained even more
>> traction with Go but that was already a problem with the Java ecosystem.
>> I don't think there is much to do about this one.
>
> Embedded code/data copies have been a problem since as long as I've
> been a Debian user, they aren't specific to any particular language
> community.
>
> https://wiki.debian.org/EmbeddedCodeCopies
For some languages, embedded copies are a pattern. Notably Go. But there
is also the omnibus stance: the embedded copy could not be in the
source, but could be in the shipped artifact. This includes Go, JS and
Java (when using uberjars). For some other ecosystems, the embedded copy
is more the exception than the rule (C, C++, Python).
If upstream is using embedded copies, they are quite unlikely to make
any effort tu undo this aspect.
--
Indent to show the logical structure of a program.
- The Elements of Programming Style (Kernighan & Plauger)
Attachment:
signature.asc
Description: PGP signature