| Summary: | Switch gnome2.eclass to use emake in gnome2_src_install | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Petteri Räty (RETIRED) <betelgeuse> |
| Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Is there some advantage to this? Or is it just asthetics? Obviously, it's nicer to have ebuilds use emake, because everyone sees them, but this is an eclass; changing it will cause huge metadata churn for the whole world. Is there any gain to it? (I'm not against it; I'm merely prioritizing) (In reply to comment #1) > Is there some advantage to this? Or is it just asthetics? Obviously, it's > nicer to have ebuilds use emake, because everyone sees them, but this is an > eclass; changing it will cause huge metadata churn for the whole world. Is > there any gain to it? > > (I'm not against it; I'm merely prioritizing) > Yes. It makes using MAKEOPTS possible and respects the MAKE variable. It's also the way to do it told by policy. I regularly change Java eclasses that are used by hundreds of ebuilds... It's only a strain on the servers generating the metadata cache any way. *** This bug has been marked as a duplicate of bug 20284 *** (In reply to comment #3) > > *** This bug has been marked as a duplicate of bug 20284 *** > Seems like a typo or something as that bug is about qmail. *** This bug has been marked as a duplicate of bug 202184 *** |
make DESTDIR=${D} "scrollkeeper_localstate_dir=${D}${sk_tmp_dir} " "$@" install || die "install failed" should use emake here nowadays