Re: idea: generalized soft dependencies
On Thu, May 9, 2013 at 9:24 PM, Eugene V. Lyubimkin <jackyf@debian.org> wrote:
> tl;dr: I would want to be able to differentiate between, for example,
>
> - "install this or your system will break (unless you did special things so it does not)";
> - "install this unless you know you'll never need this feature";
> - "this things is worth installing by default".
What I mean is that you either have to define the values for these classes
or maintainer A will write 70% and B 80% to transport the same meaning.
And these classes need to be defined really well. E.g. your second class
is the same as the third class (for me, others will see it differently)
as a package for a feature I will need at some point is well worth to be
installed and a package worth to be installed is one providing a feature
I will need …
Currently we have 3 slots we can place dependencies in. Providing 100 slots
isn't going to fix the problem of not having a deterministic entity placing
the dependencies in the correct slot. For all practical proposes we have an
infinite amount of entities deciding based on their current state/experience
which causes new experiences forming a self-feeding reinforcement loop.
>> > Soft-Depends: iceweasel {50%,tag:desktop}, curl {95%,if_not_installed:wget}
>>
>> So supposedly on 50% of all desktops iceweasel is installed which can
>> in turn be used by the software having this dependency. Great, but I still
>> have no idea why 50% installed it and 50% don't.
>
> It was an example of maintainer guessing that half of users of some
> software will want also iceweasel installed, provided the computer "is
> desktop".
Yeah, and what I meant is that this doesn't give me any new useful info.
That iceweasel does something useful in combination with this package is
clear just by listing it here. That its not a Recommends tells me that it
is not part of what upstream/the maintainer considers a "usual installation",
but it is in no way telling me why 50% install it – and whats the propose of
an annotation if it isn't going to help me?
>> Which 50% group I am part of? The tag desktop might give a hint, but
>> such tags need to be defined and carry a meaning. A tag like "laptop"
>> tells me that it will help with powersaving (which would probably be the
>> better tag name, as I will like want to install it on my phone too),
>> "printing" is useless if I don't have a printer, "online" and "streaming"
>> might not be the best ideas if I have no internet connection at all …
>> That's a lot harder of course, but caries way more useful information as
>> I have no idea how many people don't have their own nuclear power plant,
>> highspeed internet or a printer. 30, 50 or 90% ? I might be able to answer
>> that in my area (and I would probably still be wrong), but not on a global
>> scale.
>
> I don't propose any specific attribute. I propose to have an ability to later
> discuss and standardize these attributes.
>
>> > Soft-Depends: debdelta {10%,text:"to enable automatic delta downloading"}
>>
>> While this solves the why, we have a new problem: Translations
>> And these texts are quickly written in a way a user can't use:
>> What the hell is a "delta"? -> debian-l10n-english to the rescue!?
> [...]
>
> You speak about problems of a specific example attribute. We might use
> text: attribute, we might not use is. Unless your point is say that
> (all) attributes don't help (and therefore the proposal doesn't make the
> situation better), this is not what proposal is about.
Yes, I speak about this specific type of attributes, namely such which have
free text in them. If I want a free-form documentation of why it could be
useful to install this or that we have documentation for that, starting with
the long description. Attributes should be limited to something which can be
evaluated by a package manager automatically to help the user, not another
blob of text nobody is going to read (and understand).
I do this because its out of question that a package manager needs to help
a user more to manage the ever-growing pool of packages to choose from.
(At least I highly doubt there is anyone thinking we don't need to.)
The question is how and my personal impression is that this is neither
solved by adding 97 new classes of (soft-)dependencies nor by free-form
text and I outline why I think this in the hope that I am either convinced
of the opposite or that we find something else which would work.
>> Of course, this doesn't work if wget is used instead of debdelta in the
>> example as wget is used by a lot of stuff, but always for the same task:
>> So annotating all dependencies on wget with the tag use:downloading just
>> feels wrong. And the package wget is already tagged with use:downloading,
>> we just don't make proper use of this so far.
>
> Sounds like I had not enough good example if you feel this was about
> 'use:downloading'. The idea of this example was not to repeat packages
> descriptions, but say how the soft dependency will help exactly this
> package in question. This one should illustrate better:
>
> libcupt2-0: Soft-Depends: ed (text:"to enable downloading PDiffs")
>
>> [...] we should really use the current information we
>> already have much more [...]
>
> I kind of disagree here. Currently we have zero dependency-specific
> information apart of a) what group of Depends/Recommends/Suggests the
> maintainer put the dependency to b) possible free-form explanations in
> long descriptions or other package documentation.
We have package namespaces (e.g. *-l10n-*, *-dbg, *-dev, xul-ext-*) and
we have debtags which can hint at what the dependency will be used for
(wget downloads stuff, iceweasel views websites, cups prints, …)
and in which context (whats the point of suggesting a KDE frontend if the
user uses GNOME and a frontend for this environment is available).
That's quiet a lot already and only very barely used, if at all, currently.
Granted, in the libcupt2-0 example above the information that ed is for
editing text isn't going to help much to answer "why", but a free-form text
is either to short to provide an understandable answer or is a copy&paste
from proper documentation. Something like "ed [use::bandwidthsaving]" would
allow me to configure my package manager to install everything which saves
me money by default and offload the details to the documentation.
debdelta could be tagged with it by default on the other hand, a bit like a
dependent of a package in Multi-Arch is usually better at deciding which
type it is than the package depending on it.
Best regards
David Kalnischkies
Reply to: