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)
Attachment:
signature.asc
Description: PGP signature