On Oct 20, 2015, at 12:37 AM, Piotr Ożarowski wrote: >should we also document that we're not OpenStack Packaging Team?
Or zope-packaging? <wink>. Agreed that there are different teams here, but I am hoping that we can do some consolidation. E.g. I posted on the zope list that I'd like to pull those packages into DPMT. I heard *zero* responses, so I'm honestly not sure there's still anybody who cares about that team. (I'll post on the wider debian lists to follow up, but I will take silence as assent at some point.) >there is one HUGE difference, one is about packaging MODULES and the >other one is packaging APPLICATIONS. One provides python-, python3- >and/or pypy- packages, the other cannot do that. Although there is often overlap. Some packages intentionally provide both libraries and applications. These usually end up in DPMT, which I think is fine. I also think it would be fine to *eventually* merge the two teams. I suspect there isn't really much benefit to keeping them separate and a lot of unnecessary cost. Is there anybody on PAPT who doesn't want to be on DPMT? Is there any reason why team policy couldn't be expanded to describe the few differences between packaging libraries and pure-applications? >> There are packages that do not provide public modules that are aimed at >> developers. I imagine there are also packages that are end user >> applications that do provide public modules, for end user >> programming. These end user's may require the first group of packages >> aimed at developers too. > >if something installs into dist-packages, it should (I'd make it a >"must", but it's just me) provide python-/python3-/pypy- binary >package. Python application should not (again, "must" is much better >here IMO) pollute global Python namespace I'm not sure I'd go as far as MUST, but aside from that, there's no inherent reason IMHO why these two policies and procedures couldn't co-exist within the same team. Cheers, -Barry
