[aur-general] TU application: Maxim Baz

Tue Nov 6 01:22:57 UTC 2018

On 11/5/18 7:05 PM, Maxim Baz via aur-general wrote:
>>> - wire-desktop (76): End-to-end encrypted messaging app that works on Windows,
>>> Linux, Mac, Android and iPhone. It is free, open-source and available
>>> on Github. Although I'm co-maintaining this package on AUR, I was mostly
>>> focused on contributing to the project itself: I added proper emoji support
>>> (following the latest Unicode standard), emoji autocomplete and improved
>>> native notifications on Linux (show user pictures, set urgency hint).
>>
>> - patching should happen in prepare()
>> - electron packages should use our electron package and don't download
>>   it again. (I'm assuming it does btw)
>> - ideally the desktop file should be from upstream or submitted upstream
>> - i686 shouldn't be in the arch=() array for community packages
>> - Just my personal opinion, but what the JavaScript!!!
> 
> Thank you for these, I expect making it use system electron will be the most
> difficult part. 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?

Well, I for one am rather opposed to shipping vendored binaries,
especially when it results in bugs like this:
https://github.com/electron/electron/issues/13972

And just generally, vendored dependencies are gross.

...

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.

Also once again, note to self: write some wiki packaging guidelines for
this.

>>> - browserpass (31): Browser extension for pass (unix password manager),
>>> works in Chromium and Firefox. I became the primary project maintainer about
>>> a year ago, and together with another maintainer recently started rewriting
>>> it to make the architecture accommodate users' needs. I'm planning to bring
>>> this to [community] after the new version is ready (we are aiming to release
>>> in December). Also, someone in comments on AUR gave me a cool idea to use
>>> split-packages for Chromium and Firefox browsers, I'm going to do this as
>>> well (current PKGBUILD installs browserpass for both browsers, even if these
>>> browsers are not installed).
>>
>> No idea, what to make of the Golang stuff, melts my brains. This however
>> semes to not be reproducible? Or does upstream have a lock file for
>> locking it's deps?
> 
> The upstream has a lock file, and moreover the sources archive that this package
> is downloading already contains all dependencies, so that PKGBUILD doesn't have to
> deal with them — all it has to do is to extract the archive and run `make`.
> 
>> I'm not a fan of supporting a non-supported component i.e. goole chrome.
> 
> Will it be better in your opinion if this was a split package, providing app itself,
> and then packages for google chrome, chromium and firefox? This was suggested to me
> earlier, so that the package doesn't create files for browsers that are not even
> installed.
> 
> I guess I could even separate them into completely different PKGBUILDs, bring
> browserpass, browserpass-config-chromium and browserpass-config-firefox to community
> and leave browserpass-config-google-chrome in AUR. All these browserpass-config-*
> packages will provide "browserpass-config", and browserpass will depend on generic
> "browserpass-config", so that user is required to install at least one.
> 
> 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.

> 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...

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.

This is, after all, why we developed hooks for pacman. :)

It was originally added in March of this year:
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/systemd&id=c2ba1fefa6e393e5cb4d2c19ba65a4ec4c33fb9f

>> * 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's neither a new rule nor an old rule -- it's an unspoken rule. The
AUR is for hosting build recipes, it's logically inconsistent to serve
as the upstream source. Moreover, our servers have enough load without
also checking into git a lot of source code we never intended to provide
hosting services for. Not that we're in imminent danger of overload,
but... why add bloat...

*puts on aurweb hat*

We actually have checks within the backend code to ensure a maximum
allowable blob size for any file checked into git. This has been
calculated in an effort to be friendly to things like linux kernel
.config which can be moderately large (this is the precise example that
made us bump the limit from 100KB to 250KB). A linux .config is a thing
which is not source code, but package configuration, and thus makes
sense to be uploaded directly.

In theory it's supposed to be obvious, much like uploading your holiday
pictures is obviously against the rules despite not being spelled out.
But, we do seem to get people uploading trivial scripts, possibly
because they don't feel like bothering with the creation of an
additional GitHub repo. :/

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- 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/20181105/dad9061f/attachment-0001.asc>