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

[Luca Capello]

Hi Steffen!

On Wed, 18 Feb 2009 22:39:47 +0100, Steffen Moeller wrote:
> Luca Capello wrote:
>> 1) why would one like a bigger /boot partition?
>> 
>>    * please always think about the ordinary user, i.e. someone who
>>      installs Debian on the Openmoko without being an expert GNU/Linux
>>      user
>
> It is because the first partition is also /media/card in Qtopia and a
> series of applications share it with the booting for Debian. The phone
> number database goes there, or the OpenStreetMap data, or ...

There is an important fact to be clear here: the /boot partition *must*
contain everything which is needed to boot the machine and that is all,
no more, no less.  Thus, I would say that we should not care about a bug
in other distributions, otherwise we end up adding workaround for
everything.

I know I am a bit harsh, here: the fact that Qtopia (or $WHATEVER) not
automatically mounts, but also automatically uses the microSDHC is a
bug, no matter what I think.  And it should be solved there, not on the
Debian side, which BTW does not ship any Qtopia software (yet, because
sometime in the future it could do it as there is interest for it [1]).

[1] http://lists.alioth.debian.org/pipermail/pkg-fso-maint/2008-November/000321.html

If Qtopia (or $WHATEVER) wants to go on with this behavior (which BTW is
against the FHS [2], to which Debian adheres), there could be another
solution: installing everything on a single partition, which is possible
with Qi (I have never tried it and probably will never try), but not
with U-Boot (and this is a bug in the latter as well).

[2] http://www.pathname.com/fhs/

>>    * there is no automatic way to switch between various U-Boot kernel
>>      images (the reason for a bigger /boot partition), thus if you know
>>      how to deal with symlinks and know what you are doing, then you
>>      also know how to manually create a bigger /boot partition since the
>>      beginning (this is why install.sh is separated into self-contained
>>      stages)
>
> With vfat there is no symlinks, so one would rename to uImage.bin
> whataver shall be used.

My fault, sorry.

> I would now for instance copy the 2.6.24 version next to the installed
> 2.6.28 one and start comparing the two more.

I, at least, will support only one Debian kernel version, the latest
packaged.  This because not only building the kernel is time consuming
(it requires at least 5-6 hours on a native ARM machine, not the FR, and
with a minimum set of modules), but because I am already out of time.
Moreover, AFAIK there is no kernel hacker in the pkg-fso team, which
means that the low-level support we can provide for the kernel is really
suboptimal.

In your case, a better option would be to install upstream FSO-MS5
kernel, which should behave exactly like the Debian one, since the
latter has been compiled with the same config.  Then, if you find a bug
in both kernels, the bug is upstream, otherwise it is Debian-specific.

>> 2) why do you need a swap partition?  I have not followed the
>>    discussion on this matter, so providing link to constructive
>>    threads is enough

This question is still valid, but I would prefer to discuss it in a
proper thread, where only the swap partition issue (and not also the
/boot on vfat one) is dealt with.

>>>  # run partitioner
>>> -if [ "$SD_PART1_FS" = "vfat" ]; then
>>> +rootpartno=2
>>> +bootfstypeno=83
>> 
>> 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.

>>> +if [ "vfat" = "$SD_PART1_FS" ]; then
>> 
>> Semantically, this test (and some following ones) order is wrong.
>
> I did not know how to change a patch afterwards. I wished you would
> decide over that functionality by looking at the latest version. I had
> added some logics to allow the swap partition to be the last partition
> of the device.

The problem here is the workflow when you submit patches: if you submit
single-issue patches, it is easier to submit a new version afterwards.

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

  $ git reset $COMMIT_BEFORE_YOUR_PATCH
  [do your corrections]
  $ git commit
  $ git format-patch
  $ git send-email

>>> +	if fdisk $SD_DEVICE < /tmp/argsToFdisk$$; then
>>> +		echo "Partitioning was successful."
>>> +		#rm /tmp/argsToFdisk$$
>>> +	else
>>> +		echo "Partitioning failed, could not execute with fdisk:"
>>> +		cat /tmp/argsToFdisk$$
>>> +		exit -1
>>> +	fi
>> 
>> I am not sure if this is clearer: I would prefer the previous way of
>> partitioning, because it is easier to repeat manually (you just
>> follow the order the commands are given).
>
> If something went wrong, then cat `ls -lt /tmp/argsToFdisk*|head -1`
> will print the commands sent to fdisk.

While I agree on this, IMHO it renders the install.sh script harder to
read, because different conditions are mixed together.

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/f3c26585/attachment.pgp