Re: [Monotone-devel] bundled libs

[Daniel Carosone]

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?

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

Or maybe it's enough just for propagate to take some directory
translation/limitation arguments?
 
Back to the original topic, at least partly:

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

--
Dan.

pgpg4n1e7tKs2.pgp
Description: PGP signature