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

Re: symlinks in /boot vs. symlinks in /



On Fri, Jun 18, 2004 at 10:43:00PM +0200, martin f krafft wrote:
> Why does Debian drop symlinks to vmlinuz and initrd.gz into the root
> directory? The FHS does allow it (after all), but it's butt-ugly, if
> you ask me.
> 
> Can we please use the upcoming release to clean this issue up?

How about we futz with this sort of thing near the beginning of a
release cycle, not near the end? This change requires:

  * co-ordination of a number of packages

  * communication with maintainer scripts generated by kernel-package,
    which is complex enough that expecting bugs when using it in
    non-default mode is not unreasonable

  * explicit action by every port maintainer to make sure their
    bootloaders do something sensible and change the corresponding
    bootloader installers

For some ports, this change is required; for others, it's largely
cosmetic. The ports where it's required have probably already done the
work, or we wouldn't be seeing success reports on them.

I made the change from / to /boot for powerpc a while back; it did take
a number of days to co-ordinate everything carefully so that nothing
would break in the interim period, and I wouldn't have dreamed of doing
it for a port I couldn't personally test. I don't think it's appropriate
to require everybody to change this at this late date in d-i's first
release cycle.

At this point, we need to be concentrating on things which are broken
and require stabilization, not things which work and are merely
subjectively "butt-ugly, if you ask me".

>   - change the template default in rootskel.
>   - change the bootloaders to look for /boot/vmlinuz instead of
>     /vmlinuz.

Changing the bootloader installers in d-i now to accept symlinks either
in / or in /boot (i.e. to be strictly more tolerant) would make some
sense; but it should be at the discretion of the port maintainers, must
be well-tested with both rootskel defaults, and we should not consider
this a release blocker in any way.

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]



Reply to: