The problem is that the directory structure uses setup.py to find the python packages. So the layout (expected by our build tools) has a single rules file at the same level as the python modules.
. ├── debian │ ├── changelog │ ├── compat │ ├── control │ ├── copyright │ ├── package-one.install │ ├── package-two.install │ ├── package-two.service │ ├── rules │ └── source │ └── format ├── package_one │ ├── check_health.py │ ├── configure_package.py │ └── __init__.py ├── package_two │ ├── foo.py │ ├── bar.py │ └── __init__.py ├── Makefile ├── pyproject.toml ├── pypropject.toml ├── README.md ├── requirements-dev.txt ├── requirements.txt ├── setup.cfg ├── setup.py └── usr On Wed, Nov 4, 2020 at 7:18 PM Michael Biebl <[email protected]> wrote: > > Am 05.11.20 um 00:41 schrieb Alex Nelson: > > The subject may be clear enough, but if you want more information: > > > > I have one git repo that generates one debian package -- no systemd > > service here. > > Is that a package that is shipped in the Debian archive? > Do you have a pointer to the repo? > > > > I have a second git repo that generates one debian package; this > > package does generate a service using "--with systemd" in the rules > > file. > > > > I would like to merge the two repos and have that one repo generate > > two packages, one package will have a service in it, and the other > > will not. > > Are you targetting different distros here or what is the use case? > > > I tried the experiment, but the generated debian package for the > > python module that doesn't need or want to know anything about systemd > > now has (dh generated) references to systemd. > > > > Maybe there is a way to say for target module `my_module_one', use > > > > dh $@ --with python3 --buildsystem=pybuild > > > > and for my other module `my_module_two' use > > > > dh $@ --with python3,systemd --buildsystem=pybuild > > What's the problem with shipping a .service file, even if you don't use > it ? I don't quite see the problem here, tbh.
