You are not logged in.

#1 2020-09-15 22:22:34

Omar007
Member
Registered: 2015-04-09
Posts: 368

PKGBUILD review request: cockpit-split

This is probably going to be a weird PKGBUILD for a large majority here (hence me not just throwing it onto the AUR) but I figured that it could be useful for others.
In summary, the weird part is basically that it's depending on a repository package but not in the 'depends=()' type of way. So here I am, putting this thing up here for some scrutiny. tongue

To get some back-story/motivation out of the way really quickly:
I created this (split) package to make the installation of cockpit as minimal as it can possibly be. This to allow for bastion based deployments and high system customization. With this it would be possible to set up a system as host and interface, as just an interface (bastion) or as just a host (interface on another system or a container, etc).
Since Arch is already providing some components as separate items and all the required files needed for splitting are contained within the 'cockpit' package, I'm using said package as a base. This so that any/all modules already build for and available with Arch can be re-used and do not have to be replaced/repackaged in this variant.

I've already had success using it myself for the remote bastion use-case;
1) Installed cockpit-bridge on the to-be-monitored system (plus a mix and match of additional modules both from this as well as the repos)
2) Use cockpit/bastion container as the interface connecting to said system

pkgbase=cockpit-split
pkgname=('cockpit-split'
         'cockpit-doc'
         'cockpit-bridge'
         'cockpit-kdump'
         'cockpit-networkmanager'
         'cockpit-packagekit'
         'cockpit-shell'
         'cockpit-storaged'
         'cockpit-systemd'
         'cockpit-tuned'
         'cockpit-users'
         'cockpit-ws')
pkgver=227
pkgrel=1
pkgdesc='A systemd web-based user interface for Linux servers. Fully splits the sub-components out for maximum customization.'
arch=('x86_64')
url='https://cockpit-project.org/'
license=('LGPL')
source=("cockpit.tar.zst::https://mirror.f4st.host/archlinux/community/os/${CARCH}/cockpit-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst")
noextract=("cockpit.tar.zst")
sha256sums=('5ed3bf2043fd360442ba5201625bdf794270a71a3e15a4870533ced9a4d15c94')

package_cockpit-split() {
	pkgdesc='Meta-package bridging all cockpit-* sub-modules.'
	arch=('any')
	optdepends=("cockpit-bridge: the system agent"
	            "cockpit-doc: deployment and developer guide"
	            "cockpit-kdump: manage kernel crashdumps in the web interface"
	            "cockpit-networkmanager: manage network connections in the web interface"
	            "cockpit-packagekit: manage packages in the web interface"
	            "cockpit-shell: shell access through the web interface"
	            "cockpit-storaged: manage hard disks in the web interface"
	            "cockpit-systemd: manage servives in the web interface"
	            "cockpit-tuned: manage udev/sysctl/sysfs in the web interface"
	            "cockpit-users: manage users in the web interface"
	            "cockpit-ws: web-based user interface"

	            # Below are from the original package.
	            "cockpit-dashboard: show up to 20 servers on a dashboard in the web interface"
	            "cockpit-docker: manage docker containers in the web interface"
	            "cockpit-machines: manage virtual machines in the web interface"
	            "cockpit-pcp: show performance metrics in the web interface"
	            "cockpit-podman: manage podman containers in the web interface")
	provides=('cockpit')
	conflicts=('cockpit')

	install -dm755 "${pkgdir}/usr/share/cockpit"

	tar -C "${pkgdir}" -xf cockpit.tar.zst \
		usr/share/man/man1/cockpit.1.gz \
		usr/share/metainfo/cockpit.appdata.xml \
		usr/share/pixmaps/cockpit.png
}

package_cockpit-doc() {
	pkgdesc='The Deployment and Developer Guide.'
	arch=('any')
	depends=('cockpit-split')

	tar -C "${pkgdir}" -xf cockpit.tar.zst \
		usr/share/doc/cockpit
}

package_cockpit-bridge() {
	pkgdesc='The server-side component that runs commands on the system on behalf of the web-based interface.'
	depends=('cockpit-split' 'cockpit-shell' 'cockpit-systemd' 'libssh' 'json-glib' 'polkit')

	tar -C "${pkgdir}" -xf cockpit.tar.zst \
		etc/cockpit/machines.d \
		usr/share/cockpit/base1 \
		usr/share/cockpit/ssh \
		usr/share/polkit-1/actions/org.cockpit-project.cockpit-bridge.policy \
		usr/share/man/man1/cockpit-bridge.1.gz \
		usr/bin/cockpit-bridge \
		usr/lib/cockpit/cockpit-askpass \
		usr/lib/cockpit/cockpit-ssh
}

package_cockpit-kdump() {
	pkgdesc='A module for managing kernel crash dumps.'
	depends=('cockpit-split' 'kexec-tools')
	arch=('any')

	tar -C "${pkgdir}" -xf cockpit.tar.zst \
		usr/share/cockpit/kdump \
		usr/share/metainfo/org.cockpit-project.cockpit-kdump.metainfo.xml
}

package_cockpit-networkmanager() {
	pkgdesc='A module for managing networking, using NetworkManager.'
	depends=('cockpit-split' 'networkmanager')
	arch=('any')

	tar -C "${pkgdir}" -xf cockpit.tar.zst \
		usr/share/cockpit/networkmanager
}

package_cockpit-packagekit() {
	pkgdesc='A module for managing packages, using packagekit.'
	depends=('cockpit-split' 'packagekit')
	arch=('any')

	tar -C "${pkgdir}" -xf cockpit.tar.zst \
		usr/share/cockpit/apps \
		usr/share/cockpit/packagekit
}

package_cockpit-shell() {
	pkgdesc='A module providing a shell.'
	depends=('cockpit-split')
	arch=('any')

	tar -C "${pkgdir}" -xf cockpit.tar.zst \
		usr/share/cockpit/shell
}

package_cockpit-storaged() {
	pkgdesc='A module for managing storage, using udisks2.'
	depends=('cockpit-split' 'udisks2')
	arch=('any')

	tar -C "${pkgdir}" -xf cockpit.tar.zst \
		usr/share/cockpit/storaged \
		usr/share/metainfo/org.cockpit-project.cockpit-storaged.metainfo.xml
}

package_cockpit-systemd() {
	pkgdesc='A module for systemd services.'
	depends=('cockpit-split')
	arch=('any')

	tar -C "${pkgdir}" -xf cockpit.tar.zst \
		usr/share/cockpit/systemd
}

package_cockpit-tuned() {
	pkgdesc='A module for udev/sysctl/sysfs.'
	depends=('cockpit-split' 'tuned')
	arch=('any')

	tar -C "${pkgdir}" -xf cockpit.tar.zst \
		usr/share/cockpit/tuned
}

package_cockpit-users() {
	pkgdesc='A module for managing users.'
	depends=('cockpit-split' 'accountsservice')
	arch=('any')

	tar -C "${pkgdir}" -xf cockpit.tar.zst \
		usr/share/cockpit/users
}

package_cockpit-ws() {
	pkgdesc='A systemd web-based user interface to interact with systems using cockpit-bridge.'
	depends=('cockpit-split' 'gnutls' 'json-glib')
	optdepends=('krb5: kerberos authentication support')
	backup=('etc/pam.d/cockpit' 'etc/cockpit/ws-certs.d')

	tar -C "${pkgdir}" -xf cockpit.tar.zst \
		var/lib/cockpit \
		etc/cockpit/ws-certs.d \
		etc/issue.d \
		etc/motd.d \
		etc/pam.d \
		usr/share/cockpit/branding \
		usr/share/cockpit/motd \
		usr/share/cockpit/static \
		usr/share/locale \
		usr/share/man/man1/cockpit-desktop.1.gz \
		usr/share/man/man5 \
		usr/share/man/man8 \
		usr/lib/systemd/system \
		usr/bin/remotectl \
		usr/lib/cockpit/cockpit-desktop \
		usr/lib/cockpit/cockpit-session \
		usr/lib/cockpit/cockpit-tls \
		usr/lib/cockpit/cockpit-ws \
		usr/lib/cockpit/cockpit-wsinstance-factory \
		usr/lib/security \
		usr/lib/sysusers.d \
		usr/lib/tmpfiles.d
}

