[Barry Warsaw, 2015-10-20] > On Oct 19, 2015, at 09:04 PM, Piotr Ożarowski wrote: > > >Debian Python Policy¹ is something every single packages that extends > >Python should follow. There are many teams (more than 4) each of them > >can have their own policy that extends DPP. > > This is an important distinction that I don't think is really captured > anywhere. Let me rephrase it to see if I'm capturing your sentiment. > > There is Debian Python Policy which describes the standards for publishing > Python libraries and applications within the Debian archive. It is a Debian > Project-wide standard, irrespective of which team, if any, is maintaining the > Python package. > > There is the DPMT, a team for co-maintaining Python libraries. It has its own > policy document for how those libraries are maintained, and adheres to DPP for > publishing those libraries in the archive.
correct > There is the PAPT, a team for co-maintaining Python applications. While there > may be overlap with DPMT (e.g. some upstream packages provide both libraries > and applications), PAPT has its own policy document for how those applications > are maintained, and adheres to DPP for publishing those applications in the > archive. just to make it even clearer: if package provides a tiny script that uses library, it should go to DPMT. If package provides an app and a tiny library (I'm thinking about real library, not just those where maintainer forgot to set --install-lib correctly and installs app into dist-packages) - it's a PAPT candidate. --install-lib is the main difference between DPMT and PAPT. There are different set of problems when you install into dist-packages and outside this directory. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
