On Sun, Dec 20, 2015 at 10:27:41PM +0900, Charles Plessy wrote:
> Le Mon, Dec 14, 2015 at 11:16:24PM +0900, Charles Plessy a écrit :
> > The current behaviour of the backports suite is deeply rooted in how APT works.
> > Following the "install" command for a package, APT will look at the versions
> > present in its cache and their priorities ("pin values"), and following the
> > rules explained the apt_preferences manpage, will either install one of these
> > versions or do nothing. In that sense, there is actually no difference between
> > "installing" a package and "upgrading" a package. For backport packages
It is dense and simplified, but at least not wrong, so fine by me.
> > without a counterpart in the base suite, the backports versions are
> > valid candidtes and will be installed without warning. This is true
> > as well for packages in the "experimental" suite.
You never get a "warning" if a package is taken from a 'non-base suite'
(lacking the definition of what would be the 'base suite' as that is an
idea which only exists in the head of people and is nowhere codified,
beside that if we really explore this idea each package has its own base
suite it should be coming from which quickly leads us to define a way of
specifying a way of expressing preferences for possible sources…).
stable main, stable non-free, experimental and backports are all
perfectly fine sources which can all include a package and distribute
versions of this package. Preferences define how apt picks a version
among the potentially many options as its candidate – which is set by
the user ultimatively, but the maintainers of a source can provide
a default value if they so choose.
It is a natural consequence that – lacking better options – apt will
pick a candidate coming from a 'non-base suite' even if that is as low
in preferences as experimental is by default.
The closest thing to a warning you get at the moment is a notice if apt
picks a *different* candidate version based on your request e.g. if you
do "apt install foo/experimental" it will say it gets foo from
experimental (and maybe bar as well, which foo has a strong versioned
dependency on). If you do "apt install foo -t experimental" on the other
hand nothing tells you if foo (or bar) is installed from experimental
before you press 'y'.
> > David wrote that he would like to implement a pattern system inspired from
I think I wrote 'we'. The team is very small, but it is still big enough
to reasonably deny my use of "pluralis majestatis" for 'us'. ;)
> > aptitude, and utilise this to configure and display package listings in a way
> > that gives a chance to the user to cancel the installation of a backports
> > package when this installation happens only because there is no version
> > available in the base suite.
That is a very negative summary. As I tried to explain in my last mail
I believe users can have very different views on how to rate a presented
solution – and I believe apt should make it (more) easy to rate
a solution by displaying more information. Personally, I doubt it will
significantly increase the amount of cancelations, but it helps letting
the user feel in control which is always a good thing (beside that it
helps educating users and presets the right expectation value).
In your previous mail you raised the question of which other frontends,
which potentially ranges from none to all depending on what you expect
to be told by your frontend. That is why we have so many.
> I would like to report the fruit of our discussion to the debian-cloud
> mailing
Frankly, I haven't seen much of a discussion – just a question being
raised and me trying to answer it from my personal POV. If my POV is now
elevated via a summary to "fuits of a discussion", I think 'we' have to
rethink the "pluralis majestatis" thing… but maybe I have just missed
all the good parts of the discussion as I am not subscribed to -boot or
-backports. I am just responding to calls to deity(@). ;)
The best "fruits" for me in this thread were actually the private
replies I got, which I haven't answered as I don't really know what to
say, but still are very grateful for as even after all things said in
public I actually ended up labeling this experience as good, which
I hadn't even considered a potential outcome initially.
So, thanks a lot!
Best regards
David Kalnischkies
Attachment:
signature.asc
Description: PGP signature