[Slackbuilds-users] slimjet

B Watson yalhcru at gmail.com
Wed Jun 20 01:12:51 UTC 2018


This build spends more time with an md5sum mismatch than it does
matching... there has to be a better way.

Currently the download links are:

https://www.slimjetbrowser.com/release/slimjet_i386.tar.xz
https://www.slimjetbrowser.com/release/slimjet_amd64.tar.xz

...which are unversioned filenames, and are always the latest release.

>From looking at slimjet's release history, it looks like they do 3 or 4
releases per month, on average. So Skaendo (the SBo maintainer) would have
to update the md5sum and version in the .info file 3 or 4 times a month.

Our public updates also happen 4 times a month on average... and they
don't necessarily coincide with slimjet's release dates. So even if
Skaendo has the time & energy to track the releases and immediately
submit an update, the update won't appear on our site for up to a week,
during which time users will get an md5sum error (if they ignore it,
they'll get a mis-versioned package, which is also bad).

Whenever there's a new slimjet release, the old version is moved to
the archive area of their site, here:

https://www.slimjet.com/release/archive/

These *are* versioned (at least, the directory names are). So if we
were willing to live with always being one release behind the latest,
we could just use these for URLs:

https://www.slimjet.com/release/archive/19.0.3.0/slimjet_i386.tar.xz
https://www.slimjet.com/release/archive/19.0.3.0/slimjet_amd64.tar.xz

...and update the 19.0.3.0/ to point to the 2nd-latest release (aka
the latest one that's in archive/). This would allow the build to keep
working even if several releases are missed (it would be an older version,
but at least it would be installable with sbopkg/etc).

An even better solution: very politely ask upstream to go ahead and
create the archive/<version>/ directory even for the newest release,
as part of their release process. This way new releases would have a
versioned download URL that could be used immediately by us and whoever
else is packaging slimjet (AUR, Gentoo, FreeBSD, etc).

This is what I did for xroar, and the upstream dev was very cooperative.

Skaendo would still have lots of updates to do (one per slimjet release),
but the old version of the build would still be usable all the time. It
would also allow sbosrcarch to actually archive the files (right now,
it refuses to archive them because of the md5sum mismatch).

Skaendo, are you interested in talking to slimjet's upstream about this?
If they agree, it would make your life a lot easier, as maintainer.


More information about the SlackBuilds-users mailing list