this post was submitted on 07 Jul 2023
28 points (100.0% liked)

Linux

47952 readers
1522 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
top 13 comments
sorted by: hot top controversial new old
[–] [email protected] 9 points 1 year ago (4 children)

Never wrote RPM specs because I generally dislike RPM-based distributions (Fedora was a really bad experience when I tried it), but from a quick Google search they're very similar.

I kinda like the format at a glance, seems pretty comparable in terms of what you put in there. Definitely less painful than debhelper.

I guess one of the advantages of PKGBUILD is that they're essentially bash scripts that gets sourced by the tools, so they're incredibly simple and don't require parsing a custom format. You can:

#!/bin/sh
source PKGBUILD
prepare
build
check
package

That comes with disadvantages in that reading the PKGBUILD is inherently unsafe, and it was the cause of many concerns back in the days with tools like yaourt, which pretty much just blindly sourced it to get the variables out, which means immediate code execution just loading it from the AUR.

[–] [email protected] 2 points 1 year ago (1 children)

Do you also dislike openSUSE and openMandriva?

[–] [email protected] 1 points 1 year ago (1 children)

I haven't really given those a try, ArchLinux happens to have ended my distro-hopping 10ish years ago.

Started with Ubuntu 7.04, bailed when they released the first Unity, went through a few Ubuntu spins, then Debian, then Fedora 15 (that one had lots of issues, the installer repeatedly crashed on me and all, it corrupted my partition table forcing me to testdisk to recover, they didn't have Chromium or any proprietary codecs and apps). I ended up back on Ubuntu for a bit and then took the Arch dive, and been happy ever since and never felt the desire to learn another distro if it doesn't have significant advantages.

My next distro will probably be something like NixOS, the concept is quite appealing but my VM experiments so far haven't convinced me to get rid of Arch just yet. Might start using it on my servers for that sweet immutability and centralized config.

[–] [email protected] 2 points 1 year ago (1 children)

Haha I'm right there with you. The timeline isn't as vast but Arch ended my distrohoppong and NixOS is the only thing really catching my eye these days.

I jumped around various Ubuntu spins, settled on Linux Mint for a while, tried out ElementaryOS for a brief moment, went back to Ubuntu spins then eventually went with Arch in 2019 and haven't looked back.

The immutability and configuration of Nix seems so appealing but at this point I'm really comfortable with Arch and it does everything I need in a pretty sane way so idk if I'd switch anytime soon.

[–] [email protected] 1 points 1 year ago

The immutability and configuration of Nix seems so appealing but at this point I’m really comfortable with Arch and it does everything I need in a pretty sane way so idk if I’d switch anytime soon.

Back in 2018, I had the experience of using NixOS. At that time, I noticed that the Nix language had a striking resemblance to Haskell, which stirred up feelings of anxiety within me.

[–] [email protected] 2 points 1 year ago

I think while yaourt was called out for it, there are still issues with doing it this way; it's the reason the AUR requires a .SRCINFO file nowadays https://wiki.archlinux.org/title/.SRCINFO

[–] [email protected] 1 points 1 year ago (1 children)

I did not know you could just source a PKGBUILD. I'm certain I'll remember this instead of the correct makepkg flag to run this ot the other stage only.

[–] [email protected] 1 points 1 year ago

I mean it's not going to make you a package if you just do that, the real tools do other things in-between but it shows the general simplicity Arch went with there.

[–] [email protected] 1 points 1 year ago

That comes with disadvantages in that reading the PKGBUILD is inherently unsafe, and it was the cause of many concerns back in the days with tools like yaourt, which pretty much just blindly sourced it to get the variables out, which means immediate code execution just loading it from the AUR.

However, the AUR helpers in question, which are not official tools, were to blame. Some developers of these tools could not or did not want to solve the problem. According to https://wiki.archlinux.org/title/AUR_helpers, almost no AUR helper sources the files automatically nowadays.

[–] [email protected] 3 points 1 year ago (1 children)

I've either never dealt with RPM specs before or it's been so long that I can't remember. Therefore, I can only make a statement about PKBUILD files.

Such files are relatively easy to create and read, as they are basically shell scripts. Thus, if you use AUR, for example, you can easily check them before an installation or an update to see whether the creator has done everything correctly or whether he has changed the file with malicious intent.

For example, a typical PKBUILD file looks like this.

# Maintainer: Alad Wenter <https://github.com/AladW>
# Co-Maintainer: Cedric Girard <cgirard [dot] archlinux [at] valinor [dot] fr>
pkgname=aurutils
pkgver=17.2
pkgrel=1
pkgdesc='helper tools for the arch user repository'
url='https://github.com/AladW/aurutils'
arch=('any')
license=('custom:ISC')
source=("$pkgname-$pkgver.tar.gz::$url/archive/refs/tags/$pkgver.tar.gz")
changelog=aurutils.changelog
install=aurutils.install
sha256sums=('65efed873facf06ec73b012d94c110f35e45d3057eda2bc85983a3c8c6ce2c81')
depends=('git' 'pacutils' 'curl' 'perl' 'perl-json-xs' 'bash')
optdepends=('bash-completion: bash completion'
            'zsh: zsh completion'
            'devtools: aur-chroot'
            'vifm: default pager'
            'ninja: aur-sync ninja support'
            'bat: view-delta example script'
            'git-delta: view-delta example script'
            'python-srcinfo: sync-rebuild example script')

build() {
    cd "$pkgname-$pkgver"
    make AURUTILS_VERSION="$pkgver"
}

package() {
    cd "$pkgname-$pkgver"
    make PREFIX=/usr ETCDIR=/etc DESTDIR="$pkgdir" install
}
[–] [email protected] 1 points 1 year ago

Such files are relatively easy to create and read, as they are basically shell scripts.

I agree. I lean towards writing in Bash script instead of learning yet another special-purpose language. Nonetheless, the RPM spec doesn't seem to pose any additional difficulty.

[–] [email protected] 2 points 1 year ago (1 children)

@veer66
One is that it's a shell script, so it feels like there's less to learn. The accuracy of that can be debated.

I've not packaged RPMs in a fair while, so I can't make a more thorough comparison.
@linux

[–] [email protected] 1 points 1 year ago

One is that it’s a shell script,

Using Bash sounds convincing to me.