Package Details: lastpass 4.38.0.4-1

Git Clone URL: https://aur.archlinux.org/lastpass.git (read-only, click to copy)
Package Base: lastpass
Description: The Universal LastPass installer for Firefox, Chrome, and Opera
Upstream URL: https://lastpass.com
Licenses: custom
Submitter: Det
Maintainer: eschwartz
Last Packager: eschwartz
Votes: 91
Popularity: 0.46
First Submitted: 2013-06-02 17:50
Last Updated: 2019-12-05 07:19

Pinned Comments

eschwartz commented on 2019-04-03 17:17

No, it really isn't bad practice. It is bad practice to fail hard because you have a tightly interwoven dependency on makepkg internals (and the format that is absolutely, positively, guaranteedly documented, since I wrote the documentation). Given I have actually discussed this with one of the lead developers of yay, and my advice to not be vulnerable to breaking for any reason, was accepted, I consider myself justified in adding this.

I did not break yay. I discovered that yay was already broken. I also guaranteed that yay-git now supports upcoming versions of pacman.

Furthermore, the official policy of the AUR is that if an AUR helper does not work, you should use makepkg directly, and if makepkg itself does work, then the problem is automatically with the AUR helper and only the AUR helper.

I am not changing this, and it is not open for debate.

eschwartz commented on 2019-03-31 21:05

I am indeed running an unreleased version of pacman/makepkg, and I'm also the one who added b2sums to pacman in git master (and the pacman-git package I maintain). :p

It's not a problem for old versions of makepkg, as old versions will ignore b2sums and rely exclusively on sha256sums (all you need is at least one valid algorithm) -- you won't get the advantage of collision resistance with multiple algorithms including an SHA-3 contender, but SHA-2 is still pretty good even without using two algorithms for redundancy.

Added: Whether an AUR helper (that I do not test) can correctly handle this does not bother me, since makepkg (the gold standard which I use to test) handles it just fine.

Latest Comments

1 2 3 4 5 6 ... Next › Last »

Det commented on 2019-07-11 11:51

He responses in complaining manners, but he's right.

eschwartz commented on 2019-04-03 17:17

No, it really isn't bad practice. It is bad practice to fail hard because you have a tightly interwoven dependency on makepkg internals (and the format that is absolutely, positively, guaranteedly documented, since I wrote the documentation). Given I have actually discussed this with one of the lead developers of yay, and my advice to not be vulnerable to breaking for any reason, was accepted, I consider myself justified in adding this.

I did not break yay. I discovered that yay was already broken. I also guaranteed that yay-git now supports upcoming versions of pacman.

Furthermore, the official policy of the AUR is that if an AUR helper does not work, you should use makepkg directly, and if makepkg itself does work, then the problem is automatically with the AUR helper and only the AUR helper.

I am not changing this, and it is not open for debate.

gromain commented on 2019-04-03 17:00

I think that adding an unreleased and undocumented feature to something is bad practice too, since it breaks tools that could not have been informed of coming changes.

ender4 commented on 2019-04-01 06:49

Is b2sums supported by makepkg? I can't find any documentation on it.

linuxninja commented on 2019-04-01 02:18

Thanks for your quick response, and all of your hard work! Sometimes it's just not obvious how to prevent breaking changes, ey?

I will follow-up by reporting this issue via yay's reporting mechanism (github issues). I'll have to check the yay-git package to be sure it hasn't already been fixed, there, and maybe just a new release of yay is all that is needed.

eschwartz commented on 2019-04-01 02:04

Was this tested?

It was tested to work with makepkg, which is the gold standard...

I don't exactly test what every fad AUR helper does. Note that this sort of heuristic blacklisting of perfectly good packages means that yay would not work for packages that implement new features, immediately after makepkg itself received a new release. So I don't generally encourage this sort of error-checking anyway. It gives me flashbacks to pacaur and its "mismatched srcinfo" errors.

linuxninja commented on 2019-04-01 02:00

for the less informed who run into this issue, here's the quick and dirty on upgrading the aur package when yay breaks:

cd ~/.cache/yay/lastpass

makepkg -si

linuxninja commented on 2019-04-01 01:56

I'm also running into a breaking error with aur package upgrades:

yay error message:

:: Parsing SRCINFO (1/1): lastpass failed to parse lastpass: Line 30: Unknown key: "b2sums": b2sums = 493334b0cf11abe2add52a2935b1e3a4afdffd8b4b64d659913084257af058c51b2157fb1fdb4f78da9dee9f61750bcd0614661b092a66c6fd252eff35f348f8

This is a fatal error and aborts the entire yay run. I would suggest adding an as-yet unsupported line to the config is not backwards compatible for the various AUR tools. Maybe those tools should be given some time to either ignore invalid config lines, or add support for the new proposed config lines.

Was this tested? Can we remove the b2sums line until tools like yay have some time to get this added?

eyrie88 commented on 2019-03-31 22:07

Well, yay doesn't like it... :: Parsing SRCINFO (1/3): lastpass failed to parse lastpass: Line 30: Unknown key: "b2sums": b2sums = 493334b0cf11abe2add52a2935b1e3a4afdffd8b4b64d659913084257af058c51b2157fb1fdb4f78da9dee9f61750bcd0614661b092a66c6fd252eff35f348f8

eschwartz commented on 2019-03-31 21:05

I am indeed running an unreleased version of pacman/makepkg, and I'm also the one who added b2sums to pacman in git master (and the pacman-git package I maintain). :p

It's not a problem for old versions of makepkg, as old versions will ignore b2sums and rely exclusively on sha256sums (all you need is at least one valid algorithm) -- you won't get the advantage of collision resistance with multiple algorithms including an SHA-3 contender, but SHA-2 is still pretty good even without using two algorithms for redundancy.

Added: Whether an AUR helper (that I do not test) can correctly handle this does not bother me, since makepkg (the gold standard which I use to test) handles it just fine.