Arch Linux User Repository

@qtmax: Disk encryption seems to work for me as is - could you check if you might be affected by this bug: https://bugs.archlinux.org/task/78052 ?

The last update removed /dev/pts from initrd, which broke systemd-askpass support in Plymouth. Could you readd the following line to plymouth.initcpio_install, so that users could enter the disk encryption password in Plymouth as before?

add_dir /dev/pts

One note, if using systemd for your initrd, I found that using the plymouth hook and the sd-encrypt hooks works for me after the latest round of changes. (wasn't sure about the latter)

Just to wade in here a little bit. For the debian/ubuntu example - It's worth noting that ubuntu has its own repository list (/etc/apt/sources.list), because installing packages is fundamentally a distro-specific task. So even if in this case, the "arch specific" cookbook may feel like it's just the logo, actually everything in all AUR packages is arch specific. Maybe you get lucky and it happens to work, but that's just happenstance.

One thing I personally appreciate about the PKGBUILD system is that it's straightforward for me as a user to understand how packages are created (and not just the final tarball). Thus, if I need to make a downstream tweak, it's something I can do (and e.g. rua can even maintain my personal patches for me).

The solutions to this problem are (in no particular order): 1. Downstream distros should maintain downstream repositories 2. Use a distro-agnostic package (e.g. flatpak) 3. Roll the dice and try to use packages for a different distro on your machine 3a. Write and share the documentation so other interested parties can follow in your footsteps

Ah, I thought that was a change you added. Thanks for explanation. Now I get how the additional code got there. Community is an Arch repo, so Arch specific changes are perfectly fine, no argument here. However, I don't get why plymouth-git is still mirroring plymouth that became community/plymouth. So what is the point of having plymouth-git? I mean, the community one is already compiled and git is compiled by us (which can have various perks), but the name suggests it is just a git version, no more, no less, but in reality it's not. Do you plan to change it? I know that you explained that "the expectation is that the -git package does not modify the 'base' package as found in the Arch repos" but is it really? I always thought that the git is just pure git. The assumption you posted would make all git packages “vulnerable” to any community changes, which doesn't make sense. There could be some reasons why someone may want to have pure git instead of a modified version. If it's simply mirroring community, it forces for manual cleaning of PKGBUILD, which not every use will know he/she has to do, because again - the name doesn't tell you that, which is misleading.

@michaldybczak: OK, I'll try to spell this out for you as clearly as I can (although I really shouldn't bother, because you could find this out yourself if you were willing to spend just one iota of effort on educating yourself instead of just having a tantrum).

1. AUR/plymouth-git is mirroring AUR/plymouth
2. AUR/plymouth is moved to community/plymouth
3. In the process community/plymouth changes
4. AUR/plymouth-git continues mirroring community/plymouth

So like I already said: So if you have an issue with this, please feel free to take things up with the plymouth maintainer in community. Oh, and do make sure to remind them of their obligation to make sure their package also works for all the Arch derived distros. I'm sure they'd love to hear about that.

@Taijian, you said "package does not modify the 'base' package as found in the Arch repos beyond what is necessary to make it work/build as a -git version". I'm confused. The base package already worked for years, and your modification is an extra addition that just gets in the way for some users. Modification was unnecessary and stands in contradiction to what you just said. Or maybe I misunderstood something, but the problem came because there was added a script that builds Arch specific plymouth theme. Without it and without it referencing to Arch specific files, all works like in the base package. Again, this was without warning and explanation. People were using this package for years, and you just made it harder to install for some.

@michaldybczak: Thank you for your long and insightful comment. I learned a lot about your way of thinking. Please allow me to comment.

1. I strikes me as a somewhat unusual approach to accuse someone - whom you want to do you a favor - of being 'ignorant'(2x), 'arrogant'(2x), 'motivated by egoism', 'following bad practice and abusive of AUR customs'. But hey, I'm just a behavioural psychologist, what do I know about how to motivate people. Do let me know how your approach works out!

2. You seem quite sure of yourself and of your judgement. Have you ever stopped to think and consider that maybe there are reasons for my behaviour that you have just never considered so far? That - shockingly - there might be thoughts and concepts out there in the world that you have so far never encountered? Maybe people disagreeing with you are not just ignorant or malicious, but are looking at the world from a diffent point of view that you have just not considered so far?

