other packages should use /etc/initramfs-tools

[Onnie Winebarger]

Other packages that install pieces into the initial ram disk put their hooks and scripts into /usr/share/initramfs-tools instead of /etc/initramfs-tools. This makes them less intuitive to locate, modify, or enable/disable. This probably applies to some of the core configuration scripts installed by initramfs-tools

/usr/share/initramfs-tools/scripts/panic/keymap
/usr/share/initramfs-tools/scripts/local-premount/resume
/usr/share/initramfs-tools/scripts/init-top/framebuffer
/usr/share/initramfs-tools/scripts/init-top/all_generic_ide
/usr/share/initramfs-tools/scripts/init-top/blacklist
/usr/share/initramfs-tools/scripts/init-top/keymap
/usr/share/initramfs-tools/hooks/framebuffer
/usr/share/initramfs-tools/hooks/compcache
/usr/share/initramfs-tools/hooks/thermal

Also, /usr/share is supposed to be restricted to "architecture independent read-only data files": /usr/lib may be a more appropriate home for the other core scripts.

[ceg (ceg)]

Isn't /etc increasingly reserved for admin system config (overrides) while distro maintained packages install configuration defaults into /usr/lib, keeping distro/local stuff out of each others way?

[Onnie Winebarger (owinebar)]

I'm new to Ubuntu, so I don't know. I do think that (a) there is a strong
analogy between the nature of the initramfs scripts and the rc/upstart
scripts, and (b) it's not clear that the scripts being installed in /usr/lib
(or /usr/share) are actually overridable defaults - for example, I'm
pretty sure the crypto tools overrule the local specification to force
the use of busybox. The other issue is that packages other than
initramfs-tools are installing into the /usr/share/initramfs-tools
directory, so that a casual user may not even realize that these
non-overridable scripts are getting installed there. Without
more user-friendly methods of turning them "on and off" (such as
you have with the rc system), I would follow the principle of least
surprise to the adminstrator. I don't believe the documentation
mentions the /usr/share/initramfs-tools hierarchy at all, just
the /etc/initramfs-tools, so discovering this set of scripts can
be surprising. It would be different if it were only the initramfs-tools
putting infrastructure there, since that can be viewed as
an implementation detail of initramfs-tools and also viewed
with dpkg -L initramfs-tools.

On Thu, Apr 15, 2010 at 1:26 PM, ceg <email address hidden> wrote:
> Isn't /etc increasingly reserved for admin system config (overrides)
> while distro maintained packages install configuration defaults into
> /usr/lib, keeping distro/local stuff out of each others way?
>
> --
> other packages should use /etc/initramfs-tools
> https://bugs.launchpad.net/bugs/558491
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in tools for generating an initramfs: New
>
> Bug description:
> Other packages that install pieces into the initial ram disk put their hooks and scripts into /usr/share/initramfs-tools instead of /etc/initramfs-tools.  This makes them less intuitive to locate, modify, or enable/disable.  This probably applies to some of the core configuration scripts installed by initramfs-tools
>
> /usr/share/initramfs-tools/scripts/panic/keymap
> /usr/share/initramfs-tools/scripts/local-premount/resume
> /usr/share/initramfs-tools/scripts/init-top/framebuffer
> /usr/share/initramfs-tools/scripts/init-top/all_generic_ide
> /usr/share/initramfs-tools/scripts/init-top/blacklist
> /usr/share/initramfs-tools/scripts/init-top/keymap
> /usr/share/initramfs-tools/hooks/framebuffer
> /usr/share/initramfs-tools/hooks/compcache
> /usr/share/initramfs-tools/hooks/thermal
>
> Also, /usr/share is supposed to be restricted to "architecture independent read-only data files": /usr/lib may be a more appropriate home for the other core scripts.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/initramfs-tools/+bug/558491/+subscribe
>

[ceg (ceg)]

Hm, I don't know the intention, just saw /usr/lib/pm-utils being used in a similiar way.

I would actually like to see a common theme for distro specific/managed (/usr/lib/etc?), site specific (/usr/share/etc?), host specific (/etc) and user specific (~/.etc or ~/.config/etc) config locations.