On 2016-04-01 11:23 PM, Dmitry Bogatov wrote: > On 2016-04-01 4:03 PM, Neil Mayhew wrote: >> I'm packaging a Haskell project that needs the now-discontinued >> haskell-download-curl. (Discontinued in Debian, not discontinued on >> Hackage.) > I am not sure why `download-curl' was dropped (found no commit),
>From my README, > This repo … was forked from the now-discontinued Debian package of the > same name, which was part of the DHG_packages git repo and was removed > in commit |ed54226|. On 2016-04-01 11:23 PM, Dmitry Bogatov wrote: > but most likely it caused too much friction when co-installing with > stackage. The commit message of ed54226 says: > commit ed5422645f15bd4f3190464af40d90a24dea7e03 > Author: Joachim Breitner <[email protected]> > Date: Mon Jul 27 11:01:06 2015 +0200 > > Remove packages that have been removed from the archive > > See #792614 #792614 says: > RM: Haskell package spring cleanup > Reported by: Joachim Breitner <[email protected]> > > the Debian Haskell Group has identified a set of 106 packages that are > probably not worth keeping in Debian. > On 2016-04-01 11:23 PM, Dmitry Bogatov wrote: > If you convince maintainer to make package part of Stackage and > maintain it's compatibility with it, it would simplify ressurection of > package in Debian. Do you mean the upstream (Hackage package) maintainer? (Don Stewart) I don't think there's much chance of that. He appears to have lost interest a long time ago. > But it may be difficult to convince a man to use github. /* Major > fault of stackage. */ I'm not hosting the Hackage package, just the debian directory forked from DHG_packages. I don't think that would have any influence on making download-curl part of Stackage. In any case, I'm using github only out of convenience, and would be open to any other solutions. > On 2016-04-01 4:03 PM, Neil Mayhew wrote: >> This gives me a problem, of course. However, my package is unlikely >> to end up in Debian, and will most likely just be distributed within my >> company by hosting it on our internal repo. (Although it is >> open-source: https://github.com/neilmayhew/RepoExplorer/). So the >> easiest solution I could see was for me to resurrect the debian >> directory for haskell-download-curl and host it myself. I did this by >> cloning >> DHG_packages and using git filter-branch to extract just >> p/haskell-download-curl/. I added a couple of commits changing the >> maintainer and VCS address and adding a new README, and pushed the >> result to github: >> >> https://github.com/neilmayhew/haskell-download-curl >> >> The package builds using pbuilder, and my main program is able to >> build against it, also in pbuilder. > [I am not DD] Your tool seems to be not-too-mature and probably is not > suitable for Archives, Correct. I haven't done a lot towards making my tools package fully Debian-compliant (eg no manpages yet). However, I'm not really wanting it to be in Debian. It's the dependency, libghc-download-curl-dev, that I'm really concerned about (which used to be in Debian and was dropped). I can't build my package without that dependency, and I don't want to make the dependency a part of my package. So the solution I've come up with is to make it a separate git repo. I've then made that repo an optional submodule of my tools' repo, as a convenience for anyone wanting to build packages of my tools. > but I would like `DependencyRoots' to be availiable to me. Is building a package with debuild, using the detailed instructions I've given in the README, not sufficient for you? I could consider splitting the two tools into separate repos, and since DependencyRoots doesn't use download-curl that would avoid the dependency problem at least for that tool. >> Is this an OK thing to do, and are there any details I haven't got >> right, particularly regarding attribution and copyright? I don't have >> a LICENSE file at the top level yet because I didn't see a copyright >> statement for the packaging itself. The one in debian/copyright >> appears to be for the upstream source rather than the packaging. > debian/copyright should mention 'Files: debian/*'. I agree. That should have been in the original package in DHG_packages. However, it wasn't, and I can't create such a statement since I'm not the copyright holder of the debian directory. I assume someone from DHG is, or maybe the whole of DHG, so I'm waiting for someone from DHG to comment. > Also, do you know about 'cabal-debian' tool? I didn't. Thanks for the pointer. I ran cabal-debian on the upstream sources and it produced something very similar to what I obtained from DHG_packages, so I don't see any need to redo the packaging since what was in DHG_packages is mature and tested. However, cabal-debian did add a "Files: debian/*" clause to debian/copyright: > Files: debian/* > Copyright: held by the contributors mentioned in debian/changelog > License: BSD3 That seems to get around the problem nicely, so if I don't hear from anyone else, I'll just add that and be done with it.
