4 ms·
> ...which will not only build the package but also fetch the sources if not already present... Something like this is probably a bigger deal than it should be
by roenxi 1y ago
> ...which will not only build the package but also fetch the sources if not already present...
Something like this is probably a bigger deal than it should be. I keep a .deb of some scripts that I want on all my systems. Truly basic, it just puts the script in /usr/bin. It was quite hard to tell if I'm doing things the sane way and I ended up with the scripts in a few different places - if I look back over the folder I was using there seem to be 3x copies of everything from following what seemed to be a beginner tutorial.
It was a weird experience. Commands like `debuild -us -uc` are opaque about what the flags are supposed to be doing and the process did seem to be naive to the fact that I have a git repository over there and I want to check out a specific commit, maybe run some scripts to build artefacts and then map the artefacts to file system locations. Add some metadata about them along the way.
It quickly put me off packaging. It was much easier in the short term to just run a custom build script to copy everything to the correct location.
- bongodongobob 1y agoI've had the same experience. It's just so much easier to write a script to copy/install/configure everything than it is to learn the ins and outs of building a package.
- pabs3 1y agoIts optimised for distro packaging of upstream projects. Sounds like you would be better served by manually running dpkg-deb.
- roenxi 1y agoI was packaging an upstream project, I had a git repo of scripts with no debian/ folder that represented upstream. It was an experiment to see if I could help package something more complicated, but starting with a trivial project so that there wouldn't be any complexities in the build system. > Sounds like you would be better served by manually running dpkg-deb. I dunno, maybe? I don't write the tutorials; I read them. It said debuild. I'd agree I'm not cut out to figure out the right tool and process, that is why I gave up.
- BiteCode_dev 1y agoYou are not alone, packaging a deb is hard, mostly because the documentation sucks.
- johnisgood 1y agoI mean, you just decompress a .deb package via "ar x", and then you just have to "tar xvf" the resulting "data.tar.*". Creating a .deb package is the opposite of this process.
- hereonout2 1y agoScripts ending up in different places is nothing to do with Debian packaging though. It just puts them exactly where you tell it - you're in complete control of that. If you're unaware, the FSH lays out some guidelines a lot of distros follow - /usr/bin is a good place for any executable coming from a package in my book. Agree debuild can be opaque as it is really a wrapper around loads of dpkg-* scripts. Digging further into those helps but it's not obvious. WRT git, I find it useful to get the entire repo as a tar.gz and treat it like an upstream source package. The have the Debian build stuff as a process on top of that. This is how many packages are maintained for real in the distro (i.e. imagine being the package maintainer of redis or vim and do it that way). It kind of makes sense to me to follow the pattern as things are geared up for it.