Re: Small package or big dependencies?
+++ Joachim Breitner [Aug 02 10 21:06 ]:
> Hi John,
>
> thanks for joining the discussion.
>
> Am Montag, den 02.08.2010, 11:49 -0700 schrieb John MacFarlane:
> > - the gitit and filestore packages will both be supplying this file --
> > I don't know enough about debian to know if this will cause problems,
> > but wouldn't you get a warning that the package you're installing
> > is overwriting an existing file?
>
> this is a valid point. I guess the filestore API does not provide a way
> for the calling application to tell it where the file is stored, so that
> gitit could use a gitit-specific location such
> as /usr/share/gitit/git-hook?
Correct. It uses the standard Cabal mechanism by which libraries
can get access to data files. Many Cabal packages use the same method.
> > - it's going to be a maintenance headache, since the maintainer of
> > the gitit package will have to make sure that the post-update file
> > is updated in gitit whenever it is changed in filestore.
>
> Lets assume for a moment that filestore changes the interface to the
> hook, i.e. the old filestore will not work with the new hook and the old
> hook will not work with the new filestore.
>
> Variant A: libghc6-filestore-data package.
> 1. gitit links against old filestore
> 2. filestore gets updated
> 3. users installing gitit run old filestore code, but new hook
> → breakage
Yes, that's a good point. In this case breakage would be unlikely,
but in general it could happen.
> Variant B: hook in gitit.
> 1. gitit links against old filestore. while building the package, the
> package scripts copy the hook file from libghc6-filestore-dev (where it
> is placed somewhere soley to be copied from) into the gitit package.
> 2. filestore gets updated
> 3. users installing gitit run old filestore code and old hook
> → everything is fine
Yes, except we'd still have the problem of two different packages
supplying a file at the same path, as noted above.
> If the maintainers copies the file manually, then this might be a cause
> for errors, but otherwise the scheme is the same.
>
>
> Did you consider a third variant: Actually linking the hook into your
> code, as a (Byte)String constant, and writing it out to disk when
> creating a gitit-enabled repository? Then there is no such problem at
> all, and the hook is always tied directly to the code. (Probably does
> not work as you’d need to update the hook when you upgrade the code,
> right?)
In the case of filestore, I could do that. I used to do something like that
for pandoc, but switched for various reasons to using data files. As you
note, it's a maintenance hassle if the bytestring is just a literal in the
code. I could avoid this by using template haskell, but that introduces its
own headaches (recall the difficulties TH caused on some architectures with
earlier versions of pandoc). I could also avoid it without template Haskell,
possibly, with a custom Setup.hs that reads the data file and writes out a
Haskell file. But now we're getting farther and farther from the nice, clean
mechanism for data files that Cabal provides.
> Do you copy the hook to the git repo or symlink it to a central
> location.
Copy.
> > In addition, I think there's good reason not to address this problem
> > in a way that is specific to gitit. After all, the same problem will
> > affect any package that (a) supplies an executable that should be installable
> > without Haskell libraries, and (b) depends on libraries that rely on data
> > files. I'm sure there are other examples than gitit. If there aren't now,
> > there will be soon. So it might be worth putting some thought into how to
> > proceed.
> >
> > One possible solution, which would require modifying haskell-devscripts,
> > would be this. If a library (say, filestore) has data files
> > that it accesses via Paths_filestore, then there could be an additional debian
> > package for it that just installs the data files, so we'd have:
> >
> > libghc6-filestore-dev
> > libghc6-filestore-prof
> > libghc6-filestore-data
> >
> > libghc6-filestore-dev and gitit could both depend on libghc6-filestore-data,
> > which would have no further dependencies of its own.
> >
> > It seems to me that this would be a clean solution to the problem.
>
> as pointed out above, this has issues while we employ statical linking.
> We could alleviate this a big by having strict dependencies onto the
> -data package, but I’d like to avoid them.
Yes, I see the problems for all the solutions proposed so far. I still think
that it would be best to come up with a general solution, since it will be
more and more common to have libraries that use data files, and executables
that depend on them. (Just as an example, suppose I split the pandoc cabal
package into a library package and an executable package. Then we'd have the
problem with pandoc too.)
Maybe someone else on the list will have a better solution?
John
Reply to: