I mostly stick to things in the repos, if theres something I want that’s not yet packaged I package it myself because Gentoo packages are fancy bash scripts with libraries (eclasses) to handle the normal make && make install sort of things for most build systems

I still use X11 because one of my necessary voip apps (mumble) doesn’t yet support wayland’s method of global hotkeys.

Otherwise I don’t particularly care one way or the other.

Heres an example, ebuilds are named package-version.ebuild and that version in the filename is used to define variables (such as $P here which is the name-version) to make new versions as simple as copying the ebuild with the new version in the filename.

use_enable is used to generate the --enable-(option) or --disable-(option) as set by the user.

For more info, see the devmanual. They’re nice relatively straightforward bash like PKGBUILDs, but with the repetitious stuff taken out.

# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=8

DESCRIPTION="GNU charset conversion library for libc which doesn't implement it"
HOMEPAGE="https://www.gnu.org/software/libiconv/"
SRC_URI="ftp://ftp.gnu.org/pub/gnu/libiconv/${P}.tar.gz"

LICENSE="LGPL-2+ GPL-3+"
SLOT="0"
KEYWORDS="~amd64 ~ppc ~sparc ~x86"
IUSE="nls"

RDEPEND="!sys-libs/glibc"
DEPEND="${RDEPEND}"

src_configure() {
	econf $(use_enable nls)
}

one of the reasons I love gentoo is how easy it is to package things for it.

You know how for pkgbuilds you have to explictly write out the whole configure make make install stuff that pretty much every package uses some variation on? Gentoo abstracts that out to libraries (eclasses) that handle that sort of thing for each build system so you can focus down on anything unique to the package, like build system options.

why did you link to a kbin view of another post right here on !linux@lemmy.ml ?

you’re probably looking for getopt/getopts. one big difference between them is getopt handles --long options while getopt doesn’t.

other example

eh, its true if you want it to be signed by microsoft, which some projects have forked out for, buut it was put into the spec for x86_64 systems that users can replace the keys. so you can make your own keys, and if you want to dual boot add microsoft’s keys to the ok to boot list.

one of the signed projects is a shim that lets you approve whatever you want more or less; pretty much everything that talks about MOK refers back to this shim. many distributions use this shim

kubuntu is already literally just a package.

if you just install kubuntu-desktop (or something similar) from any buntu flavor you get it.

package myself; I chose Gentoo (and previously Arch) in part because its reasonably easy to package things there.

Most build systems are covered by eclasses ( libraries) that handle the repetitive minutia every package that build system needs.

Here’s the tuba ebuild for example (from GURU, the Gentoo equivalent of the AUR), 90% of it is just listing the dependencies and telling it to use a few eclasses to handle everything else.

Oh, and here’s the lemmy back end ebuild, the giant wall of crates is automatically generated/updated from a tool that reads the cargo files. (needed because Gentoo doesn’t allow internet access during the build for normal packages so crates are downloaded ahead of time)

There’s nothing wrong with solid old file systems; ext4 is almost 17 and no one complains about it,

nginx is fine, lemmy uses it inside of its docker images too. I don’t find it’s config scary(template lemmy internal nginx config)

dnf is to apt as rpm is to dpkg.

The first pair are the nice user friendly front ends that pull things in and install from the repos.

The latter are the guts that directly handle the raw packages and are used by the frontends.

The closed source ones were good enough for quite a while; it was amd’s closed source ones that were mediocre.

Course now that wayland is around Nvidia bungled their support for it ( trying to force their standard rather than what had been accepted by others), and Amd’s open drivers have been solid the entire time afaik.