Hi, On Sun, Jul 10, 2011 at 01:43:03PM +0200, Geert Stappers wrote: > Here some patches for "polystrap". > > My main message is that I do like the program that builds (and > finishes) a foreign root file system.
I'm glad you like it. But for the sake of you not putting effort in things that should be discussed first, wouldnt it make sense to discuss them first? > If there is already rename of the program done, then let me rework > these patches for the new name. Until there is no name around that is considered as better fitting by everybody: no rename. > The twelve patches elaborated: > > 0001-No-new-symlinks-for-new-board.patch > 0002-Dereference-symbolic-links-in-om-gta02-directory.patch > 0003-Dereference-symbolic-links-in-kirkwood-directory.patch > > No symbolic links in the "source directories" Why are copies of files better than symlinks where you rather never want a different content than the default one or no file at all? Using symlinks instead of real files not only shows where the file comes from but also allows to only change one copy (the target of the symlink) to fix a bug in all platforms/boards. Please elaborate on your reasoning. > 0004-new-file-Makefile.patch > > Mainly for `sudo make install`, to have what `dpkg --install ...deb` do Why is a Makefile useful? This software does only make sense on debian systems anyway, so why would it make sense to have a Makefile for installation instead of just using debian/rules (look in the debian branch) to build and install a debian package? Wouldnt a Makefile not just be useless overhead cluttering the root directory? You also reference a file called 'polystrap-binfmt'. This file doesnt exist in my git. I presume it is the script for filling the /etc/qemu-binfmt/foo directories? Besides the fact that I think that supplying a multistrap config is enough for this task, I think that using /etc/qemu-binfmt/arch is connected with too many issues to be useful. See this mail: http://lists.debian.org/debian-embedded/2011/06/msg00104.html > 0005-renamed-polystrap.sh-polystrap.patch > > mv polystrap.sh polystrap I agree that, when it is in /usr/bin, it is not supposed to have the .sh extension. > 0006-s-PLATFORM-BOARD-g.patch > > sed -i 's/PLATFORM/BOARD/g' * A good idea. It's a better name and I was unsure about platform myself for the same reason you gave. > 0007-renamed-newtarget.sh-polystrap-nb.patch > > mv newtarget.sh polystrap-nb good. > 0008-polystrap-nb-s-target-board.patch > > s/target/board/ as above. > 0009-polystrap-is-being-installed.patch > > Copy new board files from absolete path Shouldnt this default to the current directory or accept a commandline switch to specify the directory to copy the board files from? Otherwise the script is not useful when developing in the source directory as it will not copy from there but from /usr/share instead. > 0010-polystrap-binfmt-a-reminder.patch > > A reminder True. I not only consider it obsolete, but just a dirty workaround for a problem that can more easily be fixed by fixing #632192 or another way I didnt think of yet. > 0011-manual-pages.patch > > Manual pages A manual page is a good idea, should it ever become a debian package - but why asciidoc? Also, wouldnt it make more sense to put the manpage in the ./debian directory instead? Wouldnt it also make more sense to only write the documentation for a new user once the current problems are fixed? Look at the current problems here: http://lists.debian.org/debian-embedded/2011/07/msg00014.html and here http://lists.debian.org/debian-embedded/2011/07/msg00017.html > 0012-git-ignore-the-output-of-make-dist.patch > > Git ignore the output of `make dist` I dont like the Makefiles - see above. Sorry for the late reply but real life was calling :) cheers, josch -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/20110715030155.GA30923@hoothoot
