Hi,
Alan wrote (02 May 2013 22:10:29 GMT) :
> 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?
I'm not holding that strong a position on this topic. I'd like it to
be the general case, yes, but I don't think it's worth
over-engineering the whole thing to make every corner case consistent
with the rest -- see below.
> 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.
I think this is good enough. At least the notification message will be
partly correct, and it will be quite clear to me that this feature is
currently enabled.
> To behave another way, I would have to cache the list of installed
> software, which I won't do before the freeze. Future improvement?
I don't think it's needed to go this far.
>> >> > 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.
Fair enough. At this point, I would entirely understand if you
preferred not to investigate any further. Your call.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