3. You rightly state that the name of an AUR package should reflect whether or not there have been any modifications to the 'base' package in making the AUR package. Where you seem to be confused is in what the 'base' is in relation to plymouth-git. In general, when a -git version of a package that is already in the Arch repos is added to the AUR, the expectation is that the -git package does not modify the 'base' package as found in the Arch repos beyond what is necessary to make it work/build as a -git version. And this is exactly what is happening here. Plymouth-git is mirroring community/plymouth, because that is the 'base' package it is supposed to be mirroring. I'm sure, if you give it a bit of thought, you will understand why this is so.

4. So if you have an issue with this, please feel free to take things up with the plymouth maintainer in community. Oh, and do make sure to remind them of their obligation to make sure their package also works for all the Arch derived distros. I'm sure they'd love to hear about that.

5. I am very much looking forward to your complaint to the TUs about my bad packaging practices and my abuse of AUR customs!

@Taijian, while I agree that AUR is for Arch packages, the comparison you made are not fully accurate. 1. First, Arch is not a singular distro like in the past but a base for a variety of distros, just like Debian is the base for various spin-offs. Looking on AUR as something exclusive to Arch only is just ignorant and arrogant. 2. Second, in this particular case, the PKGBUILD adds additional instructions that made it reliable on packages from Arch repos only. This instruction is not necessary at all, it should be optional. The package plymouth-git will work for all Arch based distros, but the added option made it exclusive and problematic. 3. While I agree that Arch stands in the name of AUR, this addition is unnecessary. It's exactly like Apple making everything they can to make your life harder and exclude every third parties. They have financial incentive to do so, but the only incentive to make an AUR package reliant on Arch repos and files only is just arrogance and egoism, in the best case, it's just ignorant. 4. This is the AUR package maintainer right to do what he desires with the package, it's open source after all and, I assume, the license of plymouth allows it. However, if he alters the base package, it should be reflected in the name. So that is my last problem. You either provide plymouth-git or some personal spin-off. If you know that the package is modified, you are warned and can check what the modifications were about. If you say you provide the base package while you are not, it's just a bad practice and abuse of the AUR customs.

@Anagastes: I think you have a pretty serious misconception here about what AUR PKGBUILDs are and are not.

A PKGBUILD is a recipe for building a particular package. It lists a number of ingredients in the depends= and makedepends= arrays and then has instructions on how to proceed with these ingredients towards creating a functional and installable package.

In listing these ingredients, it does assume that you will actually be using the exact same ingredients, because - if you are not - then the rest of the instructions might not work for you. Now, because this is the AUR, as in Arch User Repository, the assumption is that you will be using the packages (ingredients) from the Arch repos - and then the recipes will work.

You can of course make the choice for yourself that you do not want to use Arch, but some other distro. Totally fine. But that is like taking a recipe from an egg-lovers foodie blog and then complaining that it does not work or taste well, because you choose to only frequent a store that sells avocados instead of eggs. Well yes, it that case certain adjustments may be necessary to make all those recipes work for you that assume that you have easy access to eggs. And, with a bit of tinkering and improvisation, I am sure some very nice dishes can be prepared with avocados instead of eggs. And that is a very valid life choice.

The difference of opinion between you and me seems to be in whose responsibility it should be to do the tinkering and the improvisation. And I happen to believe that it should be you, who refuses to use the nice eggs I put in my recipe. Of course I might try to accomodate you and work out a way to do things without eggs - or avocado OR egg, alternatively. But then tomorrow someone might decide that they what to switch all instances of flour for nutmeg. Or brussel sprouts. See the problem?

If you are not using Arch, the authors of AUR PKGBUILDs have zero way a knowing what kinds of packages are installed on your system or get pulled in via dependencies. So you are of course free to use the AUR, but please do not try to make other people responsible for your choices.

Now, if you do want to make a positive contribution and have worked out to make plymouth-git work for your distro of choice, why not type up a nice summary of what you did and either post it here (we might even get it pinned) or put it in your distros wiki for all to see!