[Kde-scm-interest] Package splitting

Oswald Buddenhagen ossi at kde.org
Wed Jan 27 15:46:33 CET 2010


On Wed, Jan 27, 2010 at 03:07:45PM +0100, Thiago Macieira wrote:
> Em Quarta-feira 27 Janeiro 2010, às 14:46:21, Oswald Buddenhagen escreveu:
> > On Wed, Jan 27, 2010 at 02:01:28PM +0100, Thiago Macieira wrote:
> > > Git submodule isn't atomic at all. It cannot be used to indicate
> > > atomicity because it requires at *least* two operations (two pushes),
> > > any of which could fail. In our case, it would require three: two
> > > submodules and the supermodule.
> > > 
> > 
> > but i think that's non-critical for dependencies on "additive" changes,
> > as it is sufficient to commit the lib change first, then the supermodule
> > change and finally app change.
> 
> I don't think updating the supermodule is necessary.
> 
> What gain do you have here?
> 
as i said a few mails before. that the supermodule would force a minimal
sha1. i don't know whether it can be currently done, but it should be
doable.

> > it becomes a problem if the change really needs to be atomic because
> > the lib change is "substitutive", i.e., breaks existing
> > functionality. the "pseudo-atomicity" would be still sufficient to
> > eliminate most cases of "update foolibs, sucker" cases, though.
> 
> That's why we have "Binary Incompatible Mondays" for.
> 
yes, i considered that. but i must admit, i find them quite a pita to
adhere to personally (though that would be significantly reduced by
pervasive use of git). and other projects with shorter dependency chains
might want a shorter cycle - but at some point it simply becomes
ineffective.

> > that's actually an interesting idea: one could have micro-versionchecks
> > (on sha1's) in the cmake files. however, updating them manually would be
> > a royal pita.
> 
> Doesn't need to be sha1. Libraries have version numbers. We just have to have 
> room in the numbering to increase it when necessary.
> 
yes, but nobody *wants* to maintain micro-version information ...
depending on sha1s would limit the pain to the "consumer" side, but
that's still painful.



More information about the Kde-scm-interest mailing list