Let me know how much it made your toes curl I guess wink

Last edited by Omar007 (2020-09-15 22:23:34)

Offline

#2 2020-09-16 01:10:56

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: PKGBUILD review request: cockpit-split

Using <name>-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst from a mirror as the source=() is forbidden by policy and you may not upload it to the AUR.

Any specific reason you cannot just install the entire package including unneeded files on each machine?

...

Note: missing makedepends=('tar')

Consider using bsdtar instead as makepkg guarantees and uses it internally.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#3 2020-09-16 09:55:43

Omar007
Member
Registered: 2015-04-09
Posts: 368

Re: PKGBUILD review request: cockpit-split

eschwartz wrote:

Using <name>-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst from a mirror as the source=() is forbidden by policy and you may not upload it to the AUR.

Would a non-mirror based solution be fine or is it the concept of using a repo package as source in general (regardless of it being pulled in via a mirror or not) not OK for the AUR?

Also, where can I find this information? The only relevant information I'm aware of are the PKGBUILD, AUR and Package Guidelines, all of which say nothing about this.
If there is an extra set of policies/guidelines somewhere, I'd love to know where I can find these. Right now, the only thing I'm aware of that is ever said about mirrors (in general, be it Arch or otherwise), is that you 'should not' but not a 'may not/never' (with the sole reasoning being; mirrors can disappear).

eschwartz wrote:

Any specific reason you cannot just install the entire package including unneeded files on each machine?

Technically you could but as I mentioned that is not the use-case for this. This is for when you don't want everything.
If you're happy with just throwing everything on a system and automatically install dependencies and enable as well as expose the functionality of all those sub-modules, just install the repo package.
This is specifically for the cases where you do not want to install and expose certain functionality.

eschwartz wrote:

Note: missing makedepends=('tar')

Consider using bsdtar instead as makepkg guarantees and uses it internally.

Changed to `bsdtar`.


I'll also remove the renaming to make sure the downloaded file is (stays) unique for different versions, that was a left-over from earlier tests where I just had the file locally as cockpit.tar.gz so just quickly mapping that name was a quick way to test things.

Offline

#4 2020-09-16 11:56:50

a821
Member
Registered: 2012-10-31
Posts: 381

Re: PKGBUILD review request: cockpit-split

Omar007 wrote:

Would a non-mirror based solution be fine or is it the concept of using a repo package as source in general (regardless of it being pulled in via a mirror or not) not OK for the AUR?

The issue is using a repo package as source. IMO this falls under Rule 1: https://wiki.archlinux.org/index.php/AU … submission

Omar007 wrote:

Also, where can I find this information? The only relevant information I'm aware of are the PKGBUILD, AUR and Package Guidelines, all of which say nothing about this.
If there is an extra set of policies/guidelines somewhere, I'd love to know where I can find these. Right now, the only thing I'm aware of that is ever said about mirrors (in general, be it Arch or otherwise), is that you 'should not' but not a 'may not/never' (with the sole reasoning being; mirrors can disappear).

see link above

Offline

#5 2020-09-16 12:29:59

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,866

Re: PKGBUILD review request: cockpit-split

This looks like a case where ayekat remakepkg can help.
See remakepkg — rebuild pacman packages with changes


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#6 2020-09-16 12:49:16

ayekat
Member
Registered: 2011-01-17
Posts: 1,589

Re: PKGBUILD review request: cockpit-split

*nervous sweating*

While one can indeed use repkg/remakepkg to split packages (I do so with pacman and makepkg), I don't think it will add much value in this case. Splitting a package into 10+ packages will likely result in even more work when using repkg/remakepkg (and there is no any additional safety either; you might still end up with conflicting or lost files…).


pkgshackscfgblag

Offline

#7 2020-09-16 12:52:42

Omar007
Member
Registered: 2015-04-09
Posts: 368

Re: PKGBUILD review request: cockpit-split

a821 wrote:

The issue is using a repo package as source. IMO this falls under Rule 1: https://wiki.archlinux.org/index.php/AU … submission

If this is supposed to be covered by that rule, that rule is written very badly. The way it is written now is only about creating packages for something that is already in the repo without differing from the repo package.
E.g. making an AUR package that builds `vim` from the same sources, the same version and does not apply any patches.

Going over the current rule;
> The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances.
Technically it doesn't; it makes use of but it doesn't build the same package. The resulting package differs from the original. It's not even 1 package anymore for one. Now, semantically speaking one could argue the overall collection of these packages provide the same functionality as the repository package but if we're going down that rabbit hole, there is some pruning to do on the AUR...
> Check the official package database for the package. If any version of it exists, do not submit the package.
A version exists but not one like this (also see exceptions later on).
> If the official package is out-of-date, flag it as such.
It is not.
> If the official package is broken or is lacking a feature, then please file a bug report.
I suppose I could go bug the maintainer to provide all the modules as separate packages but technically the repo package isn't broken nor missing features. (or one must qualify this customization as a feature)
> Exception to this strict rule may only be packages having extra features enabled and/or patches in comparison to the official ones.
I'd classify this one here; it's providing the cockpit features separately. Could you install a combination that equals the repository package? Sure. But the point of this variant is to NOT do so.
> In such an occasion the pkgname should be different to express that difference. For example, a package for GNU screen containing the sidebar patch could be named screen-sidebar. Additionally the provides=('screen') array should be used in order to avoid conflicts with the official package.
This is done and covered.

Going by that rule (and all the text on the other guidelines I mentioned), I'd say it is OK for the AUR. Hence me asking about where I can find said information.
If the rules here are supposed to prevent this case/type of package, then please update it or add one. Right now it does not do so.
E.g. something akin to "Repacks of official packages are not allowed on the AUR.". But tbh that means a LOT of packages would need to be removed from the AUR as there are a bunch of variants that just repack or strip out features.

Alternatively one could literally clone the repo PKGBUILD, split it up and provide/conflict all repo packages but that just creates a lot of duplication with no other benefit whatsoever...

a821 wrote:

see link above

As I mentioned, I am aware of these. They do not cover this (and if they are supposed to, rewrites/additions are needed).


I will post an updated version here with the mentioned fixes later today but if this is how things are I'm just going to leave it at that and keep it in my personal repo. Not like anything changes for me when it's not on the AUR ¯\_(ツ)_/¯


EDIT: posts where made when I was typing this; will update in a bit with replies to those as well smile

EDIT2:

Lone_Wolf wrote:

This looks like a case where ayekat remakepkg can help.
See remakepkg — rebuild pacman packages with changes

ayekat wrote:

*nervous sweating*

While one can indeed use repkg/remakepkg to split packages (I do so with pacman and makepkg), I don't think it will add much value in this case. Splitting a package into 10+ packages will likely result in even more work when using repkg/remakepkg (and there is no any additional safety either; you might still end up with conflicting or lost files…).

I did not know this was a thing yikes

While how I did things now works perfectly fine for my personal use (and it being a PKGBUILD could be packaged by anyone using the standard Arch tools), it does sound like that tool could potentially be a cleaner way to handle this type of thing for some personal stuff in the future.
Will probably not rewrite this one though, a quick glance does seem like this one might be a tad to complicated/error-prone to do this with.

Last edited by Omar007 (2020-09-16 12:59:51)

Offline

#8 2020-09-17 18:42:52

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: PKGBUILD review request: cockpit-split

@Omar007,

There's a couple of problems.

The use of a mirror is specifically its own problem since the link is not stable and will eventually die anyway. Not because of "software mirror" but because of "distro repos get regularly rebuilt and old packages get removed"; package sources should never be urls that frequently appear and disappear.

It's also generally a problem to just repack someone else's compiled binaries; while -bin packages do exist, they're only supposed to be used for redistributing upstream prebuilt binaries.

Creating a package that does nothing but turn a repo package into a split package likely falls under rule 3: "why is this useful". I asked:

eschwartz wrote:

Any specific reason you cannot just install the entire package including unneeded files on each machine?

Omar007 wrote:

Technically you could but as I mentioned that is not the use-case for this. This is for when you don't want everything.

