[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#468201: Unhelpful error message in lh_config

On Wed, Feb 27, 2008 at 1:06 PM, Daniel Baumann <daniel at debian.org> wrote:
> tags 468201 +pending
>  thanks
>  Will Murnane wrote:
>  > When I invoke lh_config with an invalid option, all it says is
>  > 'internal error'.  Changing line 635 as follows helps:
>  > Echo_error "Invalid option $0"
>  thanks, fixed in git.
Cool.  Is there a simple way I can get bleeding-edge live-helper
packages through apt: i.e., some repo with the latest git version?  I
build debian live quite often, on the order of twice a week, but it's
never particularly important that it build correctly.  Thus, I think
I'd be a good person to help test a "real-world" build process.

>  > Also, it appears the --mirror-bootstrap-security option is no longer
>  > valid, which is how I discovered this problem.
>  --mirror-bootstrap-* got renamed to --mirror-chroot-*; and the 'new'
>  --mirror-bootstrap only designates the mirror to (c)debootstrap from.
This doesn't appear to work:
lh_config -b usb-hdd --mirror-chroot --mirror-chroot-security ...
lh_config: unrecognized option `--mirror-chroot'
lh_config: unrecognized option `--mirror-chroot-security'
It looks like all that needs to change is the argument to getopt; it
doesn't have any mirror-chroot options set (line 116).  I'll test in a
minute: yep, inserting the string
":,mirror-chroot:,mirror-chroot-security" does let at least the
configuration part run; I haven't built a whole image yet, though it
looks like it's going well.

Hypothetically, would you be averse to converting the lh_build scripts
to Perl?  It would make this kind of internal consistency easier to
maintain.  Rather than specify in several places the name of the
option, what variable it's tied to, and what its help output is, one
could create a single hash containing the data for all those items and
iterate over it in different ways.  It might be possible to do this in
shell scripts, but Perl makes such things relatively easy to express.
This could also lead to easier unit testing in the future: include a
test function in the hash that checks for functionality.  I don't have
time to maintain such a port, but I think I could at least get a
working prototype together.  This could be a slow migration; Perl will
deal with environment variables just fine, and not all the code needs
to be rewritten at once.  If you have a counter-suggestion how I could
help, please let me know.  This project has been very helpful to me
and I'd like to give back if I can.


Reply to: