Ticket #1230 (closed defect: fixed)

Opened 7 years ago

Last modified 7 years ago

Paludis should not disable dependency tracking in EXTRA_ECONF

Reported by: uzytkownik Owned by:
Priority: Sometime Milestone:
Component: clients/cave Version: 0.72.2
Keywords: Cc:
Blocked By: Blocking:
Distribution: N/A

Description

Paludis disable dependency tracking if it is supported unconditionally in EXTRA_ECONF. It causes problems when it is broken and needs to be explicitly disabled (see  https://bugs.gentoo.org/show_bug.cgi?id=406117 ).

Proposed solution - use it at the beginning (econf XYZ -> ./configure --disable-dependency-tracking XYZ ${EXTRA_ECONF}) rather then end.

Change History

comment:1 follow-up: ↓ 2 Changed 7 years ago by ciaranm

  • Status changed from new to closed
  • Resolution set to upstream

PMS specifies this, not us.

comment:2 in reply to: ↑ 1 Changed 7 years ago by uzytkownik

Replying to ciaranm:

PMS specifies this, not us.

The PMS specify the need for including - not the ordering (at least I cannot find the ordering). The putting it at the end and making it impossible to override makes it break ebuilds.

comment:3 follow-up: ↓ 4 Changed 7 years ago by ciaranm

Ebuilds can't use EXTRA_ECONF anyway, so putting at the end doesn't help ebuilds.

comment:4 in reply to: ↑ 3 Changed 7 years ago by uzytkownik

Replying to ciaranm:

Ebuilds can't use EXTRA_ECONF anyway, so putting at the end doesn't help ebuilds.

You misunderstood me. If the econf would work as:

./configure ${OPTIONAL_DISABLE_DEPENDENCY_TRACKING} "$@" ${USER_EXTRA_EXCONF}

then ebuild could write it as (which works with portage):

econf --disable-dependency-tracking

Right now it is:

./configure "$@" ${USER_EXTRA_EXCONF} ${OPTIONAL_DISABLE_DEPENDENCY_TRACKING} 

Which makes it non-overridable by anyone (including users and ebuilds).

comment:5 follow-up: ↓ 6 Changed 7 years ago by ciaranm

Ebuilds aren't allowed to override it, so this doesn't fix your problem. And there's no point in giving users a feature whose sole purpose is to work around ebuild bugs.

comment:6 in reply to: ↑ 5 Changed 7 years ago by uzytkownik

Replying to ciaranm:

Ebuilds aren't allowed to override it, so this doesn't fix your problem. And there's no point in giving users a feature whose sole purpose is to work around ebuild bugs.

I am not sure if it should fully qualify as ebuild bug. The software is not buildable with --enable-dependency-tracking, and it seems that enabling dependency tracking is deliberate in autotools (which seems to have no option to hard-enable it). It looks for me as PMS bug to be honest[1].

I would be grateful for an advice how to fix an ebuild if you know.

[1] Yay - I love when 2 pieces of software simply don't work together due to their perfectly logical design...

comment:7 follow-up: ↓ 8 Changed 7 years ago by ciaranm

I'm wondering whether we can shift the --help-dependent stuff to be before $@ rather than after it without breaking any rules.

comment:8 in reply to: ↑ 7 Changed 7 years ago by uzytkownik

Replying to ciaranm:

I'm wondering whether we can shift the --help-dependent stuff to be before $@ rather than after it without breaking any rules.

If I understand the code correctly that what's portage is doing (I know that portage sometimes diverges from PMS but I couldn't find any specification about position of --disable-dependency-tracking):

                if ! has "$EAPI" 0 1 2 3 3_pre2 && \
                        "${ECONF_SOURCE}/configure" --help 2>/dev/null | \
                        grep -q disable-dependency-tracking ; then
                        set -- --disable-dependency-tracking "$@"
                fi

comment:9 Changed 7 years ago by dleverton

  • Status changed from closed to reopened
  • Resolution upstream deleted

comment:10 Changed 7 years ago by dleverton

  • Status changed from reopened to closed
  • Resolution set to fixed

ad2ae2b

Note: See TracTickets for help on using tickets.