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!
