Packaging Scala on Gentoo Linux

I expect you can safely ignore sbaz.  I don't think many people use it.  Maven seems more common.

The advantage of sbaz and maven over a distro's package management is that it can be done as a non-root user, and the worst state you can get in is needing to delete ~/.m2.  So unless the package manager is useful for non-root users I'd hope it stays out of the way of maven etc.

2009/1/11 Alistair Bush <ali_bush@gentoo.org>

Hi Scala Team.

This email is to find out some information on how scala should be
packaged on a distribution.  It is a open ended email which will
hopefully come up with some interesting ideas/solutions.  It should be
noted that (sadly) my exposure to scala is limited.  So forgive me if I
get anything wrong :)

Gentoo Linux is a source based distribution that provides a build script
(ebuild) to our users which allows them to install a package.  I won't
into any detail about this but if you are interested see [1].

The main discussion I wish to raise is about sbaz.  Basically as I see
it sbaz allows a user to install/update scala packages within managed
directories.  Now, within a distribution it is considered bad for
programs to install anything without integration with the system package
manager (pm).  If the pm is not aware of those packages uninstalling the
base package (in this case scala) will leave undesired/unwanted files
which possibly could have security issues.  As a result of this I have
no current plans to have the installed scala directory as an managed
directory.

sbaz is also able to create managed directories.  In which it downloads
a version of scala and installs it into that directory.  This at least
allows users to have a scala install and then add addition packages to
it safely (from a system perspective).  Yet doing this creates duplicate
scala installs which is an aim of packaging scala in the first place.
As an pretty good example of this.  I have packaged sbaz-1.25 yet when
using sbaz-setup it downloads and installs within the managed directory
sbaz-1.24.

I would like to know how scala should be packaged.  Whether the current
situation is acceptable and just any ideas on this.

Now, this is an example of an ideal way to package scala.

Basically it would be to separate scala into a scala.base and
scala.home.  Where scala.base contains the base files, scala-{compiler,
library, etc, etc}.jar plus bin files (scala, scalac, etc, etc) while
scala.home would contain any additional packages that have been
installed.  With this there could actually be more than one scala.home
on a system.  For example each user could have and use independently of
each other their own scala.home with its own packages installed in each.
 scala.home would not contain the files also within scala.base ( tho
maybe it could link to them if necessary ).

Anyway, I hope to there is some good feedback from this email.

Alistair Bush

ali_bush@gentoo.org
Gentoo Linux Java Developer

[1] http://www.gentoo.org/proj/en/java/java-devel.xml

Ricky Clarkson wrote:
> I expect you can safely ignore sbaz. I don't think many people use it.
> Maven seems more common.
>

Yeah, lets not even go there. Lets just say maven and gentoo have a
clash of ideologies. In fact after writing the rest of this email, lets
just say its pretty obvious.

> The advantage of sbaz and maven over a distro's package management is
> that it can be done as a non-root user, and the worst state you can get
> in is needing to delete ~/.m2. So unless the package manager is useful
> for non-root users I'd hope it stays out of the way of maven etc.

Oh coarse the disadvantage of maven/sbaz is that instead of having one
jar file, you have "# of users".

and also maven doesn't really help with installing netbeans, eclipse-sdk
and every other app (like scala) that are system packages. Ive never
seen maven install .desktop file, icons, mime-type mappings, etc, etc.
Maven after all is a development/project tool, not a end user one.

If we were to apply your logic to non-java packages then users should
install gcc, glibc, pam into there home directories ;) In fact i'm sure
maven would be able to do just this. We can also ignore the
bootstrapping issues as maven is built with maven already, so whats the
problem adding glibc to the mix as well.

>
> 2009/1/11 Alistair Bush >
>
> Hi Scala Team.
>
> This email is to find out some information on how scala should be
> packaged on a distribution. It is a open ended email which will
> hopefully come up with some interesting ideas/solutions. It should be
> noted that (sadly) my exposure to scala is limited. So forgive me if I
> get anything wrong :)
>
> Gentoo Linux is a source based distribution that provides a build script
> (ebuild) to our users which allows them to install a package. I won't
> into any detail about this but if you are interested see [1].
>
> The main discussion I wish to raise is about sbaz. Basically as I see
> it sbaz allows a user to install/update scala packages within managed
> directories. Now, within a distribution it is considered bad for
> programs to install anything without integration with the system package
> manager (pm). If the pm is not aware of those packages uninstalling the
> base package (in this case scala) will leave undesired/unwanted files
> which possibly could have security issues. As a result of this I have
> no current plans to have the installed scala directory as an managed
> directory.
>
> sbaz is also able to create managed directories. In which it downloads
> a version of scala and installs it into that directory. This at least
> allows users to have a scala install and then add addition packages to
> it safely (from a system perspective). Yet doing this creates duplicate
> scala installs which is an aim of packaging scala in the first place.
> As an pretty good example of this. I have packaged sbaz-1.25 yet when
> using sbaz-setup it downloads and installs within the managed directory
> sbaz-1.24.
>
> I would like to know how scala should be packaged. Whether the current
> situation is acceptable and just any ideas on this.
>
> Now, this is an example of an ideal way to package scala.
>
> Basically it would be to separate scala into a scala.base and
> scala.home. Where scala.base contains the base files, scala-{compiler,
> library, etc, etc}.jar plus bin files (scala, scalac, etc, etc) while
> scala.home would contain any additional packages that have been
> installed. With this there could actually be more than one scala.home
> on a system. For example each user could have and use independently of
> each other their own scala.home with its own packages installed in each.
> scala.home would not contain the files also within scala.base ( tho
> maybe it could link to them if necessary ).
>
> Anyway, I hope to there is some good feedback from this email.
>
> Alistair Bush
>
> ali_bush@gentoo.org
> Gentoo Linux Java Developer
>
> [1] http://www.gentoo.org/proj/en/java/java-devel.xml
>
>

[moving to scala-debate]

I dislike maven, as it tries to force a development model rather than being flexible, and there's my dislike of XML.  However, I do like its idea of being able to manage packages as a non-root user.  Having n copies of foo-bar-baz.jar is better than struggling to install foo-bar-baz.jar because you're not root.

And yes, it would be nice to *be able* to install gcc, etc., in one's home directory.  For non-Gentoo distros this helps get around the lack of slots too.  Perhaps if you supported home directory packages then you wouldn't consider maven the enemy.

Right now as a non-root user of a machine with limited libs, I often have to chase source dependencies myself and do the ./configure --prefix=/home/ricky/local, make, make install dance.

Are CPAN and easy_install also the enemy?

2009/1/11 Alistair Bush <ali_bush@gentoo.org>

Ricky Clarkson wrote:
> I expect you can safely ignore sbaz.  I don't think many people use it.
> Maven seems more common.
>

Yeah, lets not even go there.  Lets just say maven and gentoo have a
clash of ideologies. In fact after writing the rest of this email, lets
just say its pretty obvious.

> The advantage of sbaz and maven over a distro's package management is
> that it can be done as a non-root user, and the worst state you can get
> in is needing to delete ~/.m2.  So unless the package manager is useful
> for non-root users I'd hope it stays out of the way of maven etc.

Oh coarse the disadvantage of maven/sbaz is that instead of having one
jar file, you have "# of users".

and also maven doesn't really help with installing netbeans, eclipse-sdk
and every other app (like scala) that are system packages. Ive never
seen maven install .desktop file, icons, mime-type mappings, etc, etc.
Maven after all is a development/project tool,  not a end user one.

If we were to apply your logic to non-java packages then users should
install gcc, glibc, pam into there home directories ;)  In fact i'm sure
maven would be able to do just this.  We can also ignore the
bootstrapping issues as maven is built with maven already, so whats the
problem adding glibc to the mix as well.

>
> 2009/1/11 Alistair Bush <ali_bush@gentoo.org <mailto:ali_bush@gentoo.org>>
>
>     Hi Scala Team.
>
>     This email is to find out some information on how scala should be
>     packaged on a distribution.  It is a open ended email which will
>     hopefully come up with some interesting ideas/solutions.  It should be
>     noted that (sadly) my exposure to scala is limited.  So forgive me if I
>     get anything wrong :)
>
>     Gentoo Linux is a source based distribution that provides a build script
>     (ebuild) to our users which allows them to install a package.  I won't
>     into any detail about this but if you are interested see [1].
>
>     The main discussion I wish to raise is about sbaz.  Basically as I see
>     it sbaz allows a user to install/update scala packages within managed
>     directories.  Now, within a distribution it is considered bad for
>     programs to install anything without integration with the system package
>     manager (pm).  If the pm is not aware of those packages uninstalling the
>     base package (in this case scala) will leave undesired/unwanted files
>     which possibly could have security issues.  As a result of this I have
>     no current plans to have the installed scala directory as an managed
>     directory.
>
>     sbaz is also able to create managed directories.  In which it downloads
>     a version of scala and installs it into that directory.  This at least
>     allows users to have a scala install and then add addition packages to
>     it safely (from a system perspective).  Yet doing this creates duplicate
>     scala installs which is an aim of packaging scala in the first place.
>     As an pretty good example of this.  I have packaged sbaz-1.25 yet when
>     using sbaz-setup it downloads and installs within the managed directory
>     sbaz-1.24.
>
>     I would like to know how scala should be packaged.  Whether the current
>     situation is acceptable and just any ideas on this.
>
>     Now, this is an example of an ideal way to package scala.
>
>     Basically it would be to separate scala into a scala.base and
>     scala.home.  Where scala.base contains the base files, scala-{compiler,
>     library, etc, etc}.jar plus bin files (scala, scalac, etc, etc) while
>     scala.home would contain any additional packages that have been
>     installed.  With this there could actually be more than one scala.home
>     on a system.  For example each user could have and use independently of
>     each other their own scala.home with its own packages installed in each.
>      scala.home would not contain the files also within scala.base ( tho
>     maybe it could link to them if necessary ).
>
>     Anyway, I hope to there is some good feedback from this email.
>
>     Alistair Bush
>
>     ali_bush@gentoo.org <mailto:ali_bush@gentoo.org>
>     Gentoo Linux Java Developer
>
>     [1] http://www.gentoo.org/proj/en/java/java-devel.xml
>
>

One more thing, yes, maven does help with installing Scala.  Josh Suereth, one of the maven Scala plugin committers, told me that he has never installed Scala other than by referring to it from a maven pom.xml file.

2009/1/11 Ricky Clarkson <ricky.clarkson@gmail.com>

[moving to scala-debate]

I dislike maven, as it tries to force a development model rather than being flexible, and there's my dislike of XML.  However, I do like its idea of being able to manage packages as a non-root user.  Having n copies of foo-bar-baz.jar is better than struggling to install foo-bar-baz.jar because you're not root.

And yes, it would be nice to *be able* to install gcc, etc., in one's home directory.  For non-Gentoo distros this helps get around the lack of slots too.  Perhaps if you supported home directory packages then you wouldn't consider maven the enemy.

Right now as a non-root user of a machine with limited libs, I often have to chase source dependencies myself and do the ./configure --prefix=/home/ricky/local, make, make install dance.

Are CPAN and easy_install also the enemy?

2009/1/11 Alistair Bush <ali_bush@gentoo.org>

Ricky Clarkson wrote:
> I expect you can safely ignore sbaz.  I don't think many people use it.
> Maven seems more common.
>

Yeah, lets not even go there.  Lets just say maven and gentoo have a
clash of ideologies. In fact after writing the rest of this email, lets
just say its pretty obvious.

> The advantage of sbaz and maven over a distro's package management is
> that it can be done as a non-root user, and the worst state you can get
> in is needing to delete ~/.m2.  So unless the package manager is useful
> for non-root users I'd hope it stays out of the way of maven etc.

Oh coarse the disadvantage of maven/sbaz is that instead of having one
jar file, you have "# of users".

and also maven doesn't really help with installing netbeans, eclipse-sdk
and every other app (like scala) that are system packages. Ive never
seen maven install .desktop file, icons, mime-type mappings, etc, etc.
Maven after all is a development/project tool,  not a end user one.

If we were to apply your logic to non-java packages then users should
install gcc, glibc, pam into there home directories ;)  In fact i'm sure
maven would be able to do just this.  We can also ignore the
bootstrapping issues as maven is built with maven already, so whats the
problem adding glibc to the mix as well.

>
> 2009/1/11 Alistair Bush <ali_bush@gentoo.org <mailto:ali_bush@gentoo.org>>
>
>     Hi Scala Team.
>
>     This email is to find out some information on how scala should be
>     packaged on a distribution.  It is a open ended email which will
>     hopefully come up with some interesting ideas/solutions.  It should be
>     noted that (sadly) my exposure to scala is limited.  So forgive me if I
>     get anything wrong :)
>
>     Gentoo Linux is a source based distribution that provides a build script
>     (ebuild) to our users which allows them to install a package.  I won't
>     into any detail about this but if you are interested see [1].
>
>     The main discussion I wish to raise is about sbaz.  Basically as I see
>     it sbaz allows a user to install/update scala packages within managed
>     directories.  Now, within a distribution it is considered bad for
>     programs to install anything without integration with the system package
>     manager (pm).  If the pm is not aware of those packages uninstalling the
>     base package (in this case scala) will leave undesired/unwanted files
>     which possibly could have security issues.  As a result of this I have
>     no current plans to have the installed scala directory as an managed
>     directory.
>
>     sbaz is also able to create managed directories.  In which it downloads
>     a version of scala and installs it into that directory.  This at least
>     allows users to have a scala install and then add addition packages to
>     it safely (from a system perspective).  Yet doing this creates duplicate
>     scala installs which is an aim of packaging scala in the first place.
>     As an pretty good example of this.  I have packaged sbaz-1.25 yet when
>     using sbaz-setup it downloads and installs within the managed directory
>     sbaz-1.24.
>
>     I would like to know how scala should be packaged.  Whether the current
>     situation is acceptable and just any ideas on this.
>
>     Now, this is an example of an ideal way to package scala.
>
>     Basically it would be to separate scala into a scala.base and
>     scala.home.  Where scala.base contains the base files, scala-{compiler,
>     library, etc, etc}.jar plus bin files (scala, scalac, etc, etc) while
>     scala.home would contain any additional packages that have been
>     installed.  With this there could actually be more than one scala.home
>     on a system.  For example each user could have and use independently of
>     each other their own scala.home with its own packages installed in each.
>      scala.home would not contain the files also within scala.base ( tho
>     maybe it could link to them if necessary ).
>
>     Anyway, I hope to there is some good feedback from this email.
>
>     Alistair Bush
>
>     ali_bush@gentoo.org <mailto:ali_bush@gentoo.org>
>     Gentoo Linux Java Developer
>
>     [1] http://www.gentoo.org/proj/en/java/java-devel.xml
>
>

Ricky Clarkson wrote:
> One more thing, yes, maven does help with installing Scala. Josh
> Suereth, one of the maven Scala plugin committers, told me that he has
> never installed Scala other than by referring to it from a maven pom.xml
> file.

And what may I ask is installed? And how may it be used easily?

>
> 2009/1/11 Ricky Clarkson >
>
> [moving to scala-debate]
>
> I dislike maven, as it tries to force a development model rather
> than being flexible, and there's my dislike of XML. However, I do
> like its idea of being able to manage packages as a non-root user.
> Having n copies of foo-bar-baz.jar is better than struggling to
> install foo-bar-baz.jar because you're not root.

maven isn't a package manager. "Maven is a software project management
and comprehension tool."

They share some similar functionality, but completely different goals.

>
> And yes, it would be nice to *be able* to install gcc, etc., in
> one's home directory. For non-Gentoo distros this helps get around
> the lack of slots too. Perhaps if you supported home directory
> packages then you wouldn't consider maven the enemy.

Firstly I don't dislike maven because it installs packages into a users
home. Manly I dislike it because the phases it has are completely
incompatible with portage. For example, maven has an annoying habit of
attempting to download files which should, within the portage world at
least, have already been fetched (yes I know about offline mode). That
makes packaging it on Gentoo very difficult. Therefore as a nicer
summary I dislike maven purely because I am unable to package it on
Gentoo. It should be noted that gentoo packages maven-bin and users are
free to do whatever they want with it.

Also /home is not something a package manager ever installs packages into.

>
> Right now as a non-root user of a machine with limited libs, I often
> have to chase source dependencies myself and do the ./configure
> --prefix=/home/ricky/local, make, make install dance.

I would suggest that instead of doing that, you approach the admins and
ask for permissions or a vm or a chroot/jail, etc, etc. Or at least
come up with a mechanism to report required libs to them. Do your
admins know you do this? I would hate for them to add noexe to the
mount options for /home. I also wonder how you know when a new version
of that library is available, say one that fixes a security
vulnerability (aka privilege esculation, if you are smart enough you
might not need to ask for root access). Im not really a fan of LFS
implementations, I like to let package managers do what they do best
(aka manage packages)

