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

Re: Small package or big dependencies?



Hi.

Il 03/08/2010 18:01, John MacFarlane ha scritto:
> I still think a general and automatic solution, in which haskell-devscripts
> makes a separate -data package containing all the 'data-files' specified
> in the cabal file, is better than baking in blobs (as hsb2hs would do).
> 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.

I agree with you: having data embedded in binaries is a bad idea; it
makes things more difficult when you want to share this data with other
programs, it makes big binaries (which mean big memory occupation,
perhaps for things that need to be loaded only in particular cases;
moreover, there is no sharing among packages for different
architectures), it confuses program with data (that gives problems when
you want to edit data without touching the program, which is a perfectly
reasonable scenario).

I think that the drawbacks of having an extra package (even if for just
a very small file) are really smaller.

> 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.
> 
> * 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.
>   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.
> 
> * 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.
> 
> Do I understand correctly?

Yes, that's correct. Anyway, the first point is just an added burden,
the second one is (or, at least, can be) a real problem. So I believe
that the first solution is better.

At least, that's true for a general case. The specific case of gitit
against filestore is a bit different, because, given how the data file
is used, it is rather improbable that a change in filestore without the
same change in the data file could cause big problems. Anyway, I still
think that the first solution is cleaner (and with the advantage of
mirroring the general solution, which helps maintainability).

Thanks, Giovanni.
-- 
Giovanni Mascellani <mascellani@poisson.phc.unipi.it>
Pisa, Italy

Web: http://poisson.phc.unipi.it/~mascellani
Jabber: g.mascellani@jabber.org / giovanni@elabor.homelinux.org

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: