> The general statement that .install is not meant for documentation is
> correct, if this falls under the category of being well suited for
> .install is interpretation and debatable. Personally i don't see basic
> fontconfig knowledge to fall under this category and IMO its
> documentation that could be stuffed as well in
> /usr/share/doc/${pkgname}. After all, our users are expected to be able
> to search the wiki, people over the whole net claim we have the best
> linux wiki out there after all :pI see your point and in general I agree, but in this specific case of ttf-emojione I was actually trying not to teach people how to create symlinks in conf.d folder, but rather to let them know that this config _exists_. This fontconfig file is not shipped by upstream (nor will it ever be - upstream only provides assets), instead this is something I made personally with the goal of making it part of the package. If this is not something you feel strongly about, I would much prefer to keep the .install file as it is — as a packager I want to make users of my package as happy as possible, and in my mind letting them know immediately after installation that the package won't work properly unless they also deal with provided fontconfig file is a good move — and if they want to learn more about fontconfig, I'm sure they will visit our awesome ArchWiki. > Levente said: why should you? Systemctl warns you itself about this whenever > you would do > something that could require a daemon-relload. > > Eli said: It's pretty wrong to execute this, mostly because the systemd > package > installs a universal hook to do so and it's therefore outdated bloat to > do so. You are both right, I didn't know about the universal hook, but even if it didn't exist systemctl will warn about this anyway, so makes sense removing the .install file. > It indeed is a rule and obviously we need to make it very clear. > It's neither a new rule nor an old rule -- it's an unspoken rule. Alright, let's please add this to the wiki, I'm sure I'm not the first person to break this rule :) I wanted to add it myself, but "Arch package guidelines" page is write-protected. >> Am I right to assume that if for whatever reason it turns out >> to be impossible to decouple from the bundled electron version, I should keep >> this package in AUR? > > It shouldn't be a huge problem, though. See how e.g. atom caprine code > cozy-desktop geogebra keybase-gui messengerfordesktop min riot-desktop > do it. Awesome, the presence of this number of packages that have already went down this road inspires me :) >> It is vital for browserpass that configs for all browsers (where user wants >> to use >> the app) are installed, it will not function at all without them. > > It is a tiny json file, and I see no reason to create split packages for > it. At worst, you'll just drop the native messaging host (and extension > installation policy) for the google-chrome browser that isn't in the repos. I hear your feedback, let's postpone this discussion to the time when I'm ready with browserpass v3, I will not be updating PKGBUILD or moving it to community until then anyway. Finally, thanks for sharing the info about PIE and RELRO, this is interesting. Cheers, Maxim Baz
signature.asc
Description: OpenPGP digital signature
