Re: Too many Recommends (in particular on mail-transport-agent)
Adam Borowski <kilobyte@angband.pl> writes:
> On Tue, Jun 06, 2017 at 09:06:46AM -0700, Russ Allbery wrote:
>> And what happens here is, I think, typical: any one person often thinks
>> choices of recommends make no sense, but a broader perspective provides
>> quite a bit of justification.
> It is remarkable that out of 94 unsatisfied recommends on my system you
> disagreed with just 6, despite them going contrary to the maintainer's
> wishes thus being certain to be controversial.
I skipped all of the ones that you didn't mark as BAD, since the other
classifications were beside the point, and commented only on the ones
where your classification leaped out at me as incorrect. I'm pretty
dubious about the whole list, but as I said at the start of my message, I
was giving some specific examples where I had the information readily to
hand (or thought I did; I was wrong on libpurple).
> Also, it's quite obvious this list was very hastily done, with often
> just a few seconds per entry.
And you did this in response to a message of mine that was asking for
something more thoughtful, which is part of why I reacted the way that I
did.
> I did not happen to know ghostscript can also be used not for .ps but
> also for some .pdf workflows (I prefer to not use blatantly fake-free
> software) but my main point stands: an _image_ manipulation program
> cannot be said to import _documents_ in "all but unusual installations".
> And "gsfonts" is not even ghostscript itself but merely an add-on for it.
PostScript is one of the common image types (in the form of EPS) that
ImageMagick manipulates. Use of ImageMagick to handle those files is not
as common as JPEG or PNG, but certainly not unusual, particularly if you
have tool chains that like to generate EPS; I used to run into it a lot
when processing TeX documents, for instance. gsfonts may be a requirement
for correctly converting some of those files to other formats because it
provides the fonts that are "built in to any PostScript printer" and
therefore do not have to be embedded in files (by specification).
This is pretty classic Recommends stuff, just in a field that you're not
personally using ImageMagick for. One can argue about the merits of
having a Swiss Army knife tool like ImageMagick that is pretty much
guaranteed to only be used for 10% of what it can do by any given user of
it, but in that context, support for PostScript images is well within its
scope and less obscure than many other formats it handles.
>>> libmail-sendmail-perl: po-debconf
>>> * BAD: why would po stuff want to send mail?
>> This is for podebconf-report-po. I assume you've not packaged something
>> with translations?
> I'm not dealing with any po-heavy packages at the moment, yeah. It
> might indeed be useful for some deep po stuff, but the package I want is
> "debhelper".
podebconf-report-po is not "deep po stuff." It should be used by
literally every maintainer who packages something with debconf
translations, whenever the debconf templates are changed.
> Technically, I do know how to package without debhelper (see "goodbye")
> but I still would prefer to use it.
po-debconf includes the tools the package maintainer should be using to
manage debconf translations. You could conceivably separate the ones
needed during a build from the maintainer tools, but I'm not sure it's
really worth the effort for the tiny amount of disk space this would save.
>> This, like all other lib*-bin packages in Debian, are external helper
>> utilities *run by the library* under specific situations, which are split
>> into a separate package to avoid SONAME issues.
> Nope, its contents are four misc "extra utilities" that are mean to run
> _by the user_ or at most by some scripts. They look somewhat useful
> (purple-remote allows controlling pidgin from cmdline, etc) but are
> seriously hampered by a lack of documentation. On the other hand, not a
> single one is ever called by the library:
> strings `dpkg -L libpurple0`|grep purple-remote
> strings `dpkg -L libpurple0`|grep purple-send
> strings `dpkg -L libpurple0`|grep purple-send-async
> strings `dpkg -L libpurple0`|grep purple-url-handler
Ah, indeed, I apologize; you're entirely correct. I made a bad assumption
about how the URL handling in libpurple worked and should have done a
little bit of research first.
I think (barring other information I'm not aware of) I agree with you
here, and also think that the name of this package is probably wrong and
should be something more like purple-tools or the like.
>> I'm going to stop here, since at this point I think this is just going
>> to turn into a thread educating you about Debian packaging conventions
>> you've apparently not encountered before, which is really not a good
>> use of everyone's time.
> Uhm... could you be please be a bit more civil?
I apologize; you're right. I should have been more civil.
I do have to also add that I found your message considerably less civil
than how I think you actually intended it. I found your message rather
condescending and dismissive of the analysis maintainers have put into
their package metadata, and confrontational about your personal opinions
about some widely used software, in a way that felt honestly like you were
intentionally provoking people.
That said, that's not an excuse, and I will try to be more civil.
> The issue is systematic, and we have far more than "a few" cases. The
> very post you're responding to had 94 of them,
There were absolutely not 94 real problems on that list. It was a largely
unfiltered dump of Recommends of packages on your system. I would be
surprised if there were more than 10 real problems there, most of which
are quite minor in terms of user impact and didn't seem to be to be worth
the amount of energy that you're putting into this.
That said, I absolutely welcome bug reports against any of my packages for
too-broad Recommends, and I think we all should feel the same! And if
there's wording we can change on the Policy side to try to make it clearer
when Recommends should be used and to head off some of these issues, I'd
love to talk that over (probably best on a Policy bug).
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: