Re: RFS: mosh
Hi Michael,
On 10/07/11 22:39, Michael Tautschnig wrote:
> I'm sorry, I haven't yet reviewed your package, I'm only commenting on the
> issues you raised.
No problem, I appreciate it.
>> For reference, I have attempted to build against a libgc using a default
>> configuration and it breaks badly at runtime.
>>
>
> Given that, according to the discussion in #156, some earlier version had
> apparently worked fine: couldn't the Debian package simply revert that
> "optimization" that requires GC_DONT_ADD_BYTE_AT_END?
At the time this was implemented it was quite a significant change and
touched most aspects of the interpreter. I think this would be quite
hard to revert, and doing so would basically constitute a fork. However
I haven't tried to do it, so I can't really be sure.
It's worth noting that the bundled version of libgc is also a CVS
version, as several bugs unrelated to the optimization were found in the
stable libgc. (I get the impression from upstream that this is because
Mosh uses the C++ wrapper, which is part of libgc but not as heavily
tested.)
> I must state that a package that only works under very specific compile-time
> settings of an external library makes me shiver. It seems that mosh has no
> safety checks and the necessity to rely on such low-level optimizations raises
> questions about the design of this software...
Sure, I agree, and I will probably raise a question on the ML about this.
>> #2. psyntax-mosh requires several Scheme sources to be compiled into a
>> single 'binary' (which is actually text, but not human-editable).
>> However, the build script requires a previous version of Mosh. Releases
>> are distributed with a precompiled version so the users doesn't need an
>> older version. I asked about this on IRC, and it seems it's
>> unacceptable to use the precompiled file in the final build, so two
>> solutions were suggested. One is to initially build using the
>> precompiled file and then rebuild over the top using the
>> now-bootstrapped version (The version doesn't necessarily need to be
>> older.) The other method is to split the source package into two
>> packages, mosh-bootstrap and mosh, where mosh-bootstrap is
>> arch-independent and mosh arch-dependent. Neither of these are clean
>> but that is probably unavoidable.
>>
>
> Well, then, which route did you follow? I don't really see a problem with the
> rebuild-over-the-top variant, although of course this introduces some
> complexity.
I didn't follow either of these routes yet as I wanted to make sure I
wasn't completely off track before working on one. Personally I agree
that the dual-build seems cleaner, so I would prefer to go with that.
Another complication (hah) that I should have mentioned in my original
message was that the build script for the 'binary' that I'm referring to
here, which is fairly substantial human readable source code, was NOT
shipped with the upstream tarball. However, it is under a free license
and is in the git respository, for some reason it was just excluded when
releasing the tarball. As a result, to actually do this dual build, I
would have to patch in the build script, or repack. Are either of these
legally OK? Which do you think would be better?
Cheers,
David
Reply to: