Someone:

I am trying to create one or multiple packages for Archlinux to install nosh



This has come up several times with multiple people, now.

I have no Arch Linux machines, and I am entirely dependent from Arch Linux people for the packaging part. As I already told one person back in August 2016, this is your opportunity to shine. (-:

My second redo is already packaged for Arch, I am told:

* https://aur.archlinux.org/packages/redo-jdebp/

* https://git.parabola.nu/abslibre.git/plain/pcr/jdebp-redo/

Here's what I know.

The redo packaging runs package/compile followed by package/export.

This is not the way to approach packaging the nosh toolset. It's not one giant lump, as you can see from the FreeBSD/TrueOS, Debian, and OpenBSD packages that I have done. What you Arch Linux people with the packaging experience have to provide is a way, on Arch, for one source package to build multiple binaries packages. This should not be hard. It's a very common thing to do, after all. It is, indeed, pretty much the norm in the worlds of Debian and Ubuntu. As you can see from the WWW pages about the FreeBSD/TrueOS, Debian, and OpenBSD packages, there are doco packages, service bundle packages, multiple toolset packages, and multiple -run packages.

The way that this works on Debian and the BSDs is largely driven by package/debian/rules and package/bsd/rules, which are in turn determined by Debian's package build system, in particular its dpkg-buildpackage tool. Notice what the rules system does. It runs package/export to populate the ./debian/tmp/ tree, and then package/stage to populate the individual binary package trees (with links) from that in the layout that is actually used within the packages. The Debian Maintainers' Guide and the FreeBSD Porters' Handbook have more on the concept of "staging" when building binary packages.

* https://www.debian.org/doc/manuals/maint-guide/build.en.html#completebuild

* https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/special.html#staging

Coming up with how something like this works on Arch is another part of your opportunity to shine, Arch packaging people.

Note that I currently plan to take package/export out of the build process and have package/stage work directly from (a copy of) the original slashpackage tree, i.e. command/ manual/ config/ guide/ et al.. Rearranging everything from slashpackage into another layout under ./debian/tmp/ only in order to rearrange it again in the staging areas seems like an unnecessary complexity. pax -r -w of the original slashpackage layout into ./debian/tmp/ or ./bsd/tmp/ seems a better idea.

There has been for a fair while now an important note at http://jdebp.eu./Softwares/nosh/source-package.html that the package/export command may change. It does both too much and too little as a tool for installing from source. It exports one giant lump, and it doesn't do all of the things that the package "maintenance scripts" do. In pursuit of that latter, back in 1.29 the BSD side of package creation was modified to make it possible to auto-generate installation/upgrade/deinstallation scripts for the old and new BSD package tools. This is, as you can see, done with package/bsd/gencontrol, which makes (the very different) +MANIFEST files for both the old and new BSD package tools. This is on the cards for Debian as well.

For Arch, the build system will need to process a similar set of files to the various package/bsd/nosh-*.p files, in some way that is appropriate to how such maintenance scripts are handled on Arch, as well as do more specific things for likes of nosh-run-system-manager. Yes, this is vague. I've refactored this into a way of making different maintenance scripts from effectively non-imperative lists of service bundles and user accounts. I'll press on with getting you a set of package/debian/nosh-*.p files, which at least will list the Linux service bundle suite not the BSD one, which can then be patched into arch/*.p files. You have to work out how to then join these lists up with however Arch does installation/upgrade/deinstallation scripts in packages, however. This is another part of your opportunity to shine, Arch packaging people.

Reply via email to