I will add that deployment of user jarfiles into a third-party-packaged host-installed JBoss server is not really contemplated in Debian packaging. Not that you can't do it with enough scriptage; but it's not state that the packaging system owns, and dpkg doesn't play that well with external state. Here again there is a containerized solution, with careful network plumbing to give the container access to the right ports on the JBoss server. As to the internal PyPI index, you're going to have to decide whether you're going to do dependency management on the PyPI side or during the pip install process. I favor maintaining requirements.txt and downloaded packages outside the PyPI/Docker plumbing (see https://stackoverflow.com/questions/22531552/how-can-i-download-a-pypi-package-for-pip-installation-at-a-later-date for how), but there are other reasonable choices.
I know you were looking for something simpler. But you're going to face security and maintenance issues sooner or later. Might as well think hard about dependency management before you lock yourself into a packaging system. And be grateful that your needs do not involve npm. On Sat, Sep 14, 2024 at 2:25 PM Michael K. Edwards <m.k.edwa...@gmail.com> wrote: > > 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 > >
