Re: [Monotone-devel] bundled libs

[Nathaniel Smith]

On Sun, Nov 20, 2005 at 06:50:43PM +1100, Daniel Carosone wrote:
> On Sat, Nov 19, 2005 at 05:13:50AM -0800, Nathaniel Smith wrote:
> > They've all had such critical flaws at some point or another, yeah,
> > and switching back and forth is too much effort.
> >
> > [list of libraries and local changes, by memory]
> 
> are these tagged or tracked on the functional equivalent of a vendor
> branch at all, such that it's easy to see what local changes have been
> made, and to propagate upstream changes from new releases?

I don't actually know, I just know that every time one of these
projects releases a new version, the one in monotone's tree magically
gets upgraded :-).  Perhaps some of the people who actually do the
work here has something useful to say...

> (no irony intended, but to join this with another thread..) It strikes
> me that this kind of thing is a really good example requirement for
> directory suturing functionality: a main project branch, with some
> subdirectories sutured in from various 'vendor' branches, with local
> changes.  It would be ideal if the scope of the suturing allowed a
> propagate from an updated libfoo to only affect lib/foo in the target
> branch.
> 
> At the moment, I think you can do this, but only if the directory
> paths line up between the 'vendor' and 'main' branch?
> 
> At least this specific example probably only needs to work at the
> directory level (rather than combining files within the one dir), and
> c/should be a manual step to graft the contents together (a little
> like a filesystem mount, perhaps).
> 
> I'm sure it makes things horribly complex with corner cases, but it
> sure would be handy for users.  I imagine something similar to:
> 
> nvm.monotone$ monotone graft org.openssl lib/openssl
> 
> This would pull the contents of the root directory of the named branch
> into the named subdir of the current branch, and somehow remember the
> linkage for later propagates.

Yep.  This isn't suturing; suturing is where you drop one file or
directory right on top of another and weld them together somehow.
You don't want to intermingle the files from the two merged trees; you
want to graft on a directory that exists on one side into a particular
(unused!) location on the other side.

This is the "root directory move" use case.  Support for it
basically falls out for free from the roster model, and basically the
only reason it doesn't work right now is that we stuck in an
assertion to disable that code path.  It requires some extra UI,
tests, and supporting code in the merger (not to implement merging,
just to detect the special sorts of conflicts that can arise when such
things are allowed), so we figured we'd defer that until the basic
functionality was stabilized.

Once someone gets around to fixing up those parts, though, your
example will Just Work.

> > Overall, it's just a tradeoff; the amount of pain it would take to
> > deal with supporting whatever random versions people happened to have
> > lying around is too high a cost, when we have so many more important
> > problems to work on.
> 
> Understood, with one relatively minor qualification.
> 
> This is perfectly reasonable when using monotone's internal
> configure/make/etc building stand-alone; then, as you say, you pretty
> much have to deal with whatever you happened to find.
> 
> For those maintaining integrated package system builds (like NetBSD's
> pkgsrc, gentoo, etc etc..) then the surrounding infrastructure can
> enforce specific version dependencies, and add fixes not yet taken
> upstream on those dependencies... all presuming this information is
> clearly known or accessible.  Easy diffs against a vendor branch,
> along with some well-chosen commit log comments, would be a great way
> to facilitate this.

Sometimes the fixes are not appropriate for upstream -- e.g., we
disable Lua's exposure of the system() call, not because it's bad that
Lua has it, but because _in the context of monotone_, we don't want it
to be possible to have shell escaping bugs.

But, hey, if packagers want to hack things up locally, go wild... just
don't tell your distro's lua etc. packagers that we sent you... ;-)

-- Nathaniel

-- 
"...All of this suggests that if we wished to find a modern-day model
for British and American speech of the late eighteenth century, we could
probably do no better than Yosemite Sam."