Hello again, Luca Capello wrote:
> 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). Apparently I perceive the world as less buggy/evil here. For a start, a larger boot partition is a safe bet, IMO. It doet not cost us much to allow for that. > [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. 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. > > 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. Good plan! >>> 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. Started it. >>>> # 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. 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. >>>> +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 Many thanks! Should I better follow Joachim's suggestion to find a publicly accessible location of my git repository? Every change would then become a branch, and you diff against or between these branches, right? 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. Maybe a second file, install-dev.sh, would be a good target? Or the current one becomes install-stable.sh? >>>> + 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. There seems to be a bug with busybox since "head -1" does not seem to work there. > 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 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). Many greetings Steffen _______________________________________________ pkg-fso-maint mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-fso-maint
