public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-portage-dev] In what phase are file "merged"?
@ 2021-06-22 23:11 Joakim Tjernlund
  2021-06-23  6:47 ` Ulrich Mueller
  0 siblings, 1 reply; 8+ messages in thread
From: Joakim Tjernlund @ 2021-06-22 23:11 UTC (permalink / raw
  To: gentoo-portage-dev@lists.gentoo.org

In PMS 9.2 is says:
The call order for upgrading, downgrading or reinstalling a package is:

    pkg_pretend (only for EAPIs listed in table 9.2), which is called outside of the normal call order process.
    pkg_setup
    src_unpack
    src_prepare (only for EAPIs listed in table 9.3)
    src_configure (only for EAPIs listed in table 9.4)
    src_compile
    src_test (except if RESTRICT=test)
    src_install
    pkg_preinst
    pkg_prerm for the package being replaced
    pkg_postrm for the package being replaced
    pkg_postinst


It does not say where in this list new files merged and old files unmerged, can anyone enlighten me?

 Jocke

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-portage-dev] In what phase are file "merged"?
  2021-06-22 23:11 [gentoo-portage-dev] In what phase are file "merged"? Joakim Tjernlund
@ 2021-06-23  6:47 ` Ulrich Mueller
  2021-06-23  7:08   ` Fabian Groffen
  0 siblings, 1 reply; 8+ messages in thread
From: Ulrich Mueller @ 2021-06-23  6:47 UTC (permalink / raw
  To: Joakim Tjernlund; +Cc: gentoo-portage-dev@lists.gentoo.org

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

>>>>> On Wed, 23 Jun 2021, Joakim Tjernlund wrote:

> In PMS 9.2 is says:
> The call order for upgrading, downgrading or reinstalling a package is:

>     pkg_pretend (only for EAPIs listed in table 9.2), which is called outside of the normal call order process.
>     pkg_setup
>     src_unpack
>     src_prepare (only for EAPIs listed in table 9.3)
>     src_configure (only for EAPIs listed in table 9.4)
>     src_compile
>     src_test (except if RESTRICT=test)
>     src_install
>     pkg_preinst
>     pkg_prerm for the package being replaced
>     pkg_postrm for the package being replaced
>     pkg_postinst

> It does not say where in this list new files merged and old files
> unmerged, can anyone enlighten me?

It's somewhat hidden, but it's there:
https://projects.gentoo.org/pms/8/pms.html#x1-950009.1.10

   9.1.10 pkg_preinst
   ... immediately before merging the package to the live filesystem. ...

   9.1.11 pkg_postinst
   ... immediately after merging the package to the live filesystem. ...

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-portage-dev] In what phase are file "merged"?
  2021-06-23  6:47 ` Ulrich Mueller
@ 2021-06-23  7:08   ` Fabian Groffen
  2021-06-23 10:40     ` Ulrich Mueller
  0 siblings, 1 reply; 8+ messages in thread
From: Fabian Groffen @ 2021-06-23  7:08 UTC (permalink / raw
  To: gentoo-portage-dev; +Cc: Joakim Tjernlund

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

On 23-06-2021 08:47:58 +0200, Ulrich Mueller wrote:
> >>>>> On Wed, 23 Jun 2021, Joakim Tjernlund wrote:
> 
> > In PMS 9.2 is says:
> > The call order for upgrading, downgrading or reinstalling a package is:
> 
> >     pkg_pretend (only for EAPIs listed in table 9.2), which is called outside of the normal call order process.
> >     pkg_setup
> >     src_unpack
> >     src_prepare (only for EAPIs listed in table 9.3)
> >     src_configure (only for EAPIs listed in table 9.4)
> >     src_compile
> >     src_test (except if RESTRICT=test)
> >     src_install
> >     pkg_preinst
> >     pkg_prerm for the package being replaced
> >     pkg_postrm for the package being replaced
> >     pkg_postinst
> 
> > It does not say where in this list new files merged and old files
> > unmerged, can anyone enlighten me?
> 
> It's somewhat hidden, but it's there:
> https://projects.gentoo.org/pms/8/pms.html#x1-950009.1.10
> 
>    9.1.10 pkg_preinst
>    ... immediately before merging the package to the live filesystem. ...
> 
>    9.1.11 pkg_postinst
>    ... immediately after merging the package to the live filesystem. ...

Aha, so does this mean pkg_prerm and pkg_postrm are run with replacing
package in place, e.g. if they refer to scripts installed by the
replaced package they may no longer exist or be the same?

Thanks,
Fabian


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-portage-dev] In what phase are file "merged"?
  2021-06-23  7:08   ` Fabian Groffen
@ 2021-06-23 10:40     ` Ulrich Mueller
  2021-06-23 11:33       ` Michał Górny
  0 siblings, 1 reply; 8+ messages in thread
From: Ulrich Mueller @ 2021-06-23 10:40 UTC (permalink / raw
  To: Fabian Groffen; +Cc: gentoo-portage-dev, Joakim Tjernlund

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

>>>>> On Wed, 23 Jun 2021, Fabian Groffen wrote:

> On 23-06-2021 08:47:58 +0200, Ulrich Mueller wrote:
>> It's somewhat hidden, but it's there:
>> https://projects.gentoo.org/pms/8/pms.html#x1-950009.1.10
>> 
>> 9.1.10 pkg_preinst
>> ... immediately before merging the package to the live filesystem. ...
>> 
>> 9.1.11 pkg_postinst
>> ... immediately after merging the package to the live filesystem. ...

> Aha, so does this mean pkg_prerm and pkg_postrm are run with replacing
> package in place, e.g. if they refer to scripts installed by the
> replaced package they may no longer exist or be the same?

PMS has similar wording for pkg_prerm and pkg_postrm, so (at least
according to the spec) the old package will still be present in
pkg_prerm and will be gone in pkg_postrm.

I don't think that the ebuild can rely on any particular status of the
new package in pkg_*rm (of the old package), or the status of the old
package in pkg_*inst (of the new package).

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-portage-dev] In what phase are file "merged"?
  2021-06-23 10:40     ` Ulrich Mueller
@ 2021-06-23 11:33       ` Michał Górny
  2021-08-05 22:14         ` Joakim Tjernlund
  0 siblings, 1 reply; 8+ messages in thread
From: Michał Górny @ 2021-06-23 11:33 UTC (permalink / raw
  To: gentoo-portage-dev, Fabian Groffen; +Cc: Joakim Tjernlund

On Wed, 2021-06-23 at 12:40 +0200, Ulrich Mueller wrote:
> > > > > > On Wed, 23 Jun 2021, Fabian Groffen wrote:
> 
> > On 23-06-2021 08:47:58 +0200, Ulrich Mueller wrote:
> > > It's somewhat hidden, but it's there:
> > > https://projects.gentoo.org/pms/8/pms.html#x1-950009.1.10
> > > 
> > > 9.1.10 pkg_preinst
> > > ... immediately before merging the package to the live filesystem.
> > > ...
> > > 
> > > 9.1.11 pkg_postinst
> > > ... immediately after merging the package to the live filesystem.
> > > ...
> 
> > Aha, so does this mean pkg_prerm and pkg_postrm are run with
> > replacing
> > package in place, e.g. if they refer to scripts installed by the
> > replaced package they may no longer exist or be the same?
> 
> PMS has similar wording for pkg_prerm and pkg_postrm, so (at least
> according to the spec) the old package will still be present in
> pkg_prerm and will be gone in pkg_postrm.
> 
> I don't think that the ebuild can rely on any particular status of the
> new package in pkg_*rm (of the old package), or the status of the old
> package in pkg_*inst (of the new package).

I would even say that it can't rely on the particular status of the old
package in any case, if it's meant to be removed.  In particular, its
dependencies can be unmerged before the package itself.

-- 
Best regards,
Michał Górny




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-portage-dev] In what phase are file "merged"?
  2021-06-23 11:33       ` Michał Górny
@ 2021-08-05 22:14         ` Joakim Tjernlund
  2021-08-06  4:22           ` Ulrich Mueller
  0 siblings, 1 reply; 8+ messages in thread
From: Joakim Tjernlund @ 2021-08-05 22:14 UTC (permalink / raw
  To: gentoo-portage-dev@lists.gentoo.org, mgorny@gentoo.org,
	grobian@gentoo.org

On Wed, 2021-06-23 at 13:33 +0200, Michał Górny wrote:
> On Wed, 2021-06-23 at 12:40 +0200, Ulrich Mueller wrote:
> > > > > > > On Wed, 23 Jun 2021, Fabian Groffen wrote:
> > 
> > > On 23-06-2021 08:47:58 +0200, Ulrich Mueller wrote:
> > > > It's somewhat hidden, but it's there:
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprojects.gentoo.org%2Fpms%2F8%2Fpms.html%23x1-950009.1.10&data=04%7C01%7CJoakim.Tjernlund%40infinera.com%7Cba02686be6d54ea9cc9108d9363acdd2%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C1%7C637600448462073359%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Jb60QbNzyIAUesXa9Z9YVlaGbbKBVVXK6qK%2BgiZ87%2BM%3D&reserved=0
> > > > 
> > > > 9.1.10 pkg_preinst
> > > > ... immediately before merging the package to the live
> > > > filesystem.
> > > > ...
> > > > 
> > > > 9.1.11 pkg_postinst
> > > > ... immediately after merging the package to the live filesystem.
> > > > ...
> > 
> > > Aha, so does this mean pkg_prerm and pkg_postrm are run with
> > > replacing
> > > package in place, e.g. if they refer to scripts installed by the
> > > replaced package they may no longer exist or be the same?
> > 
> > PMS has similar wording for pkg_prerm and pkg_postrm, so (at least
> > according to the spec) the old package will still be present in
> > pkg_prerm and will be gone in pkg_postrm.
> > 
> > I don't think that the ebuild can rely on any particular status of
> > the
> > new package in pkg_*rm (of the old package), or the status of the old
> > package in pkg_*inst (of the new package).
> 
> I would even say that it can't rely on the particular status of the old
> package in any case, if it's meant to be removed.  In particular, its
> dependencies can be unmerged before the package itself.

Stubled ove this mail again and noticed "its dependencies can be
unmerged before the package itself" stmt. That does not make sense to
me. Deps should be unmerged after any pkg that depends on them?

 Jocke

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-portage-dev] In what phase are file "merged"?
  2021-08-05 22:14         ` Joakim Tjernlund
