Re: Forking a discontinued package
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 <mail@joachim-breitner.de>
> 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 <nomeata@debian.org>
>
> 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.
Reply to: