Bthis is getting very busy 
Bso threading
BHere's an example of where we do it in
https://github.com/ublue-os/config/blob/70634bf0d9fa9d506052cc764de45d0eac59d3c0/files/usr/lib/systemd/system-preset/10-flatpak-system-update.preset
config repohttps://github.com/ublue-os/config/blob/70634bf0d9fa9d506052cc764de45d0eac59d3c0/files/usr/lib/systemd/system-preset/10-flatpak-system-update.preset
GitHub
A layer to provide configuration files (udev rules, service units, etc) - ublue-os/config
Balright
Bthis solution requires adding 2 new files... one for bluefin and one for bluefin-dx>>>
or... one per service, depending on how you want to think about it
or... one per service, depending on how you want to think about it
Bso instead enabling it in the RUN command, i add a file that it enables it via that file. and that triggers automaticly?
Bright, the presets are how systemd assumes the default (preset) state of a service... enabled or not
Baah I see
Bcan i do unmask in there also
Bi see we do unmask and then enable of the service
Bi don't know if the unmask is needed in the preset... i think it's there only because when adding that new file in container it needed it to execute enable in the contianer runtime, but the preset just enabling should be enough
Balright. lets do this and see how this works out 
Bthanks for helping me
Bhey! thanks for wanting to contribute!
If I didn't want to help, I shouldn't have commented
(and made things confusing) LOL
If I didn't want to help, I shouldn't have commented
(and made things confusing) LOLBok lets see where goes from here
Badded a summary of the situation here: https://github.com/ublue-os/bluefin/pull/441#issuecomment-1694795519
GitHub
Fixes #428
Follow up of PR #434
This moves the current /etc/ folders to their corresponding /usr/etc folder.
Follow up of PR #434
This moves the current /etc/ folders to their corresponding /usr/etc folder.
Bminor nitpick, since you'll probalby need to do another preset for framework...
with these ... the number in the filename matters
with these ... the number in the filename matters
Bits when they are execute in which order?
Byou want this override to come later... so i'd probably make them
95-dconf-update.preset and 95-fprintd.presetBif you look at your own running system
ls /usr/lib/systemd/system-preset you'll probably see what i meanB90-default.presethas a lot of stuff in itB99-default-disable.preset is the last one to run, and it disables anything which wasn't already enabled by presetBnot sure if it's critical, but it seems like "good practice"
Bi see
Bah, and looks like it's a preset is NOT actually needed for frpint.d
Bbecause the
fprintd.service file added is an override of the pre-installed serviceBalright well that is good news
Byep
Bnow only rename it to 95 then
Bif all is green
BBit's looking good
BI probably should PR a fix to that
fprintd.service the better way to override a service is with an overrideBbut, i'm not going to sweat it too much, it certainly does the job
Bsorry, should I still add one for fprintd.serivce?
Band in this specific use case, i can see it making sense
Bits in the middle of the night here. i'm trying my best to follow everything
Bno, you should need a preset for fpintd ... i'll update my comment on Github PR, too
Bhow do call that number change, change of level?
Bpriority?
Bi'd just say "rename"
Bi don't know what to call it for sure either
Boke haha don't overthink it
Balright
Blooks good
Bnice
Bwould be nice to get this one finally fixed up
Bnow... who uses Bluefin and will test it? ;-D
who uses Bluefin and will test it? ;-DBi do
Bofcourse
