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

Re: dh-haskell chokes on unknown files



On Thu, 12 Jan 2017 22:45:48 +0300
Dmitry Bogatov <KAction@gnu.org> wrote:

> [2017-01-11 15:35] Sven Bartscher <kritzefitz@debian.org>
> > > Concerning 'Unhandled file' error, when I wrote this code I classifed
> > > all files into 3 packages: 'bin', 'prof', 'doc'. If I encounter unknown
> > > file, there is no clear answer where to put it in.  
> >
> > It's of course true, that dh_haskell can't just magically make up a
> > place to install these files, but from what I have seen, it seems that
> > there is no way to make an exception for individual files, even though
> > it would be trivial to list those files in <package>.install and let
> > dh_install handle them. This doesn't seem to be possible right now, as
> > dh_haskell fails before dh_install has a chance to do anything.
> >
> > I think dh_haskell should check in the .install and ignore files listed
> > there and trust that dh_install will handle them.  
> 
> I find this idea brilliant. But all this would complicate things. Not to
> forget about executable <pkg>.install file. Now I regret that I followed
> temptation to write dh-haskell in Perl.

I should have some spare time in the next few weeks, so I can invest
some time to look into this.

> > This still wouldn't cover files that have been installed
> > by cabal cut should not be part of a binary package. We could
> > probably list such ignored files somewhere so dh_haskell knows that it
> > doesn't need to worry about them, but that would be behaviour that is
> > pretty different from the rest of debhelper. (read: a solution, but
> > maybe someone comes up with something more elegant.)  
> 
> Exception list is not so elegant. Maybe it would be better to introduce
> DH_HASKELL_NON_STRICT_INSTALL, that disables this error or demotes it to
> warning? Just idea.

I think this has advantages over an exception list, but it risks that
files which should be installed slip by unnoticed. I suggest to defer
making a decision about this, until the <pkg>.install approach (which I
think is agreed upon) mentioned above is implemented, to give us some
time to think about this.

Regards
Sven

Attachment: pgp3hZSEeLEcL.pgp
Description: Digitale Signatur von OpenPGP


Reply to: