On 2017-12-14 19:04, Alexander Kanavin wrote:
> On 12/14/2017 07:49 PM, Alexander Kanavin wrote:
>> On 12/14/2017 07:40 PM, Stefan Agner wrote:
>>
>>> Oh, I see, well that simplifies it, doesn't it? E.g.
>>>
>>> # If package managers support postinsts and the package manager is
>>> present on
On 12/14/2017 07:49 PM, Alexander Kanavin wrote:
On 12/14/2017 07:40 PM, Stefan Agner wrote:
Oh, I see, well that simplifies it, doesn't it? E.g.
# If package managers support postinsts and the package manager is
present on the
# rootfs, then it will handle postinsts just fine, no
On 12/14/2017 07:40 PM, Stefan Agner wrote:
Oh, I see, well that simplifies it, doesn't it? E.g.
# If package managers support postinsts and the package manager is
present on the
# rootfs, then it will handle postinsts just fine, no need to deploy
scripts again.
if
On 2017-12-14 18:28, Alexander Kanavin wrote:
> On 12/14/2017 07:16 PM, Stefan Agner wrote:
>
>> Are you sure that rpm has no such facility? Maybe there is some other
>> mechanism around...
>
> You are welcome to find it. rpm does not distinguish between unpacking
> and configuring steps, and
On 12/14/2017 07:16 PM, Stefan Agner wrote:
Are you sure that rpm has no such facility? Maybe there is some other
mechanism around...
You are welcome to find it. rpm does not distinguish between unpacking
and configuring steps, and just does everything in a single installation
step.
If
On 2017-12-14 17:59, Alexander Kanavin wrote:
> On 12/14/2017 06:46 PM, Stefan Agner wrote:
>
>> Suggestion:
>> - Still remove systemd opkg service as proposed, since run-postinsts
>> gets run with systemd and should/will handle package manager just fine
>
> Yes.
>
>> - Change run-postinsts to
On 12/14/2017 06:46 PM, Stefan Agner wrote:
Suggestion:
- Still remove systemd opkg service as proposed, since run-postinsts
gets run with systemd and should/will handle package manager just fine
Yes.
- Change run-postinsts to behave sane: Detect package management by
checking
On 2017-12-14 16:14, Alexander Kanavin wrote:
> On 12/14/2017 04:57 PM, Stefan Agner wrote:
>> On 2017-12-14 15:55, Alexander Kanavin wrote:
>>> On 12/14/2017 04:41 PM, Stefan Agner wrote:
>>>
I think removing the Opkg first boot systemd service (as the initial
patch does) is the correct
On 12/14/2017 04:57 PM, Stefan Agner wrote:
On 2017-12-14 15:55, Alexander Kanavin wrote:
On 12/14/2017 04:41 PM, Stefan Agner wrote:
I think removing the Opkg first boot systemd service (as the initial
patch does) is the correct first step.
However, it currently still leads to a second copy
On 2017-12-14 15:55, Alexander Kanavin wrote:
> On 12/14/2017 04:41 PM, Stefan Agner wrote:
>
>> I think removing the Opkg first boot systemd service (as the initial
>> patch does) is the correct first step.
>>
>> However, it currently still leads to a second copy of the postinst
>> scripts in
On 12/14/2017 04:41 PM, Stefan Agner wrote:
I think removing the Opkg first boot systemd service (as the initial
patch does) is the correct first step.
However, it currently still leads to a second copy of the postinst
scripts in /etc if package management is enabled.
I am pretty sure that
On 2017-12-14 15:24, Alexander Kanavin wrote:
> On 12/14/2017 03:59 PM, Stefan Agner wrote:
>
>> That at least contradicts my testing with opkg/ipk.
>>
>> If /etc/ipk-postinsts is not there and /var/lib/opkg/status is there
>> (package management installed), then run-postinst runs "opkg
On 12/14/2017 03:59 PM, Stefan Agner wrote:
That at least contradicts my testing with opkg/ipk.
If /etc/ipk-postinsts is not there and /var/lib/opkg/status is there
(package management installed), then run-postinst runs "opkg configure",
which takes care of postinsts just fine.
Reading the
On 2017-12-14 14:52, Alexander Kanavin wrote:
> On 12/14/2017 03:11 PM, Stefan Agner wrote:
>>
>>> I don't think this is correct. Some postinsts are intentionally
>>> deferred to first boot, and they need to be run regardless of whether
>>> the image supports runtime package management or not.
>>
On 12/14/2017 03:11 PM, Stefan Agner wrote:
I don't think this is correct. Some postinsts are intentionally
deferred to first boot, and they need to be run regardless of whether
the image supports runtime package management or not.
Yes I know, the mentioned opkg-keyrings is such a case.
If
On 2017-12-14 14:10, Alexander Kanavin wrote:
> On 12/13/2017 08:29 PM, Stefan Agner wrote:
>
>> Maybe it needs something like this?
>>
>>
>> runtime_pkgmanage = bb.utils.contains("IMAGE_FEATURES",
>> "package-management",
>>True, False,
On 12/13/2017 08:29 PM, Stefan Agner wrote:
Maybe it needs something like this?
runtime_pkgmanage = bb.utils.contains("IMAGE_FEATURES",
"package-management",
True, False, self.d)
if delayed_postinsts and not runtime_pkgmanage:
On 2017-12-13 19:06, Stefan Agner wrote:
> From: Stefan Agner
>
> OpenEmbedded has a built-in mechanism to run postinst scripts offline
> at build time or, if necessary, on first boot (delayed execution). If
> the latter is the case and systemd is in use, two services
18 matches
Mail list logo