Reference wiki page: https://wiki.debian.org/AutomaticPackagingTools

Many such tools, often on a per-language/per-packaging team basis
+ Enabled by language-specific upstream packaging tools (UPT):
  Gems, PyPI, CPAN, etc.
+ General idea: (1) take the meta-data from the UPT; (2) convert it to Debian
  meta-data; (3) enjoy

Benefits?
+ For Debian:
  - Enforce more standardization of packaging practices in team
  - Centralize intelligence, move it from packages to tool
    + How to build & install files, how to run tests, etc.
  - Make it faster to package simple packages, focus on the hard stuff
+ For sysadmins:
  - Easy path to create Debian packages
    + for what's not packaged in Debian (after all, only 20k source packages
      in Debian, probably one order of magnitude more out there)
    + for backports / new upstream versions, to meet local needs
    => Could help achieve world domination by providing a single,
       cross-language, unified way to distribute software
    Dream: all sysadmins know how to create (basic) Debian packages, and use
    a local repository to distribute software inside their infra

Downsides?
+ Yet Another additional tool/layer to learn
+ Less people will know about the lower layers of packaging tools

Current status: https://wiki.debian.org/AutomaticPackagingTools
- not entirely up-to-date (please help!)
Review of current status - identify opportunities for collaboration or for
bits that should move to debhelper/devscripts/a separate package


Topics for discussion:
- Should we have a common front-end tool for all automated packaging tool?
  (debdry?)
  + Make it easier for end-users to create their own local debs
  + Help enforce the same interfaces
- Workflows:
  + How does on update an existing package?
    My recipe: move away debian/; re-recreate from scratch; merge using meld
    (graphical diff+merge tool)
- What's the target situation wrt Debian?
  + Less packages in Debian, because it became so easy to create packages for
    the simpler+long-tail stuff that there's no need to package those in Debian
    anymore
  + More packages in Debian, because we actually get a way to easily scale in
    terms of number of packages
- What should be the recommended way to create a local repo?
  + reprepro is quite hard
  + https://www.debian.org/doc/manuals/repository-howto/repository-howto
    (dpkg-scanpackages) is supposed to be obsolete
  + apt-ftparchive
  + aptly

Participant questions:
- Is there any expression of copyright that is both sufficient to use as or generate debian/copyright that we can push upstream?
- Should we extend this topic to extension packages (eg. PostgreSQL extensions, VIm plugins) which share many properties with language specific package formats and/or repositories.

Running notes

* Build-depends: some tools use apt-file, haskell packages have their own control file field
* copyright extraction works well in haskell, works maybe in dh_make. license-reconcile and licensecheck are useful tools there.
* AutomaticPackageTools could give a rough indication of how ready the created packages are.
* p1otr is preparing a successor to python3-stdeb
* tools for pear (php) are available as well, but upstreams are running away from pear
* fpm, mh-make (maven), dh_helper
* should dh_make suggest using the dedicated tools if it detects
* debdry: don't store tool output, but only changes to them (but needs some community love); other tools need (and have) ways of explicitly refreshing their output; some users just rebuild and meld, or do a three-way merge (nomeata).
* ideally, we might only need to fix bugs upstream or in the tools, and then have debian/ built automatically again; troublesome with copyright and descriptions (for different perspectives).
* we should have a package like simple-repository that provides a (possibly unsigned) local repository with a directory that accepts packages using inotify