"technically you could but this covers the use case where you don't end up doing so" is NOT an answer to my question. It's an off-topic collection of words that don't mean anything specific to this thread. So I will skip this entirely.

Omar007 wrote:

If you're happy with just throwing everything on a system and automatically install dependencies and enable as well as expose the functionality of all those sub-modules, just install the repo package.
This is specifically for the cases where you do not want to install and expose certain functionality.

Is this more than just "it uses more disk space"? The dependencies you're splitting out into split packages are optdepends in the repo package so I don't really see what PRACTICAL benefit you're getting here by splitting it.

If you do need to split it, why not just fork community/cockpit, build it yourself, and do the additional component splitting from the source install? This is generally how packages that do things slightly differently from existing repo packages do it.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#9 2020-09-17 20:02:33

Omar007
Member
Registered: 2015-04-09
Posts: 368

Re: PKGBUILD review request: cockpit-split

eschwartz wrote:

The use of a mirror is specifically its own problem since the link is not stable and will eventually die anyway. Not because of "software mirror" but because of "distro repos get regularly rebuilt and old packages get removed"; package sources should never be urls that frequently appear and disappear.

That could be fixed/changed though so that is a moot point. I had already changed it to the archive to have a more stable URL as a first improvement step on that part.
(also, key here being 'should', which I mentioned earlier)

eschwartz wrote:

It's also generally a problem to just repack someone else's compiled binaries; while -bin packages do exist, they're only supposed to be used for redistributing upstream prebuilt binaries.

Creating a package that does nothing but turn a repo package into a split package likely falls under rule 3: "why is this useful". I asked:

eschwartz wrote:

Any specific reason you cannot just install the entire package including unneeded files on each machine?

Omar007 wrote:

Technically you could but as I mentioned that is not the use-case for this. This is for when you don't want everything.

"technically you could but this covers the use case where you don't end up doing so" is NOT an answer to my question. It's an off-topic collection of words that don't mean anything specific to this thread. So I will skip this entirely.

