Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 686350 - savedconfig.eclass: Configuration file schemes with ${CTARGET} / ${CHOST} should not be used when ${CTARGET} / ${CHOST} are empty
Summary: savedconfig.eclass: Configuration file schemes with ${CTARGET} / ${CHOST} sho...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All All
: Normal normal
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on: 686348
Blocks: 575164
  Show dependency tree
 
Reported: 2019-05-19 23:55 UTC by Arfrever Frehtes Taifersar Arahesis
Modified: 2019-08-09 14:56 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch (savedconfig.eclass.patch,1.95 KB, patch)
2019-05-20 00:28 UTC, Arfrever Frehtes Taifersar Arahesis
Details | Diff
Patch (savedconfig.eclass.patch,3.30 KB, patch)
2019-08-09 05:04 UTC, Arfrever Frehtes Taifersar Arahesis
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Arfrever Frehtes Taifersar Arahesis 2019-05-19 23:55:12 UTC
restore_config() is documented to support these configuration file name schemes:
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${PF}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PF}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PF}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${P}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${P}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${P}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${PN}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PN}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PN}

However variants with ${CTARGET} and ${CHOST} are used even when ${CTARGET} / ${CHOST} are empty.
${CTARGET} is usually empty, so effectively ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PF} is used before ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PF} etc.
Comment 1 Arfrever Frehtes Taifersar Arahesis 2019-05-20 00:28:05 UTC
Created attachment 577334 [details, diff]
Patch
Comment 2 Thomas Deutschmann (RETIRED) gentoo-dev 2019-08-03 13:32:59 UTC
I missed this one an proposed my own solution https://archives.gentoo.org/gentoo-dev/message/d9669ce53038803b5560445cbf35ab47 instead.
Comment 4 Arfrever Frehtes Taifersar Arahesis 2019-08-09 04:21:11 UTC
Unfortunately your commit does not solve the original problem and does not satisfy suggestion from the title of this bug.
(Your commit makes unrelated cosmetic improvements.)


Example situation:
  ${CTARGET} is empty
  ${CHOST} is non-empty
  ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PN} exists
  ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PN} exists
  Other configuration files do not exist

Both before and after your commit, ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PN} is used.

With my patch, ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PN} would be used.


The order of checked configuration files is documented in eclass:
# ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${PF}
# ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PF}
# ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PF}
# ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${P}
# ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${P}
# ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${P}
# ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${PN}
# ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PN}
# ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PN}
Comment 5 Arfrever Frehtes Taifersar Arahesis 2019-08-09 05:04:37 UTC
Created attachment 586286 [details, diff]
Patch

Updated patch.
"checked" variable changed to an array, so checking of elements can be done easier using has() function.
Quoting of one path added.
Comment 6 Thomas Deutschmann (RETIRED) gentoo-dev 2019-08-09 12:06:20 UTC
Problem was that checked file path always contained CTARGET and CHOST, even when empty resulted in "//", bug 575164.

Before that change:

> >>> Preparing source in /var/tmp/portage/sys-kernel/linux-firmware-20190717/work/linux-firmware-20190717 ...
>  * Checking existence of /etc/portage/savedconfig//sys-kernel/linux-firmware-20190717 ...
>                                                  ^^
>  * found /etc/portage/savedconfig//sys-kernel/linux-firmware-20190717
>                                  ^^                                   
>  * Building using saved configfile /etc/portage/savedconfig//sys-kernel/linux-firmware-20190717
>                                                            ^^
>  * Removing all files not listed in config ...
> >>> Source prepared.

And now:

USE=savedconfig, without any saved config:

> >>> Preparing source in /var/tmp/portage/sys-kernel/linux-firmware-20190726-r2/work/linux-firmware-20190726 ...
>  * Checking existence of "/etc/portage/savedconfig/sys-kernel/linux-firmware-20190726-r2" ...
>  * Checking existence of "/etc/portage/savedconfig/sys-kernel/linux-firmware-20190726" ...
>  * Checking existence of "/etc/portage/savedconfig/sys-kernel/linux-firmware" ...
>  * No saved config to restore - please remove USE=savedconfig or
>  * provide a configuration file in /etc/portage/savedconfig/sys-kernel/linux-firmware
>  * Your config file(s) will not be used this time
>  * Removing all files not listed in config ...
> >>> Source prepared.

USE=savedconfig, with existing /etc/portage/savedconfig/sys-kernel/linux-firmware-20190726-r2

> >>> Preparing source in /var/tmp/portage/sys-kernel/linux-firmware-20190726-r2/work/linux-firmware-20190726 ...
>  * Checking existence of "/etc/portage/savedconfig/sys-kernel/linux-firmware-20190726-r2" ...
>  * Found "/etc/portage/savedconfig/sys-kernel/linux-firmware-20190726-r2"
>  * Building using saved configfile "/etc/portage/savedconfig/sys-kernel/linux-firmware-20190726-r2"
>  * Removing all files not listed in config ...
> >>> Source prepared.

And when you debug eclass you see that $CHOST and $CTARGET checks are working:

> + for check in {${CATEGORY}/${PF},${CATEGORY}/${P},${CATEGORY}/${PN}}
> + configfile=/etc/portage/savedconfig/my-ctarget/sys-kernel/linux-firmware-20190726-r2
> + [[ -r /etc/portage/savedconfig/my-ctarget/sys-kernel/linux-firmware-20190726-r2 ]]
> + configfile=/etc/portage/savedconfig/my-chost/sys-kernel/linux-firmware-20190726-r2
> + [[ -r /etc/portage/savedconfig/my-chost/sys-kernel/linux-firmware-20190726-r2 ]]
> + configfile=/etc/portage/savedconfig/sys-kernel/linux-firmware-20190726-r2

I see no problem.
Comment 7 Arfrever Frehtes Taifersar Arahesis 2019-08-09 14:56:43 UTC
This bug is about wrong order of checked files, not about cosmetic things in output.

When ${CHOST} is non-empty and ${CTARGET} is empty, then the following paths should be checked in this order:

${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PF}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PF}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${P}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${P}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PN}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PN}

But current code checks paths in this order:

${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PF}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PF}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${P}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${P}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PN}
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PN}