On 12/04/2012 01:46 PM, Christoph Wickert wrote:
Am Dienstag, den 04.12.2012, 08:29 +0100 schrieb Brendan Jones:
On 12/02/2012 10:11 PM, Christoph Wickert wrote:
I see your point, but the modifications
to /usr/share/firstboot/modules/create_user.py are a no-go. You need to
move the sed commands to the livesys init script, so the changes will
only be applied to the live system but not to the installed packages.
Even this is controversial (think of translations), but again as long as
it not explicitly forbidden, I'll turn a blind eye to it.
Is there a right way to do this?
Hi Brendan,
I'm afraid there is no really right way unless it gets configurable in
firstboot.
I tried to find one but I couldn't see
an option in kickstart to make this happen. I could probably provide a
patch to firstboot (I think this would be really useful) but obviously
it will be too late for this release.
It's definitely too late for this release and I doubt such a patch would
be accepted as it has no use case outside this spin.
Fair enough
Or is this something which should
go into pam or somewhere else?
How would you do this in pam?
Alternatively we could add this to %post in jack-audio-connection-kit
but I'm not sure if this is considered safe in a critical-path package
It is not considered safe in *any* package. You must not own or modify
files that are owned by another package (unless of course your package
is a configuration utility and the file in question is a config file)
and if you absolutely have to, you have to do it in the inscript so that
the changes only apply to the live system but don't end up on the
installed system.
I meant creating the group in %post (not editing a file owned by
firstboot). But the problem of assigning group membership still remains.
Alternatively, we could package something which gets kicked off via
xdg/autostart that could detect this and request sudo priveledges to add
the X user to the group. All really messy and too late now.
There is a package realTimeConfigQuickScan which potentially could be
kicked off at start, but having it persist post first log in is really
annoying.
So yes, we have two problems to solve here the liveuser and the
installed user. liveuser is OK - the installed user is not. How do other
packages handle this? How can a package know to give a particular user
group membership? I can't see a way out of this without user intervention.
For F19 I will submit the firtboot patch based on the config file and
see if I can make a good case for it.
If we do make changes to packages to fix these issues (not specifically
this issue), how can we ensure that the updates are part of the final
buildroot (and not only in updates)
<snip>
_______________________________________________
music mailing list
music@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/music