I've explained my motivation there and in the initial post. I'm not sure how else I'd need to word it for you.
If the following TL;DR doesn't work I don't know how I need to explain this to you (though I wonder if there would be a point if you're just going to skip it...):
You only want specific components? Or only the web client? A mix thereof? Use this. Otherwise -> repo package.

eschwartz wrote:

Is this more than just "it uses more disk space"? The dependencies you're splitting out into split packages are optdepends in the repo package so I don't really see what PRACTICAL benefit you're getting here by splitting it.

Not all of them are. This is both saving space and allows you to have more components disabled, have the machine not even function as a host, etc but I've already explained that 3 times now.

eschwartz wrote:

If you do need to split it, why not just fork community/cockpit, build it yourself, and do the additional component splitting from the source install? This is generally how packages that do things slightly differently from existing repo packages do it.

I've also already explained this. I could, but I didn't see a point as that would mean I also need to literally maintain a copy of everything the official package already does.
If that would immediately make it allowed on the AUR I suppose it could be worth it to make that change but for me it was a lot more efficient to just use it as the base and only have to manage the changes needed to split it, not everything else as well.


But in summary, it's clear there is serious backfire for this to be on the AUR in its current form. From my perspective, we've now entered a semantics discussion that is very much up to personal taste and interpretation of which nothing is explicitly covered anywhere in the guidelines. But the gut feeling I had of that being the case is exactly why I put it up here initially in the first place instead of just throwing it on there.
I had hope that maybe I was just over-thinking it and aside from some technical items (such as the tar thing) it'd be fine but it looks like it is way to much of a 'grey' case.
I don't think it's worth the pain of having to fight around semantics and interpretations to get this specifically on the AUR. I do hope that maybe this can result in having some unwritten rules or expectations from the Arch team get made explicit in the related guidelines (e.g. changing some uses of 'should' to 'must' maybe, if/where applicable).

Lastly, I'm throwing my last (current) version that just splits it here for the record and future visitors.
Barring the fork variant being OK I don't think I'll be updating it here.
> EDIT: I just noticed there is an (outdated) cockpit-minimal on the AUR, which is actually less minimal than you can get with this and more similar to the official repo package..


pkgbase=cockpit-split
pkgname=('cockpit-split'
         'cockpit-doc'
         'cockpit-bridge'
         'cockpit-kdump'
         'cockpit-networkmanager'
         'cockpit-packagekit'
         'cockpit-shell'
         'cockpit-storaged'
         'cockpit-systemd'
         'cockpit-tuned'
         'cockpit-users'
         'cockpit-ws')
pkgver=228
pkgrel=1
pkgdesc='A systemd web-based user interface for Linux servers. Fully splits the sub-components out for maximum customization.'
arch=('x86_64')
url='https://cockpit-project.org/'
license=('LGPL')
source=("https://archive.archlinux.org/packages/c/cockpit/cockpit-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst")
noextract=("cockpit-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst")
sha256sums=('514cf3c24af951c20784066960796a483e5a9b4a30447ba1246ea0ae0be81275')

package_cockpit-split() {
	pkgdesc='Meta-package bridging all cockpit-* sub-modules.'
	arch=('any')
	optdepends=("cockpit-bridge: the system agent"
	            "cockpit-doc: deployment and developer guide"
	            "cockpit-kdump: manage kernel crashdumps in the web interface"
	            "cockpit-networkmanager: manage network connections in the web interface"
	            "cockpit-packagekit: manage packages in the web interface"
	            "cockpit-shell: shell access through the web interface"
	            "cockpit-storaged: manage hard disks in the web interface"
	            "cockpit-systemd: manage servives in the web interface"
	            "cockpit-tuned: manage udev/sysctl/sysfs in the web interface"
	            "cockpit-users: manage users in the web interface"
	            "cockpit-ws: web-based user interface"

	            # Below are from the original package.
	            "cockpit-dashboard: show up to 20 servers on a dashboard in the web interface"
	            "cockpit-docker: manage docker containers in the web interface"
	            "cockpit-machines: manage virtual machines in the web interface"
	            "cockpit-pcp: show performance metrics in the web interface"
	            "cockpit-podman: manage podman containers in the web interface")
	provides=('cockpit')
	conflicts=('cockpit')

	install -dm755 "${pkgdir}/usr/share/cockpit"

	bsdtar -C "${pkgdir}" -xf "cockpit-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst" \
		usr/share/man/man1/cockpit.1.gz \
		usr/share/metainfo/cockpit.appdata.xml \
		usr/share/pixmaps/cockpit.png
}

package_cockpit-doc() {
	pkgdesc='The Deployment and Developer Guide.'
	arch=('any')
	depends=('cockpit-split')

	bsdtar -C "${pkgdir}" -xf "cockpit-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst" \
		usr/share/doc/cockpit
}

package_cockpit-bridge() {
	pkgdesc='The server-side component that runs commands on the system on behalf of the web-based interface.'
	depends=('cockpit-split' 'cockpit-shell' 'cockpit-systemd' 'libssh' 'json-glib' 'polkit')

	bsdtar -C "${pkgdir}" -xf "cockpit-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst" \
		etc/cockpit/machines.d \
		usr/share/cockpit/base1 \
		usr/share/cockpit/ssh \
		usr/share/polkit-1/actions/org.cockpit-project.cockpit-bridge.policy \
		usr/share/man/man1/cockpit-bridge.1.gz \
		usr/bin/cockpit-bridge \
		usr/lib/cockpit/cockpit-askpass \
		usr/lib/cockpit/cockpit-ssh
}

package_cockpit-kdump() {
	pkgdesc='A module for managing kernel crash dumps.'
	depends=('cockpit-split' 'kexec-tools')
	arch=('any')

	bsdtar -C "${pkgdir}" -xf "cockpit-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst" \
		usr/share/cockpit/kdump \
		usr/share/metainfo/org.cockpit-project.cockpit-kdump.metainfo.xml
}

package_cockpit-networkmanager() {
	pkgdesc='A module for managing networking, using NetworkManager.'
	depends=('cockpit-split' 'networkmanager')
	arch=('any')

	bsdtar -C "${pkgdir}" -xf "cockpit-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst" \
		usr/share/cockpit/networkmanager
}

package_cockpit-packagekit() {
	pkgdesc='A module for managing packages, using packagekit.'
	depends=('cockpit-split' 'packagekit')
	arch=('any')

	bsdtar -C "${pkgdir}" -xf "cockpit-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst" \
		usr/share/cockpit/apps \
		usr/share/cockpit/packagekit
}

package_cockpit-shell() {
	pkgdesc='A module providing a shell.'
	depends=('cockpit-split')
	arch=('any')

	bsdtar -C "${pkgdir}" -xf "cockpit-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst" \
		usr/share/cockpit/shell
}

package_cockpit-storaged() {
	pkgdesc='A module for managing storage, using udisks2.'
	depends=('cockpit-split' 'udisks2')
	arch=('any')

	bsdtar -C "${pkgdir}" -xf "cockpit-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst" \
		usr/share/cockpit/storaged \
		usr/share/metainfo/org.cockpit-project.cockpit-storaged.metainfo.xml
}

package_cockpit-systemd() {
	pkgdesc='A module for systemd services.'
	depends=('cockpit-split')
	arch=('any')

	bsdtar -C "${pkgdir}" -xf "cockpit-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst" \
		usr/share/cockpit/systemd
}

package_cockpit-tuned() {
	pkgdesc='A module for udev/sysctl/sysfs.'
	depends=('cockpit-split' 'tuned')
	arch=('any')

	bsdtar -C "${pkgdir}" -xf "cockpit-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst" \
		usr/share/cockpit/tuned
}

package_cockpit-users() {
	pkgdesc='A module for managing users.'
	depends=('cockpit-split' 'accountsservice')
	arch=('any')

	bsdtar -C "${pkgdir}" -xf "cockpit-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst" \
		usr/share/cockpit/users
}

package_cockpit-ws() {
	pkgdesc='A systemd web-based user interface to interact with systems using cockpit-bridge.'
	depends=('cockpit-split' 'gnutls' 'json-glib')
	optdepends=('krb5: kerberos authentication support')
	backup=('etc/pam.d/cockpit' 'etc/cockpit/ws-certs.d')

	bsdtar -C "${pkgdir}" -xf "cockpit-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.zst" \
		etc/cockpit/ws-certs.d \
		etc/issue.d \
		etc/motd.d \
		etc/pam.d \
		usr/share/cockpit/branding \
		usr/share/cockpit/motd \
		usr/share/cockpit/static \
		usr/share/locale \
		usr/share/man/man1/cockpit-desktop.1.gz \
		usr/share/man/man5 \
		usr/share/man/man8 \
		usr/lib/systemd/system \
		usr/bin/remotectl \
		usr/lib/cockpit/cockpit-desktop \
		usr/lib/cockpit/cockpit-session \
		usr/lib/cockpit/cockpit-tls \
		usr/lib/cockpit/cockpit-ws \
		usr/lib/cockpit/cockpit-wsinstance-factory \
		usr/lib/security \
		usr/lib/sysusers.d \
		usr/lib/tmpfiles.d
}

Last edited by Omar007 (2020-09-17 20:21:50)

Offline

#10 2020-09-17 20:52:37

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: PKGBUILD review request: cockpit-split

Omar007 wrote:

I've explained my motivation there and in the initial post. I'm not sure how else I'd need to word it for you.

Allow me to reiterate: I don't see how that part of your post contributes to any understanding. The question was "why is the split needed". You answered by re-asserting that you do in fact consider it to be needed. Re-asserting the premise is most likely NOT an answer to anyone who is questioning your premise.

"Why don't you just install unneeded files which do no harm" -> "this PKGBUILD is for the case where you don't install them" -> "um, how does that answer anything"

EDIT: To put it another way:

You posted about a goal you had.
I acknowledged I comprehended your goal, then I questioned that I'm not convinced your goal is valuable / superior-to-the-current-state, and asked "why do you have this goal".
You responded with a response that would be suitable for telling someone what your goal is, if they didn't already know.
I got snarky about "well yes, I know your goal, stop telling it to me already and get to the point".

Omar007 wrote:
eschwartz wrote:

Is this more than just "it uses more disk space"? The dependencies you're splitting out into split packages are optdepends in the repo package so I don't really see what PRACTICAL benefit you're getting here by splitting it.

Not all of them are. This is both saving space and allows you to have more components disabled, have the machine not even function as a host, etc but I've already explained that 3 times now.

Most packages in Arch are build with --enable-kitchen-sink on the rationale that more functionality is good. Saving space isn't a huge concern as a whole for the distro, but nearly all the space you do save is due to polkit (which will anyways be installed in various circumstances like "gtk3 is installed on the system"). Saving space probably does not necessitate splitting apart most of these subpackages even if you want to prevent polkit from being installed.

I think the main issue here seems to be "have more components disabled". What are the consequences of having a component enabled that you don't need? Does cockpit not come with a mechanism to configure modules as installed-but-disabled?

Omar007 wrote:
eschwartz wrote:

If you do need to split it, why not just fork community/cockpit, build it yourself, and do the additional component splitting from the source install? This is generally how packages that do things slightly differently from existing repo packages do it.

I've also already explained this. I could, but I didn't see a point as that would mean I also need to literally maintain a copy of everything the official package already does.
If that would immediately make it allowed on the AUR I suppose it could be worth it to make that change but for me it was a lot more efficient to just use it as the base and only have to manage the changes needed to split it, not everything else as well.

One benefit of doing it from source is the package will be able to be rebuilt in order to cope with dependency soname bumps, rather than being carefully synced with specific pkgrels from the official repos (and it is clear to any user how to do this, rather than needing to figure out some undocumented mechanism to sync with [community], get things working for users with the testing repos enabled, etc.). There is a reason -bin packages don't typically link to external libraries at all (other than the ever-stable libc.so.6).

This is something that AUR packages typically do concern themselves with, and I don't think it is just a semantics game. It seems reasonable to me to think that it would be simple to maintain that copy, and less prone to unpredictable de-syncing breakage.

Last edited by eschwartz (2020-09-17 21:00:51)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#11 2020-09-17 21:32:42

Omar007
Member
Registered: 2015-04-09
Posts: 368

Re: PKGBUILD review request: cockpit-split

eschwartz wrote:

I acknowledged I comprehended your goal, then I questioned that I'm not convinced your goal is valuable / superior-to-the-current-state, and asked "why do you have this goal".

eschwartz wrote:

I think the main issue here seems to be "have more components disabled". What are the consequences of having a component enabled that you don't need? Does cockpit not come with a mechanism to configure modules as installed-but-disabled?

This is probably indeed where that miscommunication seems to stem from. As far as I know, you can't.
Some may happen to not work if their dependencies aren't fulfilled (e.g. cockpit-storaged <-> udisks2) but otherwise, as far as I know, it will be available. If I've missed something and you know otherwise, please tell!
My explanations where based on that being a given so I didn't even thing twice about this possibly creating confusion. Cognitive biases ftw I guess.

eschwartz wrote:

One benefit of doing it from source is the package will be able to be rebuilt in order to cope with dependency soname bumps, rather than being carefully synced with specific pkgrels from the official repos (and it is clear to any user how to do this, rather than needing to figure out some undocumented mechanism to sync with [community], get things working for users with the testing repos enabled, etc.). There is a reason -bin packages don't typically link to external libraries at all (other than the ever-stable libc.so.6).

That is indeed a valid concern for the cockpit-bridge and cockpit-ws sub-packages as these actually contain compiled binaries.
My view on this is that it is 'out-of-date' if it didn't match the repo package version (even though the component versions do not even need to match versions exactly).
That is how I regarded it locally but I agree with you that that is not a given at all and that may not suffice for the AUR.

eschwartz wrote:

This is something that AUR packages typically do concern themselves with, and I don't think it is just a semantics game. It seems reasonable to me to think that it would be simple to maintain that copy, and less prone to unpredictable de-syncing breakage.

Well, based on this not being explicit and very up to interpretation I'd say it is but we can probably agree to disagree on that.
I do agree with the part of concerning about breakage so if there is agreement that this would otherwise have value and a source based variant based on/forked off of the official repo package would be OK, I'd be willing to make that change so others can benefit from this.

Offline

Board footer

Powered by FluxBB