[Fedora-music-list] Spin Approval

[Brendan Jones]

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>