Bug#790524: src:gmt: takes over files from several unrelated packages
Sebastiaan Couwenberg
sebastic at xs4all.nl
Thu Jul 9 21:25:07 UTC 2015
Hi Andreas,
On 07/09/2015 10:53 AM, Andreas Beckmann wrote:
> On 2015-07-03 22:11, Sebastiaan Couwenberg wrote:
>>> * libpsl-dev
>> To resolve the conflict I'm considering renaming the GMT libpsl to
>> libgmt-psl.
>
> Sounds reasonable, temporary Conflicts is fine.
> I was about to reopen since that somehow didn't work and -1~exp6 didn't
> mention anything about it ... but then I saw a typo correcting git
> commit :-) so let's see how -1~exp6 does.
For now I've not included the library rename in the new gmt revision,
because I'm still waiting for upstream to provide feedback on their
opinion of these conflicts.
I think the psl library is a good candidate to rename upstream too,
unlike the gmt binary.
>>> * turnin-ng
>>> * pslib-dev
>> These man page issues should be resolved with the Conflicts that were
>> added in gmt (5.1.2+dfsg1-1~exp5).
>
> Adding Conflicts against random packages should only be a temporary
> measure and needs to be resolved cleanly by some renaming, too.
> In my interpretation of the policy the "Two different packages must not
> install programs with different functionality but with the same
> filenames." can be extended to manpages easily: "Two different packages
> must not install manpages describing different things but with the same
> filenames."
I don't share your interpretation. The policy explicitly talks about
binaries, expanding that to man pages seems unfounded overreach to me.
Because of the close relationship between binaries and their man pages,
I see some merit in your interpretation but not enough to apply the
policy for binaries to their man pages.
> (Why should anyone be prevented from starting a project using both
> libgmt-dev and pslib-dev (and maybe even libpsl-dev)? Disclaimer: I
> don't know anything about either of these packages ;-) )
The answer could be a simple as: "Because the upstream developers of the
respective projects don't allow them to co-exist on the same system."
> BTW, why is there no file conflict on a "/usr/bin/project" (or similar)
> binary with turnin-ng? If one package is missing such a binary, there is
> no need for a corresponding manpage in section 1.
In the GMT 4 packaging the gmt project binary was installed in
/usr/lib/gmt/bin/, the separate commands have been converted to
subcommands of the gmt binary in GMT 5.
The GMT 4 packaging also appended 'gmt' to the man page sections, I've
reintroduced this in the ~exp7 revision that was just uploaded.
I think that should do.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
More information about the Pkg-grass-devel
mailing list