[pkg-fso-maint] [PATCH] install.sh: add $SD_PART1_SIZE and $SD_SWAP_SIZE user variables

[Luca Capello]

Hi Steffen!

On Thu, 19 Feb 2009 13:34:21 +0100, Steffen Moeller wrote:
> Apparently I perceive the world as less buggy/evil here.

Only a small note, and then I will consider this point closed: it is not
the world which is buggy/evil, but if there are standards, they must be
respected.

> For a start, a larger boot partition is a safe bet, IMO. It doet not
> cost us much to allow for that.

The problem here is that /boot has nothing to do with user data and the
cost to allow that is quite high: we have lost time discussing it and we
will put more effort into install.sh.

> Luca Capello wrote:
>> I, at least, will support only one Debian kernel version, the latest
>> packaged.
[...]
> The option for a larger boot partition from my understanding is not
> adding to anything that you should support. It only increases freedom
> for users.

Point taken, even if my remark was not specific to /boot on vfat, but on
the fact that you were comparing 2.6.24 (an old kernel) with 2.6.28 (the
latest one, thus the one I support).

>> On Wed, 18 Feb 2009 22:39:47 +0100, Steffen Moeller wrote:
>>> Luca Capello wrote:
>>>> Please, use uppercase variables.
>>> They are intentionally lowercase since they are of internal use only.
>> 
>> I was expecting this answer: in this case, I would prefix them with
>> something like INT_NAME.
>
> Fine. If you could accept (what you want to accept) the way it is,
> then I will go over it and change variable names to receive an
> "intern_" prefix.

I think there is a misunderstanding here: it is not me that must/should
accept, since I was not delegated to be install.sh maintainer (FYI
Joachim started coding it) nor I want this power.  I have commented on
your patches with my opinions, since I, again, consider any effort on
install.sh a loss of time, full stop.  But it seems that I am the only
one who thinks like that, thus I will stop complaining.

>> BTW, there is no way to modify a patch once it has been applied
>> without providing a new commit.  In your case, what you should have
>> done is
[...]
> Many thanks!
>
> Should I better follow Joachim's suggestion to find a publicly
> accessible location of my git repository?

Having a public repository is always a good thing, but I still prefer
patches directly sent to mailing lists, because:

1) it is easier to comment on

2) if you read the mailing lists offline, you have the patches as well

3) they are archived somewhere (mailing list archives)

If you need space, Alioth (the GForge clone provided by Debian at
http://alioth.debian.org/ ) offers the possibility to host personal
repositories for various VCSs, including Git:

  http://wiki.debian.org/Alioth/Git

Another option will be the one Joachim already offered you, i.e. you get
commit access to the pkg-fso repository:

  http://git.debian.org/?p=pkg-fso/files.git;a=summary

> Every change would then become a branch, and you diff against or
> between these branches, right?

More or less, yet.

> For now, I wish you could accept of what seems remotely acceptable for
> you, and you specify a list of changes that I should come up with for
> me to chase up.

As I stated before, I will stop complaining about new features in
install.sh and simply review the patches from a "code POV" :-)

> Maybe a second file, install-dev.sh, would be a good target? Or the
> current one becomes install-stable.sh?

This is a no-op for me, sorry, since we are adding another level of
complexity.

>>> If something went wrong, then cat `ls -lt /tmp/argsToFdisk*|head -1`
>>> will print the commands sent to fdisk.
>
> There seems to be a bug with busybox since "head -1" does not seem to
> work there.

`man head`: the correct invocation is `head -n 1` ;-)

>> While I agree on this, IMHO it renders the install.sh script harder
>> to read, because different conditions are mixed together.
>
> You mean the single vs the dual partition setups, right?

I am not sure what you mean by "single vs. the dual partition setups",
but I was referring to the complexity of your patch.

> I had felt that this would help to reduce the redundancy in code. A
> triple-partition setup with swap was a straight extension. And adding
> a fourth would now be no problem either. So, it felt right to me
> (having the situation after patch 9 in mind).

I do not remember which one was patch 9 (and I am too lazy to look for
it right now), sorry.

Thx, bye,
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 314 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-fso-maint/attachments/20090219/22bfd5b6/attachment.pgp