• [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp

    From Marek Szuba@21:1/5 to All on Thu Dec 9 14:30:01 2021
    Has been deprecated for quite a while now, comes from eutils.eclass
    so it blocks EAPI 8+. Just call mktemp directly.

    Signed-off-by: Marek Szuba <marecki@gentoo.org>
    ---
    eclass/gnome2-utils.eclass | 7 +++----
    1 file changed, 3 insertions(+), 4 deletions(-)

    diff --git a/eclass/gnome2-utils.eclass b/eclass/gnome2-utils.eclass
    index f7d45090f82..39c4797eedf 100644
    --- a/eclass/gnome2-utils.eclass
    +++ b/eclass/gnome2-utils.eclass
    @@ -1,4 +1,4 @@
    -# Copyright 1999-2020 Gentoo Authors
    +# Copyright 1999-2021 Gentoo Authors
    # Distributed under the terms of the GNU General Public License v2

    # @ECLASS: gnome2-utils.eclass
    @@ -16,10 +16,9 @@
    # * scrollkeeper (old Gnome help system) management

    [[ ${EAPI} == 5 ]] && inherit multilib
    -# eutils.eclass: emktemp
    # toolchain-funs.eclass: tc-is-cross-compiler
    # xdg-utils.eclass: xdg_environment_reset, xdg_icon_cache_update
    -inherit eutils toolchain-funcs xdg-utils
    +inherit toolchain-funcs xdg-utils

    case ${EAPI} in
    5|6|7) ;;
    @@ -379,7 +378,7 @@ gnome2_gdk_pixbuf_update() {
    fi

    ebegin "Updating gdk-pixbuf loader cache"
    - local tmp_file=$(emktemp)
    + local tmp_file=$(mktemp "${T}"/tmp.XXXXXXXXX
  • From =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=@21:1/5 to Marek Szuba on Thu Dec 9 16:10:01 2021
    On Thu, 2021-12-09 at 13:23 +0000, Marek Szuba wrote:
    Has been deprecated for quite a while now, comes from eutils.eclass
    so it blocks EAPI 8+. Just call mktemp directly.

    Signed-off-by: Marek Szuba <marecki@gentoo.org>
    ---
    eclass/gnome2-utils.eclass | 7 +++----
    1 file changed, 3 insertions(+), 4 deletions(-)

    diff --git a/eclass/gnome2-utils.eclass b/eclass/gnome2-utils.eclass
    index f7d45090f82..39c4797eedf 100644
    --- a/eclass/gnome2-utils.eclass
    +++ b/eclass/gnome2-utils.eclass
    @@ -1,4 +1,4 @@
    -# Copyright 1999-2020 Gentoo Authors
    +# Copyright 1999-2021 Gentoo Authors
    # Distributed under the terms of the GNU General Public License v2

    # @ECLASS: gnome2-utils.eclass
    @@ -16,10 +16,9 @@
    # * scrollkeeper (old Gnome help system) management

    [[ ${EAPI} == 5 ]] && inherit multilib
    -# eutils.eclass: emktemp
    # toolchain-funs.eclass: tc-is-cross-compiler
    # xdg-utils.eclass: xdg_environment_reset, xdg_icon_cache_update
    -inherit eutils toolchain-funcs xdg-utils
    +inherit toolchain-funcs xdg-utils

    case ${EAPI} in
    5|6|7) ;;
    @@ -379,7 +378,7 @@ gnome2_gdk_pixbuf_update() {
    fi

    ebegin "Updating gdk-pixbuf loader cache"
    - local tmp_file=$(emktemp)
    + local tmp_file=$(mktemp "${T}"/tmp.XXXXXXXXXX) || die "Failed to create temporary file"

    Why do you need to use random name in the first place? We have full
    control over T, so why not just hardcode a good name?

    ${updater} 1> "${tmp_file}" &&
    chmod 0644 "${tmp_file}" &&
    cp -f "${tmp_file}" "${EROOT%/}/usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache" &&

    --
    Best regards,
    Michał Górny

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marek Szuba@21:1/5 to All on Mon Dec 13 11:30:02 2021
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------kIFwHy0lUuRY9Ot4cA99aDmy
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    T24gMjAyMS0xMi0wOSAxNTowNCwgTWljaGHFgiBHw7Nybnkgd3JvdGU6DQoNCj4gV2h5IGRv IHlvdSBuZWVkIHRvIHVzZSByYW5kb20gbmFtZSBpbiB0aGUgZmlyc3QgcGxhY2U/ICBXZSBo YXZlIGZ1bGwNCj4gY29udHJvbCBvdmVyIFQsIHNvIHdoeSBub3QganVzdCBoYXJkY29kZSBh IGdvb2QgbmFtZT8NCg0KSGF2aW5nIGRpc2N1c3NlZCB0aGUgbWF0dGVyIHdpdGggZWNsYXNz IG1haW50YWluZXJzIG9uIElSQywgdGhleSBhcmUgbm90IA0KZW50aXJlbHkgc3VyZSB3aGV0 aGVyIHVzaW5nIGEgc3RhdGljIG5hbWUgaW4gdGhpcyBjb250ZXh0IGlzIGVudGlyZWx5IA0K c2FmZS4gVGhlcmUgd2VyZSBhbHNvIGNvbmNlcm5zIGFib3V0IG1ha2luZyB0aGlzIGNoYW5n ZSB0b28gYWdncmVzc2l2ZSANCmdpdmVuIGl0IGFmZmVjdHMgYWxsIHN1cHBvcnRlZCBFQVBJ cy4gVGhlcmVmb3JlLCB3ZSBoYXZlIGRlY2lkZWQgdG8gcGxheSANCml0IHNhZmUgYW5kIHN0 aWNrIGFzIGNsb3NlbHkgdG8gb2xkIGJlaGF2aW91ciBhcyBwb3NzaWJsZSwgYXQgbGVhc3Qg Zm9yIG5vdy4NCg0KQW55d2F5LCBtZXJnZWQgYSBtb21lbnQgYWdvLg0KDQotLSANCk1hcmVj a2kNCg==

    --------------kIFwHy0lUuRY9Ot4cA99aDmy--

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEE+MBeYVMkcD2jfqCrKMQ7KFUeMgEFAmG3HkIACgkQKMQ7KFUe MgFiRA//ZacCsvI+xDlthCCsfcK19ojM9VhXWqmCCGXzCSpSjSAufpCefEUFpz0i Bzh371YSB8uK99N3bVhjZ8n7fZyAfJsHvkIK8EpNbvvC06DPRCn4c3eChr8+6egp sMBQifN98vTx2pySQ9loQ4i7IUu0HraMj1n66kjK7FULAw1qTTxM2jkifLiU79v8 aL48HQSNRUM5IkjGDje7jEikBK02f8ETZEj1a2Z8s5wnD8B5BrLA3iCtKh1QuJWn ZWGZtwdxotc+MJQY3dTl+VFYgw98YH92gNU5s09PpjpojIJeAbm6rI1TpibSUIaJ 96UTBxGoHVwlVqjAPeCTydhthLGNU17MxViaBDwGkpmovkgoFbpMjwe+ERJv6I+o UNPimaxqASU3mmRlaDDPq7GzGzy+wBOX0UMa4IAcE5tWS2NGNIeiSCQaupa+Mvfa AosHWth4Zn9x01kJpLtQ9SjDNgnN4cTUsYoubHAHwNQrVtBzhovmHtBz3LwJeugG bqGJh1p2ptmhCWAtqnyuxHWX5tc4q6ohLTL9jwEAfX/zDCal+ajKlBaabA25m0wV Q1dXlCuEYm7sFGbuab8N0fD4cN5Cs+UJkpdokzjXekgZMw8T4I+BShzaA8kfdf4M BOlpsS7XJfB/nzyfvFKp6vcJtfvkYnn9xqsXMQstMJ23HlQbLgY=
    =2VkL
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mart Raudsepp@21:1/5 to All on Mon Dec 13 18:30:02 2021
    Ühel kenal päeval, E, 13.12.2021 kell 10:19, kirjutas Marek Szuba:
    On 2021-12-09 15:04, Michał Górny wrote:

    Why do you need to use random name in the first place?  We have
    full
    control over T, so why not just hardcode a good name?

    Having discussed the matter with eclass maintainers on IRC, they are
    not
    entirely sure whether using a static name in this context is entirely
    safe. There were also concerns about making this change too
    aggressive
    given it affects all supported EAPIs. Therefore, we have decided to
    play
    it safe and stick as closely to old behaviour as possible, at least
    for now.

    Anyway, merged a moment ago.

    Actually I kind of preferred a static name over straight mktemp,
    because emktemp supported other cases than a pure mktemp usage does.
    But I don't know if it could ever clash things in some weird
    situations. I think they won't, but I don't know if PMS guarantees that
    or just happens how portage works right now (e.g. the postrm currently happening in a separate ._unmerge directory path for $T; multilib
    postinst happening sequentially, etc).

    Thinking it through again a bit, straight mktemp can't be worse than a
    static name anyways (provided mktemp exists, which emktemp handled..),
    so we're good there, but provided you or someone thinks through the corner-cases, I'm in favor of a static name if it doesn't have any
    trouble.


    Mart

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2

    iQKTBAABCgB9FiEEUdZn9pOq0mlNjRvdEKbJ+k9JlgYFAmG3gcNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDUx RDY2N0Y2OTNBQUQyNjk0RDhEMUJERDEwQTZDOUZBNEY0OTk2MDYACgkQEKbJ+k9J lgbPmg//Wou6gVdzSJfgI+GnBq3smpe6b0q2l8DMCipZb1nCQIWNsj4Zl+1vO4WG ee4ojOVSkJtFxigJu0ZUrpRv2mVHL6RT2H4hIs/Z496NuPuoQUKKS8uFkYYLmqVu 24o14BRJlyMdPFPLqgwMV2qvRCyVXyy58Y/Rg9V7eg2NuhD4myxKaAAPPqeh8YFr ZZNE25tMt5gF2rP+j/jChgNuPzqx0R926PBbnNBS45L2tm4YY1NjVd1YmOUg6Zbr XwOBuY564l3oBPh1xXJxGayYIUhNlOBbQh4jz3bBIFfxoKnXXL0UP9lX98LRrwo4 ousb9QY74sIXThaWqU/BPLESsWjWI3AeItNi0JK1RnQeXv1brPEuxk0Hfu1+KUQh F2faxvNs44Qv8tXB6mtSeRUSyH09VVIG1oqhxUeFmehNXnpOJq0WbMNurrqtSfKn yZkK9FD/yy8glajxTeTvh3MywY8CZvXV9yG3YUyb0RS+MEkYUo4AbHe6NLB6PgvQ lCBfQIqtuzxvBUXFfer6xcALMe4LqAlN4BM98joiZezWGf4pom+W8d2aani1iWjy +v81hGSnZVuSCpeuAOV/or+ag0MW4ofGW47d15qeMbjpc7iDy4V7VP5PdziU03U8 oQcv/Fmu3Al+rg9IQdexyCoysPgHJBCFzjX/BRhGSgB3JyVZpDY=
    =VQKz
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marek Szuba@21:1/5 to Mart Raudsepp on Sun Dec 26 10:50:01 2021
    On 13 December 2021 17:24:18 UTC, Mart Raudsepp <leio@gentoo.org> wrote:

    Actually I kind of preferred a static name over straight mktemp,
    because emktemp supported other cases than a pure mktemp usage does.
    But I don't know if it could ever clash things in some weird
    situations.

    That last part is the message I tried to convey in my e-mail, sorry if I wasn't clear enough.

    Anyway, could anyone with more Postage/PMS experience weigh in on this? If it is indeed safe then the eclass could be modified further, e.g. to use static names with EAPI-8+ but stick with mktemp for older EAPIs just to be safe.

    --
    Marecki

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=@21:1/5 to Marek Szuba on Sun Dec 26 11:00:01 2021
    On Sun, 2021-12-26 at 09:44 +0000, Marek Szuba wrote:

    On 13 December 2021 17:24:18 UTC, Mart Raudsepp <leio@gentoo.org> wrote:

    Actually I kind of preferred a static name over straight mktemp,
    because emktemp supported other cases than a pure mktemp usage does.
    But I don't know if it could ever clash things in some weird
    situations.

    That last part is the message I tried to convey in my e-mail, sorry if I wasn't clear enough.

    Anyway, could anyone with more Postage/PMS experience weigh in on this? If it is indeed safe then the eclass could be modified further, e.g. to use static names with EAPI-8+ but stick with mktemp for older EAPIs just to be safe.

    I suppose it's not specified strictly but T should be safe for all sane
    uses. If it weren't, we'd already be in deep trouble and gnome2-utils
    would be the least of our concerns.

    That said, making this EAPI-conditional is just an unnecessary
    complexity.

    --
    Best regards,
    Michał Górny

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mart Raudsepp@21:1/5 to All on Sun Dec 26 11:20:01 2021
    Ühel kenal päeval, P, 26.12.2021 kell 10:50, kirjutas Michał Górny:
    On Sun, 2021-12-26 at 09:44 +0000, Marek Szuba wrote:

    On 13 December 2021 17:24:18 UTC, Mart Raudsepp <leio@gentoo.org>
    wrote:

    Actually I kind of preferred a static name over straight mktemp,
    because emktemp supported other cases than a pure mktemp usage
    does.
    But I don't know if it could ever clash things in some weird
    situations.

    That last part is the message I tried to convey in my e-mail, sorry
    if I wasn't clear enough.

    Anyway, could anyone with more Postage/PMS experience weigh in on
    this? If it is indeed safe then the eclass could be modified
    further, e.g. to use static names with EAPI-8+ but stick with
    mktemp for older EAPIs just to be safe.

    I suppose it's not specified strictly but T should be safe for all
    sane
    uses.  If it weren't, we'd already be in deep trouble and gnome2-
    utils
    would be the least of our concerns.

    That said, making this EAPI-conditional is just an unnecessary
    complexity.

    It's already hardcoded to $T via using mktemp instead of emktemp (which supported lack of $T or mktemp utility, unlike the replacement that was
    merged) - so if $T and mktemp is guaranteed, we are good there. It was introduced with mktemp in the first place and then vapier changed it to
    emktemp without any reason given beyond probably just doing it for
    everything to support lack of mktemp on the system or some such.


    Now the question was, can we hardcode the name instead - is it possible
    for it to be running things in parallel and clash on the name, e.g.:

    * postinst and postrm ran at the same time on replacement: is it doing ._unmerge dir in portage an implementation detail that we shouldn't
    rely on it?

    * postinst and/or postrm ran with multilib support: could they be
    running in parallel in the future for the different ABIs -- should we
    include the ABI in the static filename at least to avoid clashes there?


    Mart

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2

    iQKTBAABCgB9FiEEUdZn9pOq0mlNjRvdEKbJ+k9JlgYFAmHIQT5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDUx RDY2N0Y2OTNBQUQyNjk0RDhEMUJERDEwQTZDOUZBNEY0OTk2MDYACgkQEKbJ+k9J lgYRNQ/+LkC0ZtLYsDga9nmlxPCvwn2y2tKMVbFWIY1HAUI3Ugcf9HZ8PdXJNOul 181Gw6XnfsYl6ddteAQCfiL6D593p7S7KXCvvanGYuQvrI3fWvBIjCALlLx1ke7N i+Pxb/uP/fW/OWI+G4U6Cy9WtlSYlTE1LKtlrbbh8FLejkCCnCcCkWE8AWUoPdCL w+70D7Dkj5D/Kd5uab606mb1c6adzpjPCwr/GDSOv6h6K2LpThPiQJ7+qYEo2s5g AQQqtxvQxw+yJZdgwW5DbDV6DQdKEwzfczrcfXZw4N4INqfSXAX2bCxvQwnbAqS5 sH0EXIlYCpt9RH1EgArsh+uv1f9kg6xM5onplumChAiI3t7jxmPpRheUZPms3O7e 4sSTb7aNYi7A0hxLUkchZuBfYIRBhErexiFGfn1e/XgZgdsfV5Medlz/1BcelvP8 wRoXiTmxuZk4cjI1YXMthr8biYauXN6Qy1tg1opSozz8mPfpWsUtjT8vcvd9i4L2 CLzC1Tk1tCjHPKu1despuE0sAVBcXHN+/2XYApg7SLjnqQsYnOM7MY46ySFwFUB2 qiyeIcA5c3RZqLIJjh8QWB8h1rQm2jLYS+Tl53G0zDsb/FHAPvS8SF0alkMHquYV xOe+rUc4eAAGd/cphI4kBNDLhEX/Mn9PbdmbBQXiKlQm37N0qhw=
    =plL0
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)