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

Re: Small package or big dependencies?



+++ Giovanni Mascellani [Aug 03 10 18:01 ]:
> Hi again.
> 
> Il 03/08/2010 09:45, Giovanni Mascellani ha scritto:
> > Il 02/08/2010 22:16, Marco Túlio Gontijo e Silva ha scritto:
> >> If gitit demands the exact version of libhgc6-filestore-data, this would not
> >> happen.  Or maybe some versioning constraint that is garanteed to work with the
> >> version of filestore that was used to build gitit.  For me, it seems that this
> >> is the most general solution, and I'd go with it.
> > 
> > Given that this solution (-data package with strict dependencies) seems
> > to be the only one without possible break scenarios, I'll implement
> > that. Of course, if better ideas will come up, I'll change the
> > implementation.
> 
> Just as a reminder: I just implemented this solution and it seems to
> work (see the last darcs patch I sent on the ML). gitit (and
> libghc6-gitit-dev, for people who wants to use gitit inside an other
> happstack project) depend on the exact version used during the
> compilation of the packages libghc6-filestore-data and pandoc (for the
> same reason as filestore). This, of course, adds additional stress when
> it comes to deal with updates of the depending-to packages: should the
> need of access to data provided by dependencies become more frequent, we
> should study a more structured solution for managing binNMU (like, right
> now, we do with dependencies among -dev packages).
> 
> Another problem that could arise in such a scenario: suppose that we
> have such a dependency chain like this
> 
>  A -> B -> C -> D
> 
> and suppose that A needs to access data provided by each one of B, C and
> D. Then, manually tracking the dependencies against the -data package
> would become quite hard (and with cost increasing with the square of the
> chain length). In that case, we should also think of a system to track
> such dependencies and manage them as well.
> 
> Luckily, this isn't an actual problem right now. Let's hope it won't
> become! :-)
> 
> Thanks to all who helped to find a solution for this problem. gitit
> appears to be nearly ready now (I just need to check thoroughly the
> copyright status), so my last ITP is going to be closed. Wonderful! :-)

That's excellent news.
By the way, have you tried using 'git push' to update a gitit wiki
repository?  I think that this won't work without tweaking on newer
versions of git. See http://code.google.com/p/gitit/issues/detail?id=104

This might be an issue for the debian package -- perhaps we need
a fix upstream before you finalize?  Probably the fix needs to go
into filestore (gitInit).  Let me know if you can reproduce the problem,
and I can probably get the fix in soon.

John


Reply to: