Arch Linux User Repository

[Aur:1]  megasync-bin-4.4.0-3

  1 megasync-bin                     (Build Files Exist)
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> 
:: PKGBUILD up to date, Skipping (1/1): megasync-bin
  1 megasync-bin                     (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> 
:: (1/1) Parsing SRCINFO: megasync-bin
==> Making package: megasync-bin 4.4.0-3 (Mon 26 Jul 2021 05:06:34 PM +0545)
==> Retrieving sources...
  -> Downloading megasync-4.4.0-3-x86_64.pkg.tar.zst...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:06 --:--:--     0
curl: (22) The requested URL returned error: 404
==> ERROR: Failure while downloading https://mega.io/linux/MEGAsync/Arch_Extra/x86_64/megasync-4.4.0-3-x86_64.pkg.tar.zst
    Aborting...
error downloading sources: megasync-bin

Thank you for this time saver.

Nice found, thanks!

@johnlinde I don't live for replying to you in seconds and I have other things to do.

I really care for a State of the Art packaging for the AUR. Updating packages, fixing them, improving mines and others, removing flaws & imperfections, streamlining and removing pointless parts, following packaging guidelines

No @FabioLolix, you are the keyboard lion responding only hours if not minutes after I slapped you in the face with my keyboard.

However, I will say this. I have found that the megasync-bin package does not save the downloads when I quit megasync, and then start it again, however, the regular one that compiles does. So, despite the morons like Fabio here, the reality is, the regular one does work better.

Keep up the good work Fabio! I'm sure someday you will get what you're looking for, which is some kind of respect I think...

@johnlinde you're a real 'keyboard lion', account created today only to reply to me.

I'm gonna review as much as I want

@FabioLolix

Why don't you go find something more useful to do than try to go around and get people to take down the bin files? The people here on arch linux don't want to have to build the source from scratch every time, especially for a stupid little proprietary program like this. Furthermore, why don't you go on a campaign to stop all the other people who are doing with this other packages? Just type "bin" into the search engine. Make sure they're all following the rules little unelected police officer.

@FabioLolix: The way I interpret the rule is that an AUR entry should not just download and install a binary package generated by another PKGBUILD.

In this case, however, the original package installs a config file that modifies your inotify parameters and runs an install script that edits your /etc/pacman.conf by adding an external repository. I do not consider it acceptable for an Arch package to automatically reconfigure different core components of your setup upon installation. In fact, I am not aware of any Arch package that does anything remotely similar.

This package, on the contrary, provides the binaries for the client application without running any post-install action and, as such, is significantly different from the original one. The original package is merely used to extract precompiled binaries. By following your interpretation of the rule, extracting the binaries from the Ubuntu .deb would be fine. This would produce at best the same outcome (generating a package from the binaries shipped by mega.io) but it would potentially introduce compatibility issues (different dependencies, library versions, etc.).

From https://wiki.archlinux.org/index.php/AUR_submission_guidelines#Rules_of_submission

"The AUR should not contain the binary tarball created by makepkg"

@FabioLolix: can you please be more specific about which rule on the AUR Submission Guidelines this PKGBUILD in your opinion violates and how?