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.
Received on Sun Jan 29 2017 - 19:47:08 UTC