On 15/01/14 21:09, Svante Signell wrote:
> I cleaned out the duplicated code between xpdf and poppler (which is a
> continuation of xpdf becoming a PDF rendering library). Some more
> cleaning is still needed, to actually remove all irrelevant code (and
> update relevant code). Is it possible to create a new code base from my
> changes and the many patches?
This (and the build-system fixing you mentioned in another mail) sounds
like a job for a new upstream project, rather than something that is
in-scope for Debian packaging. If you[1] want to be its upstream
maintainer, I would suggest either forking xpdf under a new name[2] of
your choice, or asking its (former?) upstream maintainers to give you
custody of the "official" continuation of xpdf.
If nobody wants to be the de facto upstream maintainer of this fork,
then I don't think it's appropriate to keep it in Debian either: I think
there's a limit to the sort of changes that it's appropriate to make via
distro patches. Refactoring and deleting unnecessary code is a great
thing to do as an upstream, but not as a distributor.
If, as an upstream, your only release mechanism is via Debian, that's
your decision, of course; but even if it is, I think a fork that behaves
like its own upstream project should be identified as such.
I haven't used xpdf for years, so I have no informed opinion on the
choice between "it's worth taking over and fixing" vs. "let it die,
switch to something else".
S
[1] all uses of "you" refer to any prospective maintainer, not just Svante
[2] not necessarily a new name for the package/binary (particularly if
the current upstream is completely dormant), but it'd be polite to at
least have a conventional name for your version in its documentation,
similar to the way {AGPL,Aladdin,ESP,GNU} Ghostscript are labelled
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d7cd2d....@debian.org
