[Slackbuilds-users] What if we `source`d the version number

Eugen Wissner belka at caraus.de
Tue Jan 11 09:03:40 UTC 2022


I don't update the package name each time, but I often update the
package version.

On Tue, Jan 11, 2022 at 10:44:47AM +0200, Petar Petrov wrote:
> Hi guys,
> 
> if you aim to simplify things, you can take it even further...
> 
> Why do you need $PRGNAM.SlackBuild, $PRGNAM.info, etc...? Anyway, all
> of these are in a folder called $PRGNAM, right? Why should the script
> have a unique name, instead of just SlackBuild (like the PKGBUILD
> files in Arch)?
> 
> i know it's not going to happen, since this is not how Slackware does things.
> 
> -petar
> 
> On Tue, 11 Jan 2022 at 00:16, Konrad J Hambrick <kjhambrick at gmail.com> wrote:
> >
> > Klaatu --
> >
> > That's pretty much what I do ( source $PROGRAM.info ) in my do-SlackBuild.$PRGNAM scripts.
> >
> > But I do that in a wrapper-script that invokes the standard SlackBuild.
> >
> > The Code below is auto-generated by a get-SB-pkg script ( example:  get-SB-pkg intel-microcode )
> >
> > As you can see, the $PRGNAM.info File is sourced by the wrapper script but I can still override the VERSION as expected:
> >
> >    VERSION=1.2.3.4 ./do-SlackBuild.intel-microcode
> >
> > One can also set TAG= to append a TAG ( like say, TAG=_kjh )
> >
> > As a bonus, the do-wrapper logs all the output to $PRGNAM-SlackBuild-$VERSION$TAG.log
> >
> > Anyhow ... my $0.02 ... no need to change the SlackBuilds ( PLEASE don't change the SlackBuilds :)
> >
> > -- kjh
> >
> >> #!/bin/sh
> >>
> >> DoName="intel-microcode.SlackBuild"
> >>
> >> MyVersion="$VERSION"
> >>
> >> . ./intel-microcode.info
> >>
> >> [ "$MyVersion" = "" ] && MyVersion="$VERSION"
> >>
> >> LogNam="$DoName-$MyVersion$TAG.log"
> >>
> >> unset PRGNAM
> >> unset VERSION
> >> unset HOMEPAGE
> >> unset DOWNLOAD
> >> unset MD5SUM
> >> unset DOWNLOAD_x86_64
> >> unset MD5SUM_x86_64
> >> unset REQUIRES
> >> unset MAINTAINER
> >> unset EMAIL
> >> #
> >> # set and export any extra variables here
> >> #
> >> export TAG
> >> export VERSION="$MyVersion"
> >
> >
> >>
> >> # do the deed
> >> #
> >> echo "$DoName startup  at `date`"  |tee    $LogNam
> >> ./$DoName 2>&1                     |tee -a $LogNam
> >> #
> >> RetCode=${PIPESTATUS[0]}
> >> #
> >> [ "$RetCode" = "0" ] && RetStr="complete" || RetStr="FAILED  "
> >> #
> >> # optional pre-installation instructions  here
> >> #
> >> #
> >> # optional pre-installation instructions there
> >> #
> >> # log your results
> >> #
> >> echo "$DoName $RetStr at `date` ... RetCode = $RetCode" |tee -a $LogNam
> >> exit $RetCode
> >
> >
> >
> > On Tue, Jan 4, 2022 at 3:11 PM Klaatu <klaatu at mixedsignals.ml> wrote:
> >>
> >> Why do we define the VERSION for a package in two separate files?
> >>
> >>
> >>
> >> What if we replaced this line in foo.SlackBuild:
> >>
> >> VERSION={VERSION:-0.0.1}
> >>
> >>
> >>
> >> with this instead:
> >>
> >> . ./$PRGNAM.info
> >>
> >>
> >>
> >> The VERSION variable would get imported from a consolidated location (the .info file).
> >>
> >>
> >>
> >> It seems to make more sense to me, and it makes trivial upgrades (the ones where I go in and just bump a version number to something I want to build) a one-file task.
> >>
> >>
> >>
> >> Thoughts?
> >>
> >> _______________________________________________
> >> SlackBuilds-users mailing list
> >> SlackBuilds-users at slackbuilds.org
> >> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> >> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> >> FAQ - https://slackbuilds.org/faq/
> >>
> > _______________________________________________
> > SlackBuilds-users mailing list
> > SlackBuilds-users at slackbuilds.org
> > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> > FAQ - https://slackbuilds.org/faq/
> >
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
> 


More information about the SlackBuilds-users mailing list