Packaging GNU Smalltalk .star archives

Hello,

I'm about to upload gst 2.95f packages to Debian
experimental. But I'm
not sure how to package .star archives yet.

I don't think it makes sense to put every .star archive in
its own
Debian package. At the very least .star archives depending
on external
libraries should go in a separate package, so that packages
containing
those external libraries are pulled only when needed.

That would give something like:
 * gnu-smalltalk-gtk for GTK.star, BloxGTK.star and
gst-gtk.so
 * gnu-smalltalk-tk for BloxTK.star and blox-tk.so
 * gnu-smalltalk-ncurses for NCurses.star
 * gnu-smalltalk-gdbm for GDBM.star and gdbm.so
 * gnu-smalltalk-postgresql for DBD-PostgreSQL.star
 * gnu-smalltalk-mysql for DBD-MySQL.star
 * gnu-smalltalk-zlib?

There are some subtles differences here on how those
packages would be
handled, because for instance GTK.star is architecture
dependent[1],
while usually .star files are not. And some .star files
directly load
external libraries, e.g. NCurses.star loads libncurses.so
and
DBD-PostgreSQL.star loads libpq.so[2]. Besides, we'll need
to be
carefull to make sure package.xml dependencies are captured
in Debian
packages[4].

I don't know whether some other .star packages should have
their own
Debian package, e.g. glorp, sunit.

To compare with Debian Java packages of libraries using
native code[3]:
native code is stored in an extra package, so that for
example
libwhatever-java package depends on libwhatever-jni. For
.star packages
that rely on an internal library (i.e. not NCurses.star nor
DBD-PostgreSQL.star) that might be the way to go.

What's your opinion on this?

Thanks,

Thomas

[1] no problem with multiarch anymore: .star files are
searched for 
    in the smalltalk image dir too
[2] self note: 'replace this with sonames'
[3] see for example http://pa
ckages.debian.org/sid/libglib-java
[4] maybe we'll need to write a debhelper program for this




_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> I don't think it makes sense to put every .star archive
in its own
> Debian package. At the very least .star archives
depending on external
> libraries should go in a separate package, so that
packages containing
> those external libraries are pulled only when needed.

Yes, probably.  The others can go in gnu-smalltalk-common.

> That would give something like:
>  * gnu-smalltalk-gtk for GTK.star, BloxGTK.star and
gst-gtk.so
>  * gnu-smalltalk-tk for BloxTK.star and blox-tk.so
>  * gnu-smalltalk-ncurses for NCurses.star
>  * gnu-smalltalk-gdbm for GDBM.star and gdbm.so
>  * gnu-smalltalk-postgresql for DBD-PostgreSQL.star
>  * gnu-smalltalk-mysql for DBD-MySQL.star

This one can go in the main distribution because it does not
depend on 
libmysqlclient.

>  * gnu-smalltalk-zlib?

> Besides, we'll need to be
> carefull to make sure package.xml dependencies are
captured in Debian
> packages[4].

Yes.

> I don't know whether some other .star packages should
have their own
> Debian package, e.g. glorp, sunit.

No, I don't think so.  They can just go in
gnu-smalltalk-common.

> [1] no problem with multiarch anymore: .star files are
searched for 
>     in the smalltalk image dir too

Yes, that's good because you don't have anymore problems
with 
gnu-smalltalk-common including a package that is
architecture dependent.

Maybe it would it be better to name the packages, for
example, 
libgtk2-gnu-smalltalk, libtk8.4-gnu-smalltalk,
libncurses5-gnu-smalltalk 
(or maybe even using -gst as a suffix)?  I don't know, I
just got it 
from your example of libglib-java.

Paolo



_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hello Paolo,

thanks a lot for your input.

On Fri, Nov 23, 2007 at 10:12:44AM +0100, Paolo Bonzini
wrote:
> > * gnu-smalltalk-mysql for DBD-MySQL.star
> 
> This one can go in the main distribution because it
does not depend on 
> libmysqlclient.

Indeed.

> Maybe it would it be better to name the packages, for
example, 
> libgtk2-gnu-smalltalk, libtk8.4-gnu-smalltalk,
libncurses5-gnu-smalltalk 
> (or maybe even using -gst as a suffix)?  I don't know,
I just got it 
> from your example of libglib-java.

There are two schools here it seems[1]:
 * $language-$libbindings, e.g. python
 * $libbindings-$language, e.g. perl, ruby

I guess we'll have to pick one and stick to it.

Thomas

[1] http://people.debian.org/~terpstra/me
ssage/20071123.132507.2afe4060.en.html


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

>> Maybe it would it be better to name the packages,
for example, 
>> libgtk2-gnu-smalltalk, libtk8.4-gnu-smalltalk,
libncurses5-gnu-smalltalk 
>> (or maybe even using -gst as a suffix)?  I don't
know, I just got it 
>> from your example of libglib-java.
> 
> There are two schools here it seems[1]:
>  * $language-$libbindings, e.g. python
>  * $libbindings-$language, e.g. perl, ruby
> 
> I guess we'll have to pick one and stick to it.

I prefer the latter.

Thanks!  I'll delay 3.0 (which is not ready, anyway) to
after you ironed 
out Debian packaging problems.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk