RPM scriptles from file produce duplicate entries.

[zoosky]

Here is a test project https://github.com/zoosky/scriptlets-override-rpm which produces the error:
https://github.com/zoosky/scriptlets-override-rpm

This is the SPEC file with duplicates, see %post and %postun
https://github.com/zoosky/scriptlets-override-rpm/blob/master/rpm-test.spec#L157

Testet with

• Scala 2.11.8, 2.10.6
• sbt 0.13.11
• sbt-native-packager 1.1.1

[muuki88]

Thanks for the sample project reproducing the error. Would you like to make a pull request with a failing test for this: https://github.com/sbt/sbt-native-packager/tree/master/src/sbt-test/rpm/scriptlets-override-rpm

The test only checks for existence, but not for uniqueness.

[zoosky]

I'd like to. Have to find a time slot..

[zoosky]

@muuki88 Unfortunately this fix not only removes the duplicates but adds also mor standard scripts into the spec file linke

startService() {
    app_name=$1
    if hash update-rc.d >/dev/null 2>&1; then
        echo "Adding $app_name to autostart using update-rc.d"
        update-rc.d $app_name defaults
        service $app_name start
    elif hash chkconfig >/dev/null 2>&1; then
        echo "Adding $app_name to autostart using chkconfig"
        chkconfig --add rpmpackage
        chkconfig $app_name on
        service $app_name start
    else
        echo "WARNING: Could not add $app_name to autostart: neither update-rc nor chkconfig found!"
    fi
}

#
# Removing service from autostart
# $1 = service name
#
stopService() {
    app_name=$1
    if hash update-rc.d >/dev/null 2>&1; then
    echo "Removing $app_name from autostart using update-rc.d"
    update-rc.d -f $app_name remove
    service $app_name stop
    elif hash chkconfig >/dev/null 2>&1; then
    echo "Removing $app_name from autostart using chkconfig"
    chkconfig $app_name off
    chkconfig --del $app_name
    service $app_name stop
    else
    echo "WARNING: Could not remove $app_name from autostart: neither update-rc nor chkconfig found!"
    fi

}

#
# Restarting the service after package upgrade
# $1 = service name
#
restartService() {
    app_name=$1
    service $app_name restart
}

# Scriptlet syntax: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Syntax
# $1 == 1 is first installation and $1 == 2 is upgrade
if [ $1 -eq 1 ] ;
then
  startService rpmpackage || echo "Could not start rpmpackage"

This is not expected since we want to remove the standard stuff alltogether.

Could you please reopen the isse?

[muuki88]

This is actually expected behaviour. I know this is not really intuitive and we plan to change this with maybe the next minor version, but we kept it for backwards compatibility.

To give a bit more context for my statement above. At first the were settings for each rpm scriplet, like rpmPostun: SettingKey[Option[String]]. These are rather unpractical as you can't

• depend on tasks to add additional lines
• cumbersome to extend rpmPretrans.value.map(old => old + moreContent).orElse(Some(moreContent))

Furthermore the DebianPlugin replicated a similar concept in a different way. So we created a single structure maintainerScripts, which can be used by any packaging format that provides some sort of maintainer scripts. This maintainerScripts task is the single source of truth for generating the maintainer scripts. There are some helper functions to make it easier filling this data structure.

Back to the original question, why the restartService etc. bash functions are inserted. Currently everything gets appended by default. Nothing overrides. So you have

• the JavaServerAppPackaging archetype adding stuff to the maintainerScripts in Rpm
• the SystemloaderPlugin archetype adding stuff

Where the JavaServerArchetype actually provides the function to map scripts from a folder. As for standalone cli applications you would have to insert the maintainerScripts directly in your build.sbt.

Conclusion

IMHO the best option would be to extract the "loading scripts from a predefined directory" either

• into the RpmPlugin
• in special RpmScriptletsPlugin plugin

[zoosky]

Unfortunately this seems to be a moving target..

I've back ported the fix based on v.1.1.1 tag. This is the PR for an v.1.1.2 release: #827

[zoosky]

@muuki88 thx for explaining the design rationale.

It would be nice if we could have feature stability on 1.1.x, 1.2.x releases.