>
> Are CPAN and easy_install also the enemy?

We have g-cpan. Its a nice little utility that 1) auto generates
ebuilds from cpan packages and 2) installs cpan packages (without
needing a ebuild btw) in a way that means it is known to portage. As for
easy_install I believe I heard that egg support within eclasses but im
unsure of the details.

>
> Ricky Clarkson wrote:
> > I expect you can safely ignore sbaz. I don't think many
> people use it.

Oh I really should bring up that the reason we even new about sbaz was
someone filed a bug report on it. Seems it is distributed in the bin
package but not in the source.

I was hoping this was going to be constructive.

The libraries, compiler, swing, dbc and the source/scaladocs for
each. But they are only installed when I want them to be.

I look at scala as a development tool, not an end user tool (although
I guess you could look at it that way.). That is why, when delivering
to clients I either create an assembly or respective package for their
OS.

I understand wanting to limit the number of jar files that get
installed on a platform, however I beleive most Linux packaging
systems are much friendlier to ELF style libraries. What I've seen
for linux java library packages so far usually hinder my efforts, not
help.

If there were a build tool that understood native packaging for java
(and was actually usefull [cross-platform]) I think I would be using
that.

While I see your goals as admirable, until the java applications/build
tools play nicely with native package managers... I don't know how to
lessen everyone's pain. (remember we've got to support windows...)

Also note: I don't think this answers any of your questions. I'd
like to see you succesful, as that benefits all of us. However as
it's scala-debate, I like tooting my horn.

On Jan 11, 2009, at 6:26 AM, Alistair Bush wrote:

> Ricky Clarkson wrote:
>> One more thing, yes, maven does help with installing Scala. Josh
>> Suereth, one of the maven Scala plugin committers, told me that he
>> has
>> never installed Scala other than by referring to it from a maven
>> pom.xml
>> file.
>
> And what may I ask is installed? And how may it be used easily?
>
>>
>> 2009/1/11 Ricky Clarkson > >
>>
>> [moving to scala-debate]
>>
>> I dislike maven, as it tries to force a development model rather
>> than being flexible, and there's my dislike of XML. However, I do
>> like its idea of being able to manage packages as a non-root user.
>> Having n copies of foo-bar-baz.jar is better than struggling to
>> install foo-bar-baz.jar because you're not root.
>
> maven isn't a package manager. "Maven is a software project management
> and comprehension tool."
>
> They share some similar functionality, but completely different goals.
>
>>
>> And yes, it would be nice to *be able* to install gcc, etc., in
>> one's home directory. For non-Gentoo distros this helps get
>> around
>> the lack of slots too. Perhaps if you supported home directory
>> packages then you wouldn't consider maven the enemy.
>
> Firstly I don't dislike maven because it installs packages into a
> users
> home. Manly I dislike it because the phases it has are completely
> incompatible with portage. For example, maven has an annoying habit
> of
> attempting to download files which should, within the portage world at
> least, have already been fetched (yes I know about offline mode).
> That
> makes packaging it on Gentoo very difficult. Therefore as a nicer
> summary I dislike maven purely because I am unable to package it on
> Gentoo. It should be noted that gentoo packages maven-bin and users
> are
> free to do whatever they want with it.
>
> Also /home is not something a package manager ever installs packages
> into.
>
>>
>> Right now as a non-root user of a machine with limited libs, I
>> often
>> have to chase source dependencies myself and do the ./configure
>> --prefix=/home/ricky/local, make, make install dance.
>
> I would suggest that instead of doing that, you approach the admins
> and
> ask for permissions or a vm or a chroot/jail, etc, etc. Or at least
> come up with a mechanism to report required libs to them. Do your
> admins know you do this? I would hate for them to add noexe to the
> mount options for /home. I also wonder how you know when a new
> version
> of that library is available, say one that fixes a security
> vulnerability (aka privilege esculation, if you are smart enough you
> might not need to ask for root access). Im not really a fan of LFS
> implementations, I like to let package managers do what they do best
> (aka manage packages)
>
>>
>> Are CPAN and easy_install also the enemy?
>
> We have g-cpan. Its a nice little utility that 1) auto generates
> ebuilds from cpan packages and 2) installs cpan packages (without
> needing a ebuild btw) in a way that means it is known to portage. As
> for
> easy_install I believe I heard that egg support within eclasses but im
> unsure of the details.
>
>>
>> Ricky Clarkson wrote:
>>> I expect you can safely ignore sbaz. I don't think many
>> people use it.
>
> Oh I really should bring up that the reason we even new about sbaz was
> someone filed a bug report on it. Seems it is distributed in the bin
> package but not in the source.
>
> I was hoping this was going to be constructive.
>
>

Alistair, you may want to hit the scala-tools list. Also note that
sbaz has just "switched ownership" in terms of maintainers. We have
long term plans to support pulling libraries from a maven repository
as sbaz packages, so perhaps with your ideas we can make everyone happy?

Sent from my iPhone

On Jan 10, 2009, at 8:22 PM, Alistair Bush wrote:

> Hi Scala Team.
>
> This email is to find out some information on how scala should be
> packaged on a distribution. It is a open ended email which will
> hopefully come up with some interesting ideas/solutions. It should be
> noted that (sadly) my exposure to scala is limited. So forgive me
> if I
> get anything wrong :)
>
> Gentoo Linux is a source based distribution that provides a build
> script
> (ebuild) to our users which allows them to install a package. I won't
> into any detail about this but if you are interested see [1].
>
> The main discussion I wish to raise is about sbaz. Basically as I see
> it sbaz allows a user to install/update scala packages within managed
> directories. Now, within a distribution it is considered bad for
> programs to install anything without integration with the system
> package
> manager (pm). If the pm is not aware of those packages uninstalling
> the
> base package (in this case scala) will leave undesired/unwanted files
> which possibly could have security issues. As a result of this I have
> no current plans to have the installed scala directory as an managed
> directory.
>
> sbaz is also able to create managed directories. In which it
> downloads
> a version of scala and installs it into that directory. This at least
> allows users to have a scala install and then add addition packages to
> it safely (from a system perspective). Yet doing this creates
> duplicate
> scala installs which is an aim of packaging scala in the first place.
> As an pretty good example of this. I have packaged sbaz-1.25 yet when
> using sbaz-setup it downloads and installs within the managed
> directory
> sbaz-1.24.
>
> I would like to know how scala should be packaged. Whether the
> current
> situation is acceptable and just any ideas on this.
>
> Now, this is an example of an ideal way to package scala.
>
> Basically it would be to separate scala into a scala.base and
> scala.home. Where scala.base contains the base files, scala-
> {compiler,
> library, etc, etc}.jar plus bin files (scala, scalac, etc, etc) while
> scala.home would contain any additional packages that have been
> installed. With this there could actually be more than one scala.home
> on a system. For example each user could have and use independently
> of
> each other their own scala.home with its own packages installed in
> each.
> scala.home would not contain the files also within scala.base ( tho
> maybe it could link to them if necessary ).
>
> Anyway, I hope to there is some good feedback from this email.
>
> Alistair Bush
>
> ali_bush@gentoo.org
> Gentoo Linux Java Developer
>
> [1] http://www.gentoo.org/proj/en/java/java-devel.xml

Hey in quick followup (sorry),  You should make sure James Matlik is aware of the Gentoo issues.  He's the right person to be talking to in terms of how sbaz works internally.   In terms of what the sbaz packages look like, you need to talk to the packages (so for the scala ones, someone on EPFL).   Also, see (http://code.google.com/p/esmi/wiki/SbazDesignNotes) and (http://www.scala-lang.org/node/292) for more context.

Hope this can provide some more context to the discussions.  Also I've added in the scala-tools user list.  The scala-debate thread is fun for debating issues, but I think we need to solve a problem here quickly, and debate a long term solution.   Correct me if I'm wrong.


-Josh

On Sun, Jan 11, 2009 at 10:08 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Alistair, you may want to hit the scala-tools list.  Also note that sbaz has just "switched ownership" in terms of maintainers.  We have long term plans to support pulling libraries from a maven repository as sbaz packages, so perhaps with your ideas we can make everyone happy?



Sent from my iPhone

On Jan 10, 2009, at 8:22 PM, Alistair Bush <ali_bush@gentoo.org> wrote:

Hi Scala Team.

This email is to find out some information on how scala should be
packaged on a distribution.  It is a open ended email which will
hopefully come up with some interesting ideas/solutions.  It should be
noted that (sadly) my exposure to scala is limited.  So forgive me if I
get anything wrong :)

Gentoo Linux is a source based distribution that provides a build script
(ebuild) to our users which allows them to install a package.  I won't
into any detail about this but if you are interested see [1].

The main discussion I wish to raise is about sbaz.  Basically as I see
it sbaz allows a user to install/update scala packages within managed
directories.  Now, within a distribution it is considered bad for
programs to install anything without integration with the system package
manager (pm).  If the pm is not aware of those packages uninstalling the
base package (in this case scala) will leave undesired/unwanted files
which possibly could have security issues.  As a result of this I have
no current plans to have the installed scala directory as an managed
directory.

sbaz is also able to create managed directories.  In which it downloads
a version of scala and installs it into that directory.  This at least
allows users to have a scala install and then add addition packages to
it safely (from a system perspective).  Yet doing this creates duplicate
scala installs which is an aim of packaging scala in the first place.
As an pretty good example of this.  I have packaged sbaz-1.25 yet when
using sbaz-setup it downloads and installs within the managed directory
sbaz-1.24.

I would like to know how scala should be packaged.  Whether the current
situation is acceptable and just any ideas on this.

Now, this is an example of an ideal way to package scala.

Basically it would be to separate scala into a scala.base and
scala.home.  Where scala.base contains the base files, scala-{compiler,
library, etc, etc}.jar plus bin files (scala, scalac, etc, etc) while
scala.home would contain any additional packages that have been
installed.  With this there could actually be more than one scala.home
on a system.  For example each user could have and use independently of
each other their own scala.home with its own packages installed in each.
scala.home would not contain the files also within scala.base ( tho
maybe it could link to them if necessary ).

Anyway, I hope to there is some good feedback from this email.

Alistair Bush

ali_bush@gentoo.org
Gentoo Linux Java Developer

[1] http://www.gentoo.org/proj/en/java/java-devel.xml

Hey in quick followup (sorry),  You should make sure James Matlik is aware of the Gentoo issues.  He's the right person to be talking to in terms of how sbaz works internally.   In terms of what the sbaz packages look like, you need to talk to the packages (so for the scala ones, someone on EPFL).   Also, see (http://code.google.com/p/esmi/wiki/SbazDesignNotes) and (http://www.scala-lang.org/node/292) for more context.

Hope this can provide some more context to the discussions.  Also I've added in the scala-tools user list.  The scala-debate thread is fun for debating issues, but I think we need to solve a problem here quickly, and debate a long term solution.   Correct me if I'm wrong.


-Josh

On Sun, Jan 11, 2009 at 10:08 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Alistair, you may want to hit the scala-tools list.  Also note that sbaz has just "switched ownership" in terms of maintainers.  We have long term plans to support pulling libraries from a maven repository as sbaz packages, so perhaps with your ideas we can make everyone happy?



Sent from my iPhone

On Jan 10, 2009, at 8:22 PM, Alistair Bush <ali_bush@gentoo.org> wrote:

Hi Scala Team.

This email is to find out some information on how scala should be
packaged on a distribution.  It is a open ended email which will
hopefully come up with some interesting ideas/solutions.  It should be
noted that (sadly) my exposure to scala is limited.  So forgive me if I
get anything wrong :)

Gentoo Linux is a source based distribution that provides a build script
(ebuild) to our users which allows them to install a package.  I won't
into any detail about this but if you are interested see [1].

The main discussion I wish to raise is about sbaz.  Basically as I see
it sbaz allows a user to install/update scala packages within managed
directories.  Now, within a distribution it is considered bad for
programs to install anything without integration with the system package
manager (pm).  If the pm is not aware of those packages uninstalling the
base package (in this case scala) will leave undesired/unwanted files
which possibly could have security issues.  As a result of this I have
no current plans to have the installed scala directory as an managed
directory.

sbaz is also able to create managed directories.  In which it downloads
a version of scala and installs it into that directory.  This at least
allows users to have a scala install and then add addition packages to
it safely (from a system perspective).  Yet doing this creates duplicate
scala installs which is an aim of packaging scala in the first place.
As an pretty good example of this.  I have packaged sbaz-1.25 yet when
using sbaz-setup it downloads and installs within the managed directory
sbaz-1.24.

I would like to know how scala should be packaged.  Whether the current
situation is acceptable and just any ideas on this.

Now, this is an example of an ideal way to package scala.

Basically it would be to separate scala into a scala.base and
scala.home.  Where scala.base contains the base files, scala-{compiler,
library, etc, etc}.jar plus bin files (scala, scalac, etc, etc) while
scala.home would contain any additional packages that have been
installed.  With this there could actually be more than one scala.home
on a system.  For example each user could have and use independently of
each other their own scala.home with its own packages installed in each.
scala.home would not contain the files also within scala.base ( tho
maybe it could link to them if necessary ).

Anyway, I hope to there is some good feedback from this email.

Alistair Bush

ali_bush@gentoo.org
Gentoo Linux Java Developer

[1] http://www.gentoo.org/proj/en/java/java-devel.xml

Sbaz is very similar to Ruby Gems and CPAN in spirit.  Both of those are allowed on Gentoo (with sudo access), so why not sbaz?  Gems in particular is worthy of note seeing as it places tons of files in weird places, including installing things directly into /usr/bin.

For what it's worth, I actually never use sbaz for anything other than casual experimentation.  All of my dependencies are managed using Buildr in a user-local Maven repository.  I update Scala manually (though, on Gentoo I would do it using Portage if the tree contained a recent version).

Daniel

On Sun, Jan 11, 2009 at 9:34 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Hey in quick followup (sorry),  You should make sure James Matlik is aware of the Gentoo issues.  He's the right person to be talking to in terms of how sbaz works internally.   In terms of what the sbaz packages look like, you need to talk to the packages (so for the scala ones, someone on EPFL).   Also, see (http://code.google.com/p/esmi/wiki/SbazDesignNotes) and (http://www.scala-lang.org/node/292) for more context.

Hope this can provide some more context to the discussions.  Also I've added in the scala-tools user list.  The scala-debate thread is fun for debating issues, but I think we need to solve a problem here quickly, and debate a long term solution.   Correct me if I'm wrong.


-Josh

On Sun, Jan 11, 2009 at 10:08 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Alistair, you may want to hit the scala-tools list.  Also note that sbaz has just "switched ownership" in terms of maintainers.  We have long term plans to support pulling libraries from a maven repository as sbaz packages, so perhaps with your ideas we can make everyone happy?



Sent from my iPhone

On Jan 10, 2009, at 8:22 PM, Alistair Bush <ali_bush@gentoo.org> wrote:

Hi Scala Team.

This email is to find out some information on how scala should be
packaged on a distribution.  It is a open ended email which will
hopefully come up with some interesting ideas/solutions.  It should be
noted that (sadly) my exposure to scala is limited.  So forgive me if I
get anything wrong :)

Gentoo Linux is a source based distribution that provides a build script
(ebuild) to our users which allows them to install a package.  I won't
into any detail about this but if you are interested see [1].

The main discussion I wish to raise is about sbaz.  Basically as I see
it sbaz allows a user to install/update scala packages within managed
directories.  Now, within a distribution it is considered bad for
programs to install anything without integration with the system package
manager (pm).  If the pm is not aware of those packages uninstalling the
base package (in this case scala) will leave undesired/unwanted files
which possibly could have security issues.  As a result of this I have
no current plans to have the installed scala directory as an managed
directory.

sbaz is also able to create managed directories.  In which it downloads
a version of scala and installs it into that directory.  This at least
allows users to have a scala install and then add addition packages to
it safely (from a system perspective).  Yet doing this creates duplicate
scala installs which is an aim of packaging scala in the first place.
As an pretty good example of this.  I have packaged sbaz-1.25 yet when
using sbaz-setup it downloads and installs within the managed directory
sbaz-1.24.

I would like to know how scala should be packaged.  Whether the current
situation is acceptable and just any ideas on this.

Now, this is an example of an ideal way to package scala.

Basically it would be to separate scala into a scala.base and
scala.home.  Where scala.base contains the base files, scala-{compiler,
library, etc, etc}.jar plus bin files (scala, scalac, etc, etc) while
scala.home would contain any additional packages that have been
installed.  With this there could actually be more than one scala.home
on a system.  For example each user could have and use independently of
each other their own scala.home with its own packages installed in each.
scala.home would not contain the files also within scala.base ( tho
maybe it could link to them if necessary ).

Anyway, I hope to there is some good feedback from this email.

Alistair Bush

ali_bush@gentoo.org
Gentoo Linux Java Developer

[1] http://www.gentoo.org/proj/en/java/java-devel.xml