Re: [PATCH 00/12] root file system for non native boards
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
Reply to: