Hi, > > Well, in that case, with you being upstream, I'd separate the two > > packages entirely. > > Yes, I can do that. But, don't you think a whole package for a single > python file is... too much?
Well, is it? You were the one asking how to split it ;)… So, if you think the RPi and non-RPi parts should be separated, then separate them. If you think they shouldn't, then don't. I'd only suggest you make one decision, not two ;). > >> I can exclude rpi.py module from main package and create a > >> python3-mypackage.rpi.install > >> file installing rpi.py in /usr/lib/python3/mypackage but I don't think it > >> is > >> the right way of doing that. > > > > Why not? > > Because I'll miss all the "egg"-related files. Won't I? Well, you will, but that's correct. They only declare the Python package, not the modules it contains. And as your rpi sub-package would obviously depend on the main package, everything would be fine. You'd indeed go with namespace packages instead if you decided to separate the stuff upstream. > And, how can I choose the right destination folder? /usr/lib/python3 > or /usr/lib/python3.4 perhaps? By not using package.install, but copying the whole tree in override_dh_auto_install and the nremoving the non-RPi parts from the RPi copy of the tree. At least that's how I would do it if I had to. But, seeing that you are in doubt of your own decision to split the package: What about don't? Just make one package, period ;). In case you think you have to split the code because part of it will only run with python3-gpiozero, and python3-gpiozero is only available on armel, armhf and arm64, then you have other options: 1. Just make an architecture-dependent dependency on python3-gpiozero and just let the rpi module throw an ImportError it gpiozero is not available. No harm done, happens all the time, and would also happen if you'd not install it in the first place ;). 2. Find out that I am the python3-gpiozero maintainer, and kindly ask me to provide gpiozero on all architectures. It does have a mock GPIO implementation for testing purposes, if that's of any interest. So I'd personally go with 1. now and remove the architecture specification in the dependency once I got 2. finished. Cheers, Nik -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 Dominik George · Hundeshagenstr. 26 · 53225 Bonn Mobile: +49-1520-1981389 · https://www.dominik-george.de/ Teckids e.V. · FrOSCon e.V. Fellowship of the FSFE · Piratenpartei Deutschland Opencaching Deutschland e.V. · Debian Maintainer LPIC-3 Linux Enterprise Professional (Security)
signature.asc
Description: PGP signature