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

Re: Small package or big dependencies?



+++ Joachim Breitner [Aug 03 10 19:09 ]:
> Hi,
> 
> Am Dienstag, den 03.08.2010, 09:01 -0700 schrieb John MacFarlane:
> > Baking in blobs would work okay for filestore, since it's just one
> > short text file, but if you had, say, a graphics library that had
> > lots of image data files, you might not want to bake those all into
> > the binary -- it would make the binary very large. So this doesn't
> > seem a general solution to the general problem.  It also requires
> > cooperation of the upstream packager, who must decide to use hsb2hs
> > instead of cabal data files.
> 
> Sure, but there are interesting use cases that makes developing and
> deploying hsb2hs worth it. I hat to manually turn a text file into a
> bunch of "..." lines myself a few times (CSS and JS-Code, IIRC).
> 
> > But I still don't see a good solution to the versioning problem.
> > Let me just summarize the problem to make sure I understand it correctly.
> 
> Note that we have to differenciate between the build-time-dependencies
> of the gitit source package and the gitit binary package!
> 
> > * If gitit were to depend on an exact version of libghc6-filestore-data, then
> >   it would also have to depend on an exact version of libghc6-filestore-dev.
> 
> Not correct. The gitit binary package would depend on the specific -data
> package in the same version as the -dev package _it built with_, because
> it contains filestore code from that version.
> 
> >   And this would be inconvenient because you'd have to update the gitit
> >   package every time you updated the filestore package, no matter how
> >   minor the change.
> 
> Semi-Right. Because the old -data package would not be around any more,
> gitit would have to be rebuilt. But as the source package does not have
> to be changed, a binNMU is sufficient, so this is no big deal.
> 
> > * If gitit did not depend on an exact version of libghc6-filestore-data,
> >   then there would be a potential for breakage, because gitit would be
> >   using the old filestore code (that it was compiled with) together with the
> >   new filestore data.
> 
> Correct.

Thanks for the explanations. Given all of this, I agree that the
first solution -- with the gitit binary package depending on
an exact version of libghc6-filestore-data -- is best.

John


Reply to: