[pkg-s48-maint] list to do

[Jorgen Schaefer]

Sorry for the long delay in the response, I got sidetracked by
"real life" issues.

Lionel Elie Mamane <lionel@mamane.lu> writes:

>> It is non-trivial to get Scheme 48 to install multiple copies of the
>> same version. The paths that control everything are semi-distributed
>> thorough the build process. Unless you think it would be
>> definitively needed, I won't try to create versioned packages.
>
> It would be nice, but it is not essential. I'm surprised it is much
> more difficult for s48 than it is for scsh, though.

It might be easy, I only looked at it shortly and dropped the idea
again. The annoying part is to find every mentioning of the path
names, which are partly hardcoded (but I had to do this before to
be able to package it for Debian, so it should work again ;-)).
I'll think more about it.

>> We wanted to use tla or darcs for the version control. At the
>> moment, I use dpatch for the Scheme 48 package, and I wonder why we
>> (I) should use a more elaborate setup at all - I never used a
>> revision control system for my packages yet,
>
> And you tell me that *now*? Couldn't you have mentioned this *before*
> we started discussing which VC system we would use and how?

I hope that was not meant as annoyed as it sounds, else I
apologize - I definitively wanted to use a VC for the packages,
but never got around to do it. I should have done so earlier.

My current (local) Scheme 48 package uses darcs-buildpackage. It's
quite ok to use and work with. dpb-importorig does most of the
annoying work, the rest is just creating the debian repository and
working on that one. I used a separate branch to pull my patches
to, and darcs-buildpackage built the packages quite well. So that
works here, and I'm quite happy about that.

I don't want to enforce my preferences on revision control tools
on you. If you want to use darcs and have any questions, please
let me know.

> That's what a "full-blown" VC system helps us manage.

Thanks for the explanation, it really helped me get things into
the right perspective.

> For applications written in s48, I'd definitely use the upstream
> name, without special "is written in that language" string in the
> name. For libraries, number 2. The "lib" part is important :-)
> Examples below.
>
> If the upstream name is too generic (such as install-lib), I'd add
> s48- or -s48, yes. I have started my install-lib packages with
> "scsh-install-lib".
>
> For scsh, add the major/minor version to
> it. E.g. sunterlib-scsh-0.6. scsh 0.7 will be incompatible with scsh
> 0.6 (and 0.8 incompatible with 0.7), thus I'm planning for parallel
> installs all the way there.

Naming conventions:
- Libraries:
  lib<package>-s48
  lib<package>-scsh-0.6
- Other programs:
  Upstream name, no specific mentioning of what it is "written in"

- If it's too generic (install-lib), add scsh/s48 prefix:
  scsh-install-lib
- For scsh, add the version:
  libsunterlib-scsh-0.6

Does that sum it up well?

> Proposed name: scsh-install-lib

Sounds good to me.

I'm interested in packaging sunterlib. If you have the package
ready for anything, I'd be interested in finding out how to use it
to install sunterlib for scsh. :-)

>> tinyclos
>
>  tinyclos-s48, tinyclos-scsh-0.6

This should be libtinyclos-..., right?

Greetings,
    -- Jorgen

-- 
Debian GNU/Linux Developer
forcer@debian.org
http://www.forcix.cx/