If you're not building from source, and you don't need to enforce runtime dependencies because they're outside the packaging system anyway, then you don't need the debian-java apparatus. Just wrap a tarball around your jar file, create a "simple" architecture-independent project with dh_make (or your choice of helper tools), and add your jar to the list of files to be installed. That'll build a perfectly good binary package (though you'll need to correct license files and such). Scripts can go in the Debian packaging. Someday maybe you can build the jar from source; worry about cloning a Java example then.
But you still have the problem of not having root access. I guess you could try unpacking a minideb image somewhere, bind-mounting the JBoss deploy directory into it, and using dpkg with the --root flag and fakeroot? Just be aware that what you're doing, while a totally valid use case for packaging tools generally, is wildly non-standard in Debian world (not just debian-java). The dpkg database is not multi-user, full stop. By design it's on the other side of the sudo gate. You do know that you can set up passwordless sudo access to specific commands? You could wrap a script around dpkg -i that does whatever security enforcement you need on the package before installing it, so you have at least a fig leaf relative to giving everyone sudo. That lets you use the system dpkg database for what it's for, including locking against concurrent modification. You do need to have root access yourself to set this up, of course. Hope this helps, - Michael On Sun, Sep 15, 2024 at 8:06 AM Peter Bittner <peter.bitt...@gmx.net> wrote: > > Dear all, > > Please, don't get me wrong. I'm a long-time Debian user and Open > Source project maintainer. In my own projects I continuously struggle > with the fact that an improvement in one project needs to be taken > over to all the other projects. > > If you manage several (free software) projects yourself you may know > this feeling: You try to improve the state of a repository, and you > know you've done it before hence you want to avoid reinventing the > wheel. But now you're unsure where the last place was where you had > your latest and greatest solution (call it, "current best practice"). > > With that said, I know the tutorials on Debian packaging but I'm > interested in actual, living implementation in popular projects, > because that's where you learn current practices best from. People may > perceive this as rude, but it certainly depends on how harsh or > welcoming you want to be. I learned how to fish years ago, now I want > advice from fishers. > > > 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. > > I appreciate your advice, Michael. The point is, I didn't plan to come > here to bore people with discussing my infrastructure implementation > strategy. I don't think it belongs here. Using system packaging is > exactly the intermediate step I want to use for going towards a > cloud-native deployment for a nowadays traditionally deployed, > VM-based setup. Intermediate steps are needed in environments that are > reluctant to change. And not getting root-access is one component of > the first equation of that change; having to cope with pre-installed > components on the managed VM is another. But we're leaving the ground > of Debian (and Open Source) here by far. > > I had hoped someone would point me to a good example of a popular > project. One that delivers the final JAR, and a Debian maintainer > takes care of packaging only. Maybe because the project doesn't care > about having a Debian package at all. That would cut out the build > part (Maven). > > I started my research with Geogebra, didn't find traces in their > GitHub repositories (and it looks like they stopped promoting packages > for Debian at all) and didn't know where to look for the original > packaging code on Salsa. (I found it in the meantime at > https://salsa.debian.org/java-team/geogebra) > The colorpicker project > (https://salsa.debian.org/java-team/colorpicker) seems dead-simple, > but it builds from source. Is that good enough? The last code change > is from 12 years ago. > > Thank you for your understanding, > Peter >
