Arch Linux User Repository

Well that wasn't easy... Go is really fussy about where it wants things. I also got caught up regarding how go-bindata works (browsh was complaining about not finding /browsh.xpi).

Anyway, it works now. I also included UPX support as an option. (@tombh, it seems you forgot to remove "-nocompress" from your go-bindata command when you decided to remove UPX compression)

Next step browsh-git? (that is, a versionless package that pulls up-to-the-moment sources from git, this will require some way of self-making the xpi to make sense...)

PKGBUILDs are as simple as they come, they're just a bash script which sets some variables (basic package information), and defines one or more functions related to putting the package together, with the only required one being package(), all it does it put stuff in $pkgdir (./pkg), as if it's root (/). If you can install something manually on the command line, you can read and write a PKGBUILD. I'll see if I can put together a 'browsh' package now.

There's no need to avoid optimisation of the files in the .xpi, but I would like to add something in the PKGBUILD to compare it with the provided sources, to ensure they're identical, this can be done if the PKGBUILD included the same optimisation tasks you use.

Okay, I've refactored the build process now. I think it's in a few readable steps: https://github.com/browsh-org/browsh/blob/master/interfacer/contrib/build_browsh.sh It just depends on Golang and curl. Although I'm a regular AUR user myself, I have to admit I've never actually really looked at any build scripts. Does this one look okay?

Edit: @Mikurok: yes you're right about the .xpi format, it's just a zip file with JS source files in it. Although at the moment the JS is minified, I'm going to undo that, it shouldn't make any difference to the size anyway as it's zipped.

@tombh, That sounds great. From what I understand, the xpi contains only scripts taken uncompiled from the original sources, right? so that would at least make the whole package auditable/readable. While I'm not an authority on this, I'd have to agree that would be enough for a non-bin package. Is it really absolutely necessary for a webext to pass through mozilla to be usable, even with browser modification?

Something I still don't like about this is the fact that part of the source code cannot be changed, not without presumably having to go through whatever steps are needed to make a new webext with mozilla. This may not be your fault, though.

Thanks @MikuroK. I'm actually working on a better internal build script for Browsh, it needs to be done for a number of reasons. However it will still have to download the .xpi web extension package from Mozilla. Do you think that would still classify it as a 'bin' package? All the Go code can be built locally, but about half the code will be inside this .xpi thing, which is basically just a zip of a JS code base.

@tombh: Upvote to @MikuroK's comment: a from-source PKGBUILD for browsh would be really awesome!

@tombh, hitting the 'flag package out-of-date' button will let me know by email if the package is out of date. i'm happy to let you be a co-maintainer, or the maintainer for this package if you like. as a side note, i would have preferred to make a from-source "browsh" and/or "browsh-git" package, but i'm unsure how to build this program from source. instructions on how to build a release binary would be great, not just for me, but for others who don't really like the idea of getting binaries from user repositories (such as from github or the AUR).

Hello, I'm the author of Browsh, is there any way I can help to automate updating this package when a new version becomes available?