Re: [Tails-dev] Migrating to (something closer to) the regul…

Delete this message

Reply to this message
Autor: anonym
Data:  
A: The Tails public development discussion list
Assumpte: Re: [Tails-dev] Migrating to (something closer to) the regular Tor Browser
13/10/14 22:17, intrigeri wrote:
> Hi,
>
> anonym wrote (13 Oct 2014 15:54:06 GMT) :
>> 11/10/14 12:40, intrigeri wrote:
>>> 1. install_debian_extensions() could take the list of packaged
>>>    extensions as arguments (after the tbb_install one); sure,
>>>    that's cosmetic.

>
>> Done in commit a41768b.
>
> It's counter intuitive to me that the list of packages must be passed
> as a single argument. This construction is rarely seen elsewhere when
> passing lists of arguments. I think I would instead:
>
> # arguments: the destination directory, followed by a list of
> # extension packages
> install_debian_extensions() {
>    local destination
>    destination="${1}"
>    shift
>    apt-get install --yes "$@"
>    [...]

>
> What do you think?


TBH, I considered it (I much prefer this convention) but felt rather the
opposite, e.g. I do not remember to see it used very widely. I'm
switching happily.

>>> 2. BUNDLES should be moved to a configuration file, which first would
>>>    more clearly separate code from configuration, and second would
>>>    simplify the release process (after verifying sha256sums.txt, just
>>>    copy it to the right place).

>
>> I separated all data (url also, since it can be expected to change
>> frequently) from the hook in commit d46be96.
>
> Cool. I'm happy with the data separation, but I'm not happy with the
> implementation.


Sorry, I completely understand you; in retrospect, the variable names
looks terrible. I admit I wasn't putting my full attention to these
commits, as I was working on several things in parallel. I've applied
all your suggestions.

>> (BTW: For conflict resolution with the stuff from
>> feature/tor-browser-4.0, have a look at how it was done for experimental
>> in commit 1e9e1442e4b3ad8e82492ebd2d856ec45c02a884)
>
> I suspect I'll be able to merge feature/tor-browser-4.0 first. If this
> happens, then I'll let you merge the resulting testing branch into the
> refactoring one, and deal with the conflict resolution.


Just tell me when.

Cheers!