twb@cyber.com.au (Trent W. Buck) writes:
> Blockers for current darcs in sid are:
>
> DONE mmap 0.5.x
> DONE hashed-storage 0.5.3+
> DONE parsec 2.x
I don't understand this lintian complaint.
Maybe someone needs to deal with it:
I: libghc-parsec2-prof: conflicts-with-version libghc-parsec-prof (<< 3.0.0-5)
N:
N: An earlier-than version clause is normally an indication that Breaks
N: should be used instead of Conflicts. Breaks is a weaker requirement that
N: provides the package manager more leeway to find a valid upgrade path.
N: Conflicts should only be used if two packages can never be unpacked at
N: the same time, or for some situations involving virtual packages (where
N: a version clause is not appropriate). In particular, when moving files
N: between packages, use Breaks plus Replaces, not Conflicts plus Replaces.
N:
N: Refer to Debian Policy Manual section 7.4 (Conflicting binary packages -
N: Conflicts) for details.
N:
N: Severity: normal, Certainty: wild-guess
> TODO rebase quilt patches against 2.5.2
Done.
dget http://cyber.com.au/~twb/tmp/darcs_2.5.2-1.dsc
> TODO triage open darcs/hashed-storage/mmap bugs
Done. No major changes.
> I've done the first three just now, but I'm not in the Uploaders field
> for mmap or parsec so I can't upload source packages to the archive.
>
> I'm not sure if Darcs should still be explicitly forcing parsec2. Last
> time I asked, I was told in no uncertain terms that parsec3 SHOULD NOT
> be used in production; that only parsec2 was "fast enough". If this is
> no longer the case, parsec2 can be left to bitrot and Darcs can be
> unforced.
The above two paras need to be dealt with by someone else, as does
Joachim's #600287. I'll file an RFA presently referring to this post,
and then I'm pretty much done with Debian/Darcs.