Ignore environment variable stored in binary package

[bell]

I maintain overlay for custom device ebuilds and run a binhost for them. Some of ebuilds should be able for optional to update files to (boot)-SD-Card.
Any user is able to mount the device to any place. My idea was: If the user set

[Genone]

Not a direct answer, but wouldn't it be possible to specify a fixed location instead and use symlinks to redirect that to the actual target destination? Then you could also just install these files normally without having to play around with pkg_preinst, and have uninstall support (if desirable). Would be a bit more work if the target location changes regularly, but nothing that couldn't be automated.

[bell]

I cannot specify and force any specific location.
The partition is like EFI partition, a vfat partition for bootloader files. Or maybe the better comparison is to the raspberry first sdcard partition. The ebuilds should update the bootloader files (bl31.bin, bl33.bin and more) in a bootloader subfolder.
The difference is, the fvat partition contain all user files from vendor OS, so user should be able to access the partition as usual.

Some users mount the partition to /boot - But I do not like to have the linux kernel in the / of this partition, visible for user.
I prefer the /media/sdcard and install the kernel into /boot on the system (ext4) partition. The used bootloader (u-boot) is able to read the kernel from ext4

My hacky solution is

[Genone]

I think you misunderstood me. It is clear that the actual storage location can't be fixed.
The idea was that instead of using an environment variable to determine it you use a known symlink. So say the user mounts the sd card under /media/sdcard, you create a symlink like /mnt/portage-sdcard-target -> /media/sdcard. The ebuild then installs all files that should go to the sdcard into /mnt/portage-sdcard-target instead of resolving SDCARD_MOUNT_POINT. When the user unmounts the sdcard the symlink is removed again. So the built packages will always have the files that will go to the sdcard in the same location, but due to the symlink they will actually be stored on the sdcard mountpoint.
That way you don't need any special hacks, only logic to create/remove the symlink properly when the sdcard is mounted (which isn't much more complex than setting an environment variable). Only downsides that I can see atm is that you can't specify this per process, so it wouldn't support installing packages to different mountpoints at the same time. But quite possible I'm missing something here. On the Upside you'd get proper uninstall support and could easily check which packages have stuff installed on sdcards even if the mountpoint was changed in between installations.

Working around explicit portage restrictions is usually a bad idea as it will most likely bite you at a later point.

[bell]

The main idea is to provide the files trough binary packages, but decide on the client if the files should be installed into mounted vfat partition or not.

The files are installed into /usr/share/sdcard1, then optional in addition in pkg_preinst into the mounted partition.

Of course the way, using symlink is valid. Fully remove the sdcard-mount eclass and just to propose to set the symlink at /usr/share/sdcard1.
The hacky part this way is to handle the broken symlink if the partition is not mounted.

The second difference is, I recommend to set CONFIG_PROTECT="$SDCARD_MOUNT_POINT", and keep /usr/share/sdcard1 unprotected to keep the upstream configuration files.

Currently the hacky solution with manually parsing the make.conf does work for me. I estimate the number of users is in the single digits range, so I keep it as is, till anyone run into any issue.