Pacman-5.0 Released | Hacker News Reader

Pacman-5.0 Released

allanmcrae.com

66 pointsferrari860849 comments

Some of the comments here reminded me of another recent post, and in particular these statements...

>Do not start an open source project if you need praise, warmth and love from your fellow human beings. [ https://news.ycombinator.com/item?id=11053810 ]

>Folks forget that most FOSS work is volunteer & berating the hackers who make it won't help one bit. [ https://news.ycombinator.com/item?id=11054809 ]

Well, the front page did recently have people complaining about a bunch of paid products (github, twitter, everything IBM does). I'd expect us to treat open source projects like any other, and part of that is by noting their failings. Incentivising fixing those (or doing the fixing) does happen in different ways, but this isn't a development forum :)

I'd say:

> don't post anything publicly if you want only [warm fuzzy feelings]"

There is 'total compensation' to consider, though. If you're getting paid big money to work on something, you can probably swallow the criticism fairly easily. But if you're not being paid any money, and there are zero warm fuzzy feelings, it's harder to stay motivated.

I wish the package-query maintainers would stop hard coding the pacman version in their PKGBUILD as requirements. It means that every time there's a minor release of pacman, updating breaks for the 6 hours it takes the AUR guys to catch up.

There's tons of alternatives to yaourt, thankfully.

But AFAIK they all use package-query (pacaur does IIRC).

`packer` does not: https://aur.archlinux.org/packages/packer/

https://aur.archlinux.org/packages/package-query/

Only pacupg does, according to this. pacaur, cower, apacman, packer, and all the others (https://wiki.archlinux.org/index.php/AUR_helpers) don't.

I still manually build off the AUR and don't use AUR package management.

yaourt & co. are very useful when you have to build packages with tons of dependencies. I had to build the 32-bit gstreamer stuff from AUR for some Wine work recently, and it saved me tons of time. Just remember to set --noconfirm or it'll ask you to confirm a dozen things for every package :)

> or it'll ask you to confirm a dozen things for every package

I bloody well hope it asks before running unverified code off the internet with root permission!

Yes, obviously you should know what the AUR is before you use it.

Big reason why I use OpenSUSE at work.

A bunch of AUR packages, like Yaourt itself, download their sources over HTTP and verify them with MD5, so even if you trust the AUR maintainer you have no idea if you're getting the same file they did.

It's sad that makepkg still uses MD5 by default in this day and age because "it's faster".

File hashes are only supposed to protect against download errors, not against malicious intent.

MD5 is good enough for that, and makepkg supports GPG for actual verification.

I assure you Yaourt doesn't have an .asc signature either.

They should be using SHA-256, or Blake 2 if they think the extra seconds spent verifying matter, but insisting on using MD5 is pretty much going out of your way to increase your attack surface. There is no reason to use it in a modern system.

> I assure you Yaourt doesn't have an .asc signature either.

That's yaourt's problem, not makepkg's or the AUR's.

> They should be using SHA-256, or Blake 2 if they think the extra seconds spent verifying matter, but insisting on using MD5 is pretty much going out of your way to increase your attack surface.

It doesn't matter what algorithm you use, file hashes are not a security feature. Use GPG!

The widespread use of MD5 in AUR is because that is the default in makepkg, making it both AUR's and makepkg's "problem".

> It doesn't matter what algorithm you use

Of course it matters, they have different guarantees. A secure hash would at least guarantee that the file you get is the same one the packager got, MD5 doesn't. They are refusing to use strictly better alternatives out of pure stubbornness.

Still no parallel download support ?

https://bugs.archlinux.org/task/20056

Why isn't a XferCommand that by itself downloads chunks concurrently good enough for you?

There are multiple ways to do it, but the defaults matter.

XferCommands are confusing to write. I have one, and it makes my downloads faster, though I wouldn't have a clue how to write it myself. Here's what I have currently:

    XferCommand = /usr/bin/printf 'Downloading ' && echo %u | awk -F/ '{printf $NF}' && printf '...' && /usr/bin/aria2c -q --allow-overwrite=true -c --file-allocation=none --log-level=error -m2 --max-connection-per-server=2 --max-file-not-found=5 --min-split-size=5M --no-conf --remote-time=true --summary-interval=0 -t5 -d / -o %o %u && echo ' Complete!'

It's fast, but doesn't have download progress. I had another one, which printed several lines of output per file (but did have progress!).

My point is, the fact that you can make pacman download stuff quickly as-is, doesn't mean that inbuilt support wouldn't be beneficial for everyone who doesn't know how their downloading program works back-to-front.

iirc, apt has support for it (it will only download a single thing at a time from a given host, but does appear to download different things from different hosts at the same time).

I believe gentoo's emerge also has support (though I'm not as sure here as I typically have the downloads happen in the background while building).

The overall goal here is to more effectively utilize the available bandwidth on the client side even when there are limitations a given server.

It's great that we can customize how to download 1 package at a time. But there is room for improvement.

As Dan (toofishes) would say, "patches welcome" :)

That would be nice, but perhaps a bit rough on the free CDNs who are nice enough to host the packages?

I don't think it would be. Parallel downloads would simply mean that more of the client's bandwidth is consumed by connecting to multiple mirrors at once. Each individual mirror will, at most, still supply the same total bytes and bandwidth (though it's likely that being able to download form multiple mirrors at once would end up lowering an individual mirror's overall load by more effectively spreading downloaders between different mirrors)

Do you really need that? I max out any bandwidth I throw at good mirrors. Only the database syncing could be faster.

Parallel downloads are available, albeit via a 3rd party tool, `Powerpill` [1]

[1] https://wiki.archlinux.org/index.php/powerpill

Personally though, I've never had an issue with the performance of `pacman`. Even without parallel downloads I've found `pacman` generally outperforms most other package management tools I've used.

I just do this in an overnight cron: `pacman -Syuw --noconfirm`

It pulls down all the updated packages but doesn't install. The packages are then ready for update when you are.

I don't see the need for it.

Someone already got an implementation of a hook? No idea how it should be used...

It's explained in the linked article and it even links to an examples repo: https://github.com/andrewgregory/pachooks

Am I the only one that read the title and thought this was Pacman the game? I am surprised they let you use the name for something else considering it's supposed to be highly copyright-protected.

Sidenote: I am having trouble finding the link to an explanation what this really is. any help?

pacman is the package manager for archlinux: https://wiki.archlinux.org/index.php/pacman

The game you're thinking of is 'Pac-Man' (hyphenated).

This is a package management tool for ArchLinux. Similar to 'yum' for RHEL. Or Debians 'apt-*', 'dpkg' tools.

It also work on Windows, it's what MSYS uses for package management, convenient to avoid having to install CYGIN or using virtualisation.

msys uses pacman? Is there another msys than the one at mingw.org[0] ? I believe you but I just can't find any reference to pacman there.

[0] http://www.mingw.org/wiki/msys

I googled 'msys pacman' and it seems that msys2 uses pacman: http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/

He means MSYS2 https://msys2.github.io/

It's great, it has a wonderful collection of libs, sometimes it can feel a little bit too cutting edge, but after the stagnation of Mingw I'm not complaining about that.

It's open source software so it can (given enough time and motivation) be ported to whatever platform you wanted. Because of this I think there's a few other OSs / distro forks that also use pacman. But primarily, `pacman` is developed by ArchLinux maintainers for ArchLinux.

It is, for sure, a little bit confusing :) http://p.fu86.de/1454938855-32650.png

Not that confusing really - the two applications couldn't be more different in use.

"Pacman" is abbreviated from "package manager" while "Pac-Man" is derived from "Puck Man", named so because the yellow avatar looked like a hockey puck. (the reason for the name change is quite interesting too[1]).

While it's true that the ArchLinux devs do play on the name similarities (there's even an easter egg to turn the `pacman` progress bar into a little Pac-Man eating up ASCII pills[2]), I think most people who might confuse the two wouldn't be familiar with the package manager anyway. And those who are familiar with `pacman` are likely technical enough to tell the difference.

[1] Renamed because of worries that some US audiences might vandalise the Puck into Fuck.

[2] Put 'ILoveCandy' (without quotes) under the [options] in /etc/pacman.conf

Names aren't copyrighted, they're trademarked. And since:

a) Arch Linux isn't selling pacman. b) I don't believe Namco still own a registered trademark for Pacman. And they probably don't make enough money from it for them to win a lawsuit about it (trademarks require a reasonable commercial interest in order to be protected).

So there almost certainly isn't a legal issue. IANAL.

The trademark is also for 'Pac-Man' not 'pacman'.

That's why I can get away with selling my home-made "cocacola" without legal issues.

Bandai/Namco certainly do hold multiple registered trademarks on PAC-MAN, at least in Europe. They cover not just the video game side[1], but everything from kitchen appliances[2] to lotteries[3] and even beer[4].

[1] https://www.ipo.gov.uk/tmcase/Results/4/EU004977906

[2] https://www.ipo.gov.uk/tmcase/Results/4/EU000361600

[3] https://www.ipo.gov.uk/tmcase/Results/4/EU003574076

[4] https://www.ipo.gov.uk/tmcase/Results/4/EU008125031

Namco still own the trademark, they do ill-advised attempts to revive the franchise every few years. Arch Linux best defense here is that it's not in the same business, so there's no risk of confusion (trademarks aren't all-encompassing).

Namco is very involved with Pacman and still involved with arcade equipment based on it. Here's something my friends at Raw Thrills just introduced a little while ago:

https://www.youtube.com/watch?v=koLvoCMHCrI

From what I've heard on the inside, Raw Thrills has been actively working on new Pacman games based on the original 1980 source code given to them by Namco.

TLDR: They definitely still own the trademark and they are still making money on it.

I thought the same. It didn't occur to me that this wasn't about the game..

Reply on news.ycombinator.com