On Mon, Feb 28, 2011 at 12:57, Marko Saukko <[email protected]> wrote:
> On 02/28/2011 12:25 PM, Kalle Lampila wrote:
>>
>> On Mon, Feb 28, 2011 at 08:49, Marko Saukko<[email protected]>
>>  wrote:
>>>
>>> On 02/25/2011 08:13 PM, Kalle Lampila wrote:
>>>>
>>>> On Fri, Feb 18, 2011 at 17:48, Clark, Joel<[email protected]>
>>>>  wrote:
>>>>>
>>>>> Regardless of the architecture diagram, resource policy should not be
>>>>> included until it does not break other common core components.
>>>>
>>>> I have request add requirement to make sure that there is configs when
>>>> pulseaudio-policy-enforcement is installed.
>>>>
>>>> regards
>>>> Kalle
>>>
>>> I'm a bit against this "Require: policy-settings" line in the spec. My
>>> reasoning:
>>>
>>> - With this line we require every vertical and every adaptation to have
>>> package that provides policy-settings already in the very beginning of
>>> the
>>> project. This will make the adaptation harder and will cause the need for
>>> people of making empty policy-settings-adaptation-x-dummy packages that
>>> do
>>> not actually provide any files. This is pretty much the same as not
>>> having
>>> the requirement in the first place.
>>
>> If there is not working config for pulseaudio-policy-enforcement it is
>> not usefully. If we have not configure then it is best not include
>> pulseaudio-policy-enforcement at all.
>>
>> With requirement we notice missing configure error image building time
>> not running time. And it is good notice error in earlier than later.
>>
>
> Well there are many things that are not useful to specific platforms in
> specific images, but those are there because they are part of the compliance
> specification.
>
> So the question is that if the  pulseaudio-policy-enfocement is part of the
> MeeGo Compliance it needs to be included to every image AFAIK. However, it
> should be noted that all the adaptation might not have policies, in theory
> there could be a device without audiohardware, but pulse would still be
> there because of compliance requirements. So, if user would plug an usb
> audio adapter he would get audio out.

Here question is that does compliance requirement mean that some
package is there or  that it is really working. I think that idea is
that package is really usefully and can use.

Of course there is that special case without audio hardware. That case
hole pulseaudio is useless include pulseaudio-policy-enfocement. That
case you need offer no audio device policy-settings. Currently I have
not heard any MeeGo device without audio hardware, they are not really
in MeeGo targets. If we see invasion of MeeGo devices without audio
harware, probably pulseaudio requirement in compliance is made depend
the existence of audio hardware.

>>> - Also after adding multiple packages that provides the same thing and
>>> having this as a part of "Require:" field, requires that when user
>>> installs
>>> the pulseaudio-policy-enforcement he need also say which one of the
>>> policy-settings packages he wants to install. Because none of the tools
>>> can't make the decision between provides packages automatically, we need
>>> to
>>> have the policy-settings-[adaptation|vertical] package in the package
>>> group
>>> or the kickstart anyway to get the image build. So yet again the forcing
>>> of
>>> the settings does not do much good.
>>
>> We have many kernel packages and none of the tools can't make the
>> decision which is right one, in image creation we must tell what
>> kernel he want use. This is standard situation in platform specific
>> packages.
>>
>
> Yes, but none of the packages have "Requires: kernel" and all kernel
> dependencies are done in .ks level like kernel-adaptation-n900 or
> kernel-adaptation-medfield. As you said this is standard situation with
> platform specific packages what kernel to use. So, why do "Require:" field
> for this package and leave the rest for .ks and package groups? If the
> pulseaudio-settings-x package is missing then it is cause by the fact that
> there is error in either package group or .ks file, right?

Maybe because it is very easy to detect missing kernel and chroot
environment the kernel api is provided outside of image.

Pulseaudio-policy-enfocement requires policy-settings to working. So
it should be there and that is way how to prevent install
pulseaudo-policy.enforcement in system where there is not
policy-settings.

And because there no ofter way detect what policy-settings is wanted
you need told that in .ks or package group.

>>> - Also there is a case that when there is only one policy-settings
>>> packages
>>> it will be installed automatically even if the settings are not meant for
>>> the specific platform (settings are noarch packages anyway right?).
>>> However,
>>> this condition will not most probably stay there long.
>>
>> There is currently many policy-settings packages and probably in
>> future too. If some point settings are reduced to one that probably is
>> suitable all platform. So I don't see any point of that comment.
>>
>
> Ah, it seems that the current policy packages are actually published in both
> archs (ia32 and arm). So this is already multiple choices.
>
>>> - Lastly if the settings are missing it really should not crash the
>>> system
>>> but instead disable the policies or inform user gracefully in my opinion.
>>
>> I my understood there is not crash problem. If config is missing there
>> is nice error message and clean exit. Please post crash report if you
>> have detect some crash.
>>
>
> Ok, my misunderstanding I got impression that things crash if there wasn't
> proper configs. So does pulseaudio start at all if there aren't any
> configurations? And is this error messages such that it is easy to find,
> when system is booted not only when the binary is started manually?

That config missing that kind of fatal error that you cannot really
recover. That is logged like any ofter pulseaudio errors.

> Ps. this situation is similar to the udev requiring udev-rules package
> http://lists.meego.com/pipermail/meego-commits/2010-July/001281.html

There you can read that requirement was removed because "some of the
platforms may not need any udev-rules". With
pulseaudio-policy-enforcement situation is totally different because
policy-settings is mandatory.

- Kalle
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging

Reply via email to