@ 2021-08-06  4:22           ` Ulrich Mueller
  2021-08-06 20:53             ` Alec Warner
  0 siblings, 1 reply; 8+ messages in thread
From: Ulrich Mueller @ 2021-08-06  4:22 UTC (permalink / raw
  To: Joakim Tjernlund
  Cc: gentoo-portage-dev@lists.gentoo.org, mgorny@gentoo.org,
	grobian@gentoo.org

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

>>>>> On Fri, 06 Aug 2021, Joakim Tjernlund wrote:

> On Wed, 2021-06-23 at 13:33 +0200, Michał Górny wrote:
>> On Wed, 2021-06-23 at 12:40 +0200, Ulrich Mueller wrote:
>> > I don't think that the ebuild can rely on any particular status of
>> > the new package in pkg_*rm (of the old package), or the status of
>> > the old package in pkg_*inst (of the new package).
>> 
>> I would even say that it can't rely on the particular status of the
>> old package in any case, if it's meant to be removed.  In particular,
>> its dependencies can be unmerged before the package itself.

> Stubled ove this mail again and noticed "its dependencies can be
> unmerged before the package itself" stmt. That does not make sense to
> me. Deps should be unmerged after any pkg that depends on them?

A popular workflow is "emerge -c -p" followed by "emerge -C" on entries
of the list shown. IIUC emerge -C doesn't do any dependency resolution,
therefore ebuilds cannot rely on any removal order.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-portage-dev] In what phase are file "merged"?
  2021-08-06  4:22           ` Ulrich Mueller
@ 2021-08-06 20:53             ` Alec Warner
  0 siblings, 0 replies; 8+ messages in thread
From: Alec Warner @ 2021-08-06 20:53 UTC (permalink / raw
  To: gentoo-portage-dev
  Cc: Joakim Tjernlund, mgorny@gentoo.org, grobian@gentoo.org

On Thu, Aug 5, 2021 at 9:23 PM Ulrich Mueller <ulm@gentoo.org> wrote:
>
> >>>>> On Fri, 06 Aug 2021, Joakim Tjernlund wrote:
>
> > On Wed, 2021-06-23 at 13:33 +0200, Michał Górny wrote:
> >> On Wed, 2021-06-23 at 12:40 +0200, Ulrich Mueller wrote:
> >> > I don't think that the ebuild can rely on any particular status of
> >> > the new package in pkg_*rm (of the old package), or the status of
> >> > the old package in pkg_*inst (of the new package).
> >>
> >> I would even say that it can't rely on the particular status of the
> >> old package in any case, if it's meant to be removed.  In particular,
> >> its dependencies can be unmerged before the package itself.
>
> > Stubled ove this mail again and noticed "its dependencies can be
> > unmerged before the package itself" stmt. That does not make sense to
> > me. Deps should be unmerged after any pkg that depends on them?
>
> A popular workflow is "emerge -c -p" followed by "emerge -C" on entries
> of the list shown. IIUC emerge -C doesn't do any dependency resolution,
> therefore ebuilds cannot rely on any removal order.

Not quite sure I follow. Let's assume I have A -> B -> C.

Is it legal for A to call a binary packaged in A in A's pkg_prerm?
If yes, then B and C have to be on the livefs at least until A's
pkg_prerm has run; right?; otherwise if we unmerged B or C before then
we might break A's binaries?

-A

>
> Ulrich


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2021-08-06 20:53 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-06-22 23:11 [gentoo-portage-dev] In what phase are file "merged"? Joakim Tjernlund
2021-06-23  6:47 ` Ulrich Mueller
2021-06-23  7:08   ` Fabian Groffen
2021-06-23 10:40     ` Ulrich Mueller
2021-06-23 11:33       ` Michał Górny
2021-08-05 22:14         ` Joakim Tjernlund
2021-08-06  4:22           ` Ulrich Mueller
2021-08-06 20:53             ` Alec Warner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox