[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: mosh



Hi David,

[...]
> > 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.)
> 

Ok, it seems that unpatching mosh really isn't quite an option. May I thus
suggest a different route? You could try to convince the Debian libgc
maintainers to produce a -src package (see
http://packages.debian.org/search?keywords=-src for examples thereof) that
provides the source code of the Debian binary packages. I suppose the
maintainers should also be more than happy to take all the bugfix patches and
include them in the Debian package. Then re-build libgc with any options mosh
requires and be happy :-)

> > 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.
> 

I think mosh maintainers should at least seek to include some run-time checks
for the options required for correct operation.

[...]
> 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.
> 

I don't claim to be an expert on this, but it seems like a sane way to follow.

> 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?
> 

If the build script is fine license-wise, then just patch it in - that seems
much less work than repacking. Keep it simple... (it's complicated enough anyway
:-) ).

Best,
Michael

Attachment: pgpWJHmANhu7H.pgp
Description: PGP signature


Reply to: