[aur-general] TU application: Maxim Baz

[Levente Polyak]

Hi Maxim,

On 11/6/18 1:05 AM, Maxim Baz via aur-general wrote:
>> You might want to use go-pie btw, to actually have PIE support
>>
>> browserpass W: ELF file ('usr/bin/browserpass') lacks FULL RELRO, check LDFLAGS.
>> browserpass W: ELF file ('usr/bin/browserpass') lacks PIE.
> 
> Nice, will investigate this.

well replace go with go-pie is all you can do there, you can't (yet) fix
RELRO for go :/


> 
>>> - ttf-emojione (33): Colorful emoji font from EmojiOne. I created a Docker
>>> image that is able to compile the font out of image assets, and configured a
>>> Travis job for EmojiOne team so that the font is automatically being compiled
>>> on every commit and attached to every Github release.
>>
>> The .install scriptlet shouldn't contain documentation. 
> 
> Just to confirm, this is not as much documentation as a description of a command
> that user needs to run to make this package work.
> 
> I guess I could create a wiki page for EmojiOne and put there the command to run,
> but how do I let people know that they must visit the wiki? People expect to install
> the font and see it working, but it won't happen until they install fontconfig file.
> 
> I've had positive experience with using .install files to inform people what else
> they need to do after installation, not a single person complained in comments on AUR
> about problems with font! :)
> 
> Also, just saw that wiki [4] encourages to echo important directions that are needed
> to make package work, I believe my .install files fall under this category ;)
> 

This is certainly something that is totally debatable and after all we
are not Debian that does everything imaginable automagically and f.e.
reloads all kind of stuff.
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 :p


>>> - grub-btrfs (15): Detects and includes btrfs snapshots in GRUB menu, allowing
>>> to easily boot in any existing snapshot. I personally use grub-btrfs in
>>> combination with snap-pac and snap-pac-grub for seamless integration with
>>> snapper and pacman.
>>
>> The .install scriptlet shouldn't really contain documentation. Ideally
>> that should be found on the wiki or in the man pages.
> 
> Same question here, but actually worth confirming with you: is it a bad practice
> to execute "systemctl daemon-reload" in post_install() function? I've seen people
> do that, but so far I was refraining from executing any commands in .install files.
> 
> Creating a wiki page that would only tell people to run "systemctl daemon-reload"
> after installation sounds wrong...
>  

Yes, it is bad practice to use .install file to warn about  "systemctl
daemon-reload". You also don't need a wiki page for that, why should
you? Systemctl warns you itself about this whenever you would do
something that could require a daemon-relload. This is knowledge that is
expected to be gained. We are not debian that does this automatically,
and if so, it should rather be discussed on arch-dev-public to get a
pacman hook support (which IMO we don't need much).

> 
>> * rebuild-detector:
>> * snap-pac-grub:
>>
>> - Source should not be hosted on the AUR 
> 
> I will move to Github since it simplifies collaboration, but I also want to confirm
> if this is a new rule? I don't see this being mentioned on wiki [2,3,4], unless I'm blind :/
> 
> If it is a rule, let's add it to the wiki! ;)
> 

It indeed is a rule and obviously we need to make it very clear. AUR
package tree is not meant to store the actual non-build-related sources,
 signatures, tarballs or similar artifacts. AUR is not a storage and
actual sources belong elsewhere.


cheers,
Levente

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20181106/b9b97dc6/attachment.asc>