Re: [PATCH] mount-boot.eclass: do not create /boot/.keep in pkg_prerm

Ionen Wolkens <[email protected]> Thu, 18 Jun 2026 12:45:28 -0400

Newsgroups	gmane.linux.gentoo.devel
Message-ID	<ajQgqG2Gmo6k_rYi@eversor>

On Thu, Jun 18, 2026 at 04:40:48PM +0000, Alfred Wingate wrote:
> On Thursday, June 18th, 2026 at 7:33 PM, Ionen Wolkens <[email protected]> wrote:
> 
> > On Thu, Jun 18, 2026 at 06:03:40PM +0200, Ulrich Müller wrote:
> > > >>>>> On Thu, 18 Jun 2026, Mike Gilbert wrote:
> > > 
> > > >> > +     if [[ -n ${BOOT_EXISTS} && ! -d ${EROOT}/boot ]]; then
> > > >> > +             # Recreate /boot in case it got un-merged
> > > >> > +             mkdir "${EROOT}"/boot
> > > >> >       fi
> > > >> 
> > > >> That looks like a horrible hack.
> > > 
> > > > What's so horrible about it? It accomplishes the same goal without
> > > > leaving an orphaned file behind. If it will cause problems, please
> > > > elaborate.
> > > 
> > > Sorry, probably I am missing something here. What is the exact scenario
> > > where an unmerge can remove the /boot directory, so that it must be
> > > recreated?
> > 
> > Now that you mention it, do we have anything that installs *tracked*
> > files in /boot? As-in done in src_install rather than pkg_*
> 
> sys-boot/raspberrypi-firmware and sys-kernel/raspberrypi-image came immediately to mind. Looking for "insinto /boot" in the tree found sys-boot/aboot, sys-boot/cromwell, sys-apps/memtest86+[boot], sys-apps/memtest86-bin, sys-kernel/linux-firmware[initramfs,-dist-kernel] and sys-power/nvram-reboot as well.

Had just done another mail saying: (not really a question, given if
any packages did it'd be very broken with the whole mount business)

And well, I'm horrified to learn that we do have packages doing this
without mount-boot.

If anything i feel that it should be a banned location for installing
files at this point... Of course, I refer only to tracked files,
anything done in pkg_postinst with proper checks is fair game.
-- 
ionen

signature.asc (application/pgp-signature, 525 B)