[Slackbuilds-users] Package versions

[Eric Pratt]

I know I'm definitely guilty of letting my slackbuilds slip for long
periods of time.  I'm trying to prevent that moving forward, but it's
really mostly a matter of getting the time to do it and remembering to do
it.  So I like the auto-updating idea.  It would get many of us past the
remembering to do it part of the problem.

But it would be difficult to do.  If there were a single standard database
or even standard API on project homepages that could deliver the latest
version numbers, then this would start to look good.  But everyone has
their own method for announcing releases with their own formats.  We'd have
to parse that out of each project page.  And people change their web page
layouts and formats frequently enough for this to be an ongoing headache.
If we're not updating our packages fast enough then we're not going to put
even more effort into maintaining an auto-update feature.

However, I do like the idea.  I try to automate everything I do at some
point so this is an intriguing project.  Using ffmpeg as an example since
it was already mentioned in this thread, an example to search for the
current version number could be:

  > wget -qO - "${PROJECT_URL}" | grep -o
"${PROJECT_NAME}-[0-9][0-9A-Za-z.]*\.tar\.xz" | sort -n | tail -1
  ffmpeg-3.2.2.tar.xz
  >

Since we already know the version number as defined in the slackbuild, we
could compare the filename with the existing one to see what the latest
version is:

####################################
#!/bin/bash

PROJECT_NAME='ffmpeg'
PROJECT_URL='https://ffmpeg.org/download.html'
CURRENT_VERSION='ffmpeg-2.8.7.tar.xz'
LATEST_VERSION=$(wget -qO - "${PROJECT_URL}" | grep -o
"${PROJECT_NAME}-[0-9][0-9A-Za-z.]*\.tar\.xz" | sort -n | tail -1)

if [[ $(echo -e "${CURRENT_VERSION}\n${LATEST_VERSION}" | sort -n | tail
-1) == ${CURRENT_VERSION} ]]; then
        echo "${PROJECT_NAME} Slackbuild is up to date."
        exit 0
else
        echo "Download new version and test slackbuild."
fi
####################################

Of course, we can pull the current version from the slackbuild itself and
the part where we echo "download new version . . ." would need to be
replaced by code to download the new version and test the slackbuild with
it or at the least, send a notification of a new update available.  We
could probably put some more work into this to make something that the vast
majority of slackbuilds could use.  But no doubt there will need to be a
lot of unique update scripts.  But we already have a really nice slackbuild
tar ball that could optionally contain an auto-updater as a support
script.  So just like we have a standard template for slackbuild scripts
that get modified on a case-by-case basis, we could have a standard
template for an update script.

The update script would primarily be run by the maintainer, ideally via
cron or something similar, and could attempt to download and build a
package with the new version.  Or it can simply send an email to notify the
maintainer that a new release is available in which case it would need to
track state so it doesn't spam about the same version over and over again.
Lots of possibilities.  I'll look into doing this for my slackbuilds and
see what I can come up with.


On Thu, Jan 19, 2017 at 10:58 AM, Andrzej Telszewski <atelszewski at gmail.com>
wrote:

> On 19/01/17 19:45, David Spencer wrote:
>
>> As a radical idea, we could consider making some packages
>> auto-updating. I suspect lots of perl, python, haskell and ruby could
>> be completely automated. I bet everybody hates this idea :p
>>
>>
> You bet ;-)
>
> On the other hand, George from Salix made a very good point when he
>> recently wrote "SBo has a policy of constantly updating its contents
>> with new versions, which in my opinion is competely against
>> Slackware's policy (as well as our own) for stability". I do have a
>> lot of respect for that point of view.  I think the main reasons
>> against it are social not technical (too much work at one time for new
>> releases, need to keep maintainers involved). Having said that, for
>> technical reasons quite a lot of packages do need to be quite stable
>> between releases (haskell, ffmpeg and more -- everybody on the list
>> could probably name them).
>>
>
> I don't exactly agree.
> There are multiple situations where updating the package makes a lot of
> sense.
> Be it security, or new features that save your time.
>
> On the other side, how often do we see a breakage here?
>
> As you said, there are packages that won't see an update without very good
> reason.
> I think the crew is doing very well on that matter.
>
> When it comes to Slackware, well, it's the core of everything.
> The less updates it sees, the better.
> I guess we are all happy for Pat's policy.
>
> --
> Best regards,
> Andrzej Telszewski
>
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20170119/a60e9f8c/attachment-0001.html>