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