Path: csiph.com!fu-berlin.de!bofh.it!news.nic.it!robomod From: Ole Streicher Newsgroups: linux.debian.maint.python Subject: Extra debian.blends Python package Date: Sat, 24 Mar 2018 11:00:01 +0100 Message-ID: X-Mailbox-Line: From debian-python-request@lists.debian.org Sat Mar 24 09:51:16 2018 Old-Return-Path: X-Amavis-Spam-Status: No, score=-6.751 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, HEADER_FROM_DIFFERENT_DOMAINS=0.249, LDO_WHITELIST=-5] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -7 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Lines: 29 X-Mailing-List: archive/latest/15701 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/87o9jdyfwv.fsf@debian.org Approved: robomod@news.nic.it Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Sat, 24 Mar 2018 10:35:44 +0100 X-Original-Message-ID: <87o9jdyfwv.fsf@debian.org> Xref: csiph.com linux.debian.maint.python:10302 Hi, I am currently rewriting part of the blends-dev package which is used for maintaining Debian Pure Blends into Python. This however comes out some abstractions of Blends (namely the tasks infrastructure) that may be re-usable on other places, f.e. in the blends.d.o web service. So it is probably a good idea to create a separate Python package from it. Since this package deals with tasks sources, it sounds natural to put this as a sub-package of the "debian" package. I would however not like to integrate the sources to python-debian. First, it is very new and likely to change API quickly in the next time. But also, the blends subpackage is quite special; there is no need to have it installed in such a broad manner as python-debian. And finally, I do not care about Python 2 compatibility here. What I could do easily is to create a python3-debian-blends binary package (maintained in the "blends" source package) for this subpackage, just installs a "blends.py" into ../dist-packages/debian/ Since this is however somehow hijacking (part of) the namespace of python-debian, I'd like to know the policy here. Are there any problems with that approach? Best regards Ole