Peter — I'm not a debian java maintainer (or DD at all), I'm just someone who has used Debian and derivatives for 25 years. So take this with a grain of salt.
The reason you're getting resistance to your request — apart from social stuff, on which I won't comment — is that the technical obstacles are not really anything to do with Java. Debian binary packaging (nevermind source) isn't just binaries and scripts, it's also mutations to a system-wide dpkg database that doesn't have a concept of user-specific content. The function of the --root= flag isn't to support a user-specific database, it's to allow manipulation of a whole separate root filesystem mounted at that location, and without having a full userland there and chrooting into it, you're not going to be running anything with significant system dependencies (i. e., anything). What I would recommend in 2024 is that you package your software as a private .deb — which is fairly straightforward, even if you have binary blobs that aren't built during the package build — and then install that inside a suitable base debian container image. Docker is one way to do that (and the docker engine is free-as-in-beer and root-optional if you don't need complicated networking); there are others. One reasonable choice, based on minideb, is the Bitnami image found at https://hub.docker.com/r/bitnami/java . I greatly prefer maintaining a debian packaging setup, developing locally, and installing via dpkg inside a container with controlled dependencies over open-coding stuff in a Dockerfile. And I'd use the same base image for Java and non-Java applications (packaged separately), for ease of maintenance; go ahead and add a real Python on top of the base Java container image (if you choose bitnami, see https://github.com/bitnami/containers/blob/main/bitnami/python/3.12/debian-12/Dockerfile for how to do this). Be aware that this is not a Debian-packaged python — you can do that instead, but it's a different path — but you're using virtualenv and `python -m pip install -r requirements.txt` (as a user that is not the runtime user) for all your version-locked library dependencies anyway, right? If not, well, YMMV. (The needs of a Python application packager are not the needs of the debian-python team either. There is some merit in maintaining your own debian repo with custom-built version-locked system-Python library packages too — I've done it, for good and sufficient reason, along with the Java analogue — but you're going to have to learn a lot about Debian if you go down that road.) I lurk but rarely post on any of the Debian lists. Email me directly if I can be of further assistance. Cheers, - Michael On Sat, Sep 14, 2024 at 12:26 PM Peter Bittner <peter.bitt...@gmx.net> wrote: > > > If you tell us what you want to package, we can tell you a good example > > out of more than 50.000 packages > > I'm really looking for generic examples. My motivation is using a > standard, widespread convention or otherwise popular tooling for > deploying software (which - at work - is not open source). So that new > developers don't need to learn "the process". When you see a "debian" > folder in a repository you probably already guess that the project > will build a .deb package. When you see a .deb package you can easily > guess how it will be installed. > > One of the softwares is a Java Web application (delivered to us as a > .jar and some accompanying files) that is deployed into a JBoss > application server preinstalled on the host. The other is actually not > even Java software, it's a bunch of shell scripts and two Python CLI > applications that are installed from an internal PyPI index. So, it's > all about copying files somewhere and performing installation > activities that are encapsulated in the .deb file. > > > > location where it has write access. The scenario is, I have users that > > > must install the software on a managed machine. The system > > > administrators manage the operating system as such, the users install > > > and run their software in user space. > > > > As far as I know NO WAY to do so. > > Let me mention that for my use case it's sufficient that we assume > there are no dependencies, or that if we have unresolved dependencies > (e.g. most notably a JRE) the installation process aborts brutally. > > Doing some research I found a few interesting discussions: > - > https://askubuntu.com/questions/339/how-can-i-install-a-package-without-root-access > - > https://askubuntu.com/questions/193695/installing-packages-into-local-directory > > The two suggested solutions are using `--force-not-root` or simply > unpacking the .deb archive file: > > dpkg -i --force-not-root --root=$HOME package.deb > ar p package.deb data.tar.xz | tar xJv --strip-components=2 -f - > > The latter will certainly not run pre- or post-install scripts, which > is one of the reasons I want to do the packaging, though. (Encapsulate > the installation logic in the installation package itself!) > > Now I would need a simple packaging setup to verify that those > commands actually work for my use case. > > Peter >
