Re: Bug#856652: RFS: xpdf/3.0.4.real-4
On Tue, 2017-03-07 at 08:30 -0500, The Wanderer wrote:
> On 2017-03-07 at 08:12, Svante Signell wrote:
...
Sorry, I still don't get it: - Which packages still depend on
> > poppler, unless via xpdf? The ones directly dependant on poppler are
> > not affected.
>
> Yes, they are; if a newly-discovered bug which exists in both codebases
> is fixed in xpdf but not in poppler, those packages will still be
> affected by the bug.
The code bases are disconnected with my proposed release, see below. Of course
the old versions, like xpdf-3.04-4, are still using the poppler patches.
> Thus, introducing non-poppler-based xpdf back into the archive means any
> such bugs will have to be fixed in two places rather than in one; this
> is the downside which I understand to be part of the objection, and part
> of the reason for splitting out the poppler code into separate packages
> in the first place.
>
> Unless you're saying that the divergence between poppler and upstream
> xpdf is so extreme that talking about the same bug existing in both
> codebases is not meaningful - in which case this objection disappears
> entirely, and I apologize for the false trail.
In my opinion, the code bases have diverged too far, yes. That's the reason I
chose to remove all poppler-based patches from my xpdf-3.04.real-5. But doing so
required the full upstream tarball, hence the proposed xpdf-3.04.real-4.
(maybe it all should be made in one release xpdf-3.04.real-1, completely
disconnecting xpdf from poppler.
> > - Which repositories containing poppler code are you talking about?
>
> The Debian repositories which contain the packages found by 'apt-cache
> search poppler'. (Thinking about it now, I think the term "archive"
> might be more usual than "repositories" for the meaning I intended.)
>
> > - Which code has to be brought back to the xpdf package, causing
> > problems? Isn't it enough to bump the upstream version and go on from
> > there, as Adam suggested?
>
> The code which is in the upstream version but which has been split out
> of the Debian version into the poppler packages. Reverting xpdf to the
> upstream codebase, rather than basing it on poppler, brings this code
> back in implicitly.
It brings in the omitted code from the upstream tarball, yes. But it also
removes the poppler patches making xpdf no longer dependant on libpoppler. The
only thing left depending on poppler in the newly proposed packages is a
Recommends: on poppler-data for Asian language support (CJK characters).
> > - I did a search for reverse dependencies for xpdf (there are no
> > build-rdeps)
> > apt-cache rdepends xpdf
...
> Did you build this list manually, or is this actual output of the above
> command? Because the output I get from 'apt-cache rdepends' is of a very
> different format, and one which might well be considered less useful.
Yes, that list was manually created.
Reply to: