Bug#626352: arguments for bug
Tomáš Hnyk
tomashnyk at gmail.com
Fri May 13 16:23:50 UTC 2011
On Fri, 13 May 2011 12:13:25 +0200, Alan Woodland <awoodland at debian.org>
wrote:
> On 12 May 2011 21:59, Tomáš Hnyk <tomashnyk at gmail.com> wrote:
>>> Nice to hear that others consider my decision for recommends
>>> reasonable.
>>> The original poster might like to reread the guidelines when to use
>>> Depends and when Recommends.
>>
>> Do you mean this:
>> http://www.debian.org/doc/debian-policy/ch-relationships.html ?
>>
>>
>> "Depends
>> This declares an absolute dependency
>> The Depends field should be used if the depended-on package is required
>> for
>> the depending package to provide a significant amount of functionality.
>>
>> Recommends
>>
>> This declares a strong, but not absolute, dependency.
>>
>> The Recommends field should list packages that would be found together
>> with
>> this one in all but unusual installations."
>>
>>> The fact that many <x>-data packages are
>>> Depends is just because they fit the criterion that the package <x>
>>> really
>>> does not work without <x>-data. This is not the case for texmaker.
>>
>> Well, at least for the translations, I think that amounts to
>> "significant
>> amount of functionality" - consider someone who only speaks French and
>> uses
>> her system in French. If she installs with --no-install-recommends, she
>> will
>> get a program with interface she does not understand. Therefore, she
>> will
>> not be able to use the program or only with utmost difficulty.
>> Therefore,
>> the program will not be functioning for her. I think that is the
>> reasoning
>> of many of the <x> packages.
>>
>> So I will once again propose to split texmaker-data into texmaker-data
>> depending on texmaker and including the icons and the translations and
>> texmaker-docs being recommended by texmaker.
>
> I sponsored the original upload of this package and IIRC the split was
> largely based on arch: any vs. arch: all with recommends instead of
> depends selected because it's neither broken nor useless without the
> contents of -data, which in my view matched the description of
> "strong, but not absolute".
>
> The translations issue is an interesting one that perhaps warrants
> further discussion -devel and/or explicit mention in policy. (I'm not
> aware of any formal consensus). If the goal of --no-install-recommends
> is "minimise" disk space then requiring all of the translations would
> seem to be at odds with it. Then again not shipping the translations
> seems to be at odds with the basic principles of userfriendlyness and
> "play nicely with non-English languages". Is --no-install-recommends
> pretty much equivalent to --no-unneeded-user-friendlyness though?
>
> I have no strong opinions either way, but I'm interested in the
> broader question from a policy POV.
>
> Alan
I cannot speak from a normative POV (being just a casual Ubuntu user with
no through knowledge of the policies). I use --no-install-recommends
because when doing a clean install and not upgrading (which I prefer or
various reasons, one of them being the ease of migrating to the new
computer since I have most things connected to installing scripted), I
have a list of packages I install on top of Ubuntu stock install. If I do
not use --no-install-recommends, the list of packages to be installed
grows almost twice, which I do not want. On the other hand, this is about
the first time I have been bitten by me using --no-install-recommends, so
I think it is not equivalent to not-being-unnecessary-user-friendly.
I tried to switch to Czech for one session and almost all the programs are
translated (even though some of them only partially). Also, all programs
have icons (and I think that for a GUI program to have account amounts to
a "significant amount of functionality"). So I think as it stands today,
programs ship icons and translations with their packages or depend on
packages shipping the icons and translations. For some large packages,
translation packages are language specific and depend on some metapackage,
but that is not the case of texmaker. Overall, I think the behaviour of
texmaker is not consistent of with the rest of the package pool. I base my
observations on Ubuntu but I think it is not very different from Debian in
this regard.
Moreover, I think Alan is right that some kind of guidelines would be
handy, I think that both Andreas' and mine POVs are compatible with the
current guidelines. I think that my POV is more in line with the current
de facto standard, but that is (a) just my opinion and (b) by any means an
indication that the current state of affairs is the desired one.
Regards,
Tomas
More information about the debian-science-maintainers
mailing list