[Tails-dev] feature/remember_installed_packages : next step…

Delete this message

Reply to this message
Author: Alan
Date:  
To: tails-dev
Old-Topics: Re: [Tails-dev] Please review and merge feature/remember_installed_packages
Subject: [Tails-dev] feature/remember_installed_packages : next steps
Hi,

I updated the ticket [1]. You'll find remaining discussions in this
email (answers related to blockers for 0.18 are in another email).

[1]. https://tails.boum.org/todo/remember_installed_packages/

On Wed, 01 May 2013 21:56:09 +0200 intrigeri <intrigeri@???> wrote:
> Alan wrote (01 May 2013 18:36:11 GMT) :
> > On Tue, 30 Apr 2013 10:05:23 +0200 intrigeri <intrigeri@???>
> > wrote:
> >> >    set_activated()
> >> >    packages = get_additional_packages()
> >> >    if not packages:
> >> >    syslog.syslog("WARNING: no packages to install, exiting")
> >> >        return True

> >>
> >> How about moving the call to set_activated() after checking if
> >> there are packages to install? I assume we don't want to later
> >> "upgrade" software that we did not install on the first place, do
> >> we? (I mean, we're lucky the "upgrade" operation, in the way it's
> >> currently implemented, installs software when missing, but I'd
> >> rather not silently depend on this weird behaviour.)
> >>
> > I implemented it like that on purpose: if you call install (which is
> > the intended behaviour of upconing the "activate additional software
> > packages" button in Tails-greeter) and there is a configuration file
> > in the persistence, then additional software packages are activated
> > (even if the file is empty). I choosed that so that if you modify
> > the configuration file and reconnects the network later on, then the
> > behaviour is coherent with what would happen if the file was not
> > empty (the new additional software are installed). Makes sense?
>
> Well... I now see what you mean, but I happen to dislike it.
> Having behaviour consistent between "there was nothing in the config
> file" and "there was something in the config file" (at the time that
> I expect it to be read and used) does not look like a worthy goal to
> me. Rather the contrary.
>
> As a potential user (and a very happy one that you're working on it!),
> the way I understand it, this option/feature is about having stuff
> automatically installed *at login time* (and possibly upgraded
> later on, I don't care).
>
> So, having packages installation triggered by a network disconnect /
> reconnect would be useless and possibly painful behaviour to me:
>
>     1. I can't really rely on it because I guess it'll be undocumented
>        bonus behaviour that we probably won't test at release time,
>        and may be broken at any time.

>
>     2. Once the notify message is fixed, the feedback I have once the
>        stuff is effectively installed will tell me about an *upgrade*
>        having succeeded, and I certainly don't expect this to mean
>        some additional packages were *installed*.

>
>     3. So, I won't take any benefit from it, while it will eat system
>        resources behind my back, in a way that will be hard
>        to understand.

>
> What do you, and others, think?
>

I don't really care what we choose for this specific case. But if I
understand you well, you would like that any upgrade just upgrades and
doesn't install any new package? Currently, if

1. I have a config file to install packages A and B
2. I add package C to the config file
3. I reconnect to the network

then I will end up with C installed. To behave another way, I would
have to cache the list of installed software, which I won't do before
the freeze. Future improvement?

> >> >    apt_get_env['PATH'] =
> >> > "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

> >>
> >> What's the intent?
> >>
> > Otherwise apt-get fails because some of the commands it calls is
> > missing from the environment NetworkManager uses to execute its
> > hooks.
>
> OK. I'm surprised NM gives an environment that lacks one of the
> needed components, since we've never seen this before in our other
> hooks. E.g. 60-ttdnsd.sh uses `service', that's in /usr/sbin.
>
> So, I wonder which directory is missing.
>
> Are you sure you did not rather experience this behaviour outside of
> the NM dispatcher, e.g. by running the script by hand in some shell
> environment that was lacking the sbin components in $PATH?
>

I'm sure I added this after seeing the script fail in a "real"
environnment while if was working when I run it by hand.

Cheers