"name in Linux := " ignored

[davidB]

Hi,

My project is named with '' but for debian Debian package '' is forbidden. Like in the doc I try to provide an other name via "name in Linux := ..." or "name in Debian := ..." without success. Is it a bug or I'm doing something wrong with sbt ?

sbt: 0.13.1
sbt-native-packager: 0.7.0-M3

output

[error] dpkg-deb : erreur : le nom de paquet contient des caractères qui ne sont pas des minuscules alphanumériques ou « -+. »
java.lang.RuntimeException: Failure packaging debian file.  Exit code: 2
    at scala.sys.package$.error(package.scala:27)
    at com.typesafe.sbt.packager.debian.DebianPlugin$$anonfun$debianSettings$23.apply(DebianPlugin.scala:240)
    at com.typesafe.sbt.packager.debian.DebianPlugin$$anonfun$debianSettings$23.apply(DebianPlugin.scala:236)
    at scala.Function4$$anonfun$tupled$1.apply(Function4.scala:35)

from Build.scala

 lazy val prj = (Project(
    id = "my_server"
    ,base = file(".")
    ,settings = defaultSettings ++ packagerSettings ++ packageArchetype.java_server ++
      Seq(
        name := "my_server"
        ,name in Linux := "my-server" //<<= name apply { (n) => n.replace("_", "-")}
        //,target in Debian <<= (target, name in Debian, version in Debian) apply ((t, n, v) => t / (n.replace("_", "-") + "-" + v))
        ,version := "0.1.0"
        ,organization := "com.acme"
        ,organizationName := "Acme"
        ,organizationHomepage := Some(url("http://www.acme.com"))
        ,scalaVersion := "2.10.4-RC1"
        ,crossPaths := false
        ,resolvers += "Local Maven Repository" at "file://"+Path.userHome.absolutePath+"/.m2/repository"
        ,mainClass := Option("akka.kernel.Main")
        ,libraryDependencies ++= Dependencies.kernel ++ Dependencies.core ++ Dependencies.monitor ++ Dependencies.test
        //,unmanagedSourceDirectories in Compile := (scalaSource in Compile).value :: Nil
        ,unmanagedSourceDirectories in Test <++= baseDirectory { base =>
          Seq(
            base / "src/multi-jvm/scala"
            ,base / "src/universal/conf"
          )
        }
        ,bashScriptExtraDefines ++= Seq(
          """app_commands=( "${app_commands[@]}" "%s" )""" format ("my_server.Boot")
        )
        ,bashScriptDefines <<= (Keys.mainClass in Compile, scriptClasspath, bashScriptExtraDefines) map { (mainClass, cp, extras) =>
          JavaAppBashScript.makeDefines("akka.kernel.Main", appClasspath = "../conf" +: cp, extras = extras, configFile=Option("$app_home/../conf/jvm.conf"))
        }
        ,packageSummary := "My Server"
        ,packageDescription := "My Server ....."
        ,maintainer in Windows <<= organizationName
        ,maintainer in Linux := "David Bernard <[email protected]>"
      )
    )
    .settings(net.virtualvoid.sbt.graph.Plugin.graphSettings: _*)
    .configs(MultiJvm)
  )

  lazy val defaultSettings = Defaults.defaultSettings ++ multiJvmSettings ++ Seq(
    // compile options
    scalacOptions ++= Seq("-encoding", "UTF-8", "-target:jvm-1.6", "-deprecation", "-feature", "-unchecked", "-Xlog-reflective-calls", "-Xlint"),
    javacOptions ++= Seq("-source", "1.6", "-target", "1.6", "-Xlint:unchecked", "-Xlint:deprecation")
  )

Thanks for any help

[muuki88]

I was able to reproduce this with the following minimal configuration

import sbt._
import sbt.Keys._
import com.typesafe.sbt.SbtNativePackager._
import NativePackagerKeys._


object ApplicationBuild extends Build {

    lazy val root = Project(
        id = "hello_world",
        base = file("."),
        settings = Defaults.defaultSettings ++ packagerSettings ++ packageArchetype.java_server ++
          Seq(
            name := "Hello_World",
            packageSummary := "Hello World Package",
            packageDescription := "Say hello to the world from different packages",
            maintainer in Linux := "Nepomuk Seiler <[email protected]>"
          )
    )
}

The very easy solution is this: just replace the _ with a whitespace.

name := "my server"

Still I will dig a bit deeper what's causing this issue. For name the normalizedName property is used. We may have to recheck this value.

[muuki88]

Okay. The second way to go would be to override the normalizedKey setting with

normalizedName := "my-server"

However this setting is not scoped in any way, so it will be applied global AFAIK.

[davidB]

I currently workaround by changing the name (and hack some place to rename back). But it's crappy.
And changing the name, normalizedName have effect on .jar, .zip, ... where I would like to keep the name with '_'.

Thanks.

[jsuereth]

SO, this is an issue with derivied settings it seems. You can do normalizedName in Debian I bet. I'll look into a bit, but it's related to: #1036 (sbt/sbt#1036)

[muuki88]

@jsuereth , is there a concept of fallback scopes? E.g,

name := "name"
name in Linux := "linux",
name in Debian := "debian"

// I hope <<= is the correct one :P
normalizedName <<= (name in (Debian or Linux or Global)) map (normalize _)

Or defining scopes with fallback, e.g

val Linux = config("linux")
val Debian = config("debian") withFallback Linux

[muuki88]

@jsuereth solution works (using 0.7.0-RC1)

normalizedName in Debian := "hello-world"

It doesn't affect other usages of normalizedName AFAIK.

[jsuereth]

Yep, that should work for overridding. And fallback scopes sort of exists, but probably needs documented/fleshed out a bit. That's the Config.extend bit. You have to REGISTER your configurations appropriately. Once AutoPlugins hit, we can move to those and we should get appropraite "configuration extension" semantics, I believe.

[muuki88]

Is this still being a blocker for 0.7.0 release?

[jsuereth]

No, writing the getting started guide is. I'm ~30% done with that. If you want I'll push what I have to a branch for you to look at.

[muuki88]

Sure :)

[muuki88]

This ticket is way more complex as we need to define a correct scoping for our main variables which are used all over the place. These are

• name and normalizedName
• packageMappings and linuxPackageMappings
• linuxDefaultReplacements
• version

The current code needs some refactoring here. I'm not very familiar with scope handling, so a pro would be nice :)

[jsuereth]

Yeah, I can take a crack at it. Scope handling is one of those odd areas of sbt.

basic gist:

1. If you depend on a key in a scope and it doesn't exist, it will look through the scope inheritance chain for a value, or without a config scope.
2. If you declare a key in a scope that is never depended on, nothing happens.
3. If you want to force one key to use the value specified/overriden in another you have to be explicit.

I'll try to get to this ticket next time I have some air to work on fun projects :)

[timperrett]

Yikes, this one is killing me right now. Did anything ever get done to fix this guys?

[muuki88]

Nope. This issue is much bigger than it seems on the first glance :/

[timperrett]

Ok, understood. Is there a plan to fix it? I have two major points:

• need to be able to control the name of the binary separate
• need to be able to change the name of the output RPM so that it does not always take the name of the module (for example, if the module is called 'http' its not helpful to look on your system and see that you have 'http' installed.)

Seemingly these are related to name and normalizedName

[jsuereth]

normalizedName in Debian didn't work?

[jsuereth]

Huh, I see. have a fix, but let me check it out.

[timperrett]

I tried normalizedName in Rpm, normalizedName in Linux etc, but none seemed to work.

[jsuereth]

Did you try with my PR?

[timperrett]

@jsuereth im just trying it now.

[timperrett]

@jsuereth @muuki88 So I tried with the following settings (after building from the branch):

name in Rpm := "oncue",
// also tried:
// name in Linux := "oncue",
normalizedName in Linux := "oncue"

I got the following output using rpm -qlp:

/etc/default/ci
/etc/init.d/oncue
/usr/bin/ci
/usr/share/ci/bin/ci
/usr/share/ci/etc/logback.xml
/usr/share/ci/lib/default.ci-3.2-SNAPSHOT.jar
/usr/share/ci/lib/org.scala-lang.scala-library-2.10.4.jar
/usr/share/oncue/logs
/var/log/oncue
/var/run/oncue

The module name is "ci", and as you can see, its now using an odd mix of normalizedName and name:
What do you guys think? Seems strange. My ideal outcome is that the artifact itself is named per the module, but i can control the install path and the name of the binary.

Thanks, Tim