Created attachment 322802 [details, diff] patch for timezone-data-2012e.ebuild Changes: -EAPI bumped to 4 -one extra emake argument -${D} -> ${ED} -${ROOT} -> ${EROOT}
we've been locking glibc to EAPI=0. it depends directly on timezone-data. so i'm not keen on moving that to EAPI=4 yet.
(In reply to comment #1) > we've been locking glibc to EAPI=0. it depends directly on timezone-data. > so i'm not keen on moving that to EAPI=4 yet. Give me a hint, why did we locked glibc again? EAPI=3 would be enough as well. What happens to EPREFIX on EAPI=0, is it available if non-empty?
(In reply to comment #2) > EAPI=3 would be enough as well. What happens to EPREFIX on EAPI=0, is it > available if non-empty? It is "available" but portage doesn't know of it, so the env can leak in, not good. Therefore, you have to "guard" it like: has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX= but that has it's own set of problems and shouldn't be used in ebuilds.
(In reply to comment #1) > we've been locking glibc to EAPI=0. it depends directly on timezone-data. > so i'm not keen on moving that to EAPI=4 yet. Hi, could you please point me some reference that why do we lock glibc? I feel a bit lost against the recent thread http://article.gmane.org/gmane.linux.gentoo.devel/79633.
(In reply to comment #4) > (In reply to comment #1) > > we've been locking glibc to EAPI=0. it depends directly on timezone-data. > > so i'm not keen on moving that to EAPI=4 yet. > > Hi, could you please point me some reference that why do we lock glibc? > > I feel a bit lost against the recent thread > http://article.gmane.org/gmane.linux.gentoo.devel/79633. glibc is not the issue here as prefix uses the host's libc by default. (open another issue for that if you want!) I don't really see a problem with glibc having a dependency on a EAPI=4 package as many @system packages are already EAPI=4.
(In reply to comment #5) glibc doesn't depend on packages that require newer EAPI. the fact that some other @system packages do doesn't matter. i have many packages set to EAPI=0 to make upgrading older systems much easier -- bootstrap the core up, and then you can move on to the rest of @system. along those lines, i might reconsider EAPI=2 for toolchain packages. but no way i'm doing EAPI=3 or EAPI=4 any time soon as those are too new.
(In reply to SpanKY from comment #6) > along those lines, i might reconsider EAPI=2 for toolchain packages. but no > way i'm doing EAPI=3 or EAPI=4 any time soon as those are too new. 9 months later, are we still fixed to EAPI<=2 ?
(In reply to SpanKY from comment #6) > (In reply to comment #5) > > glibc doesn't depend on packages that require newer EAPI. the fact that > some other @system packages do doesn't matter. i have many packages set to > EAPI=0 to make upgrading older systems much easier -- bootstrap the core up, > and then you can move on to the rest of @system. > > along those lines, i might reconsider EAPI=2 for toolchain packages. but no > way i'm doing EAPI=3 or EAPI=4 any time soon as those are too new. EAPIs 1 and 2 is deprecated, so how about moving to EAPI=3 now?
Mike's offline until Aug. Now is not a good time to be pinging these bugs.
Created attachment 357018 [details, diff] patch against timezone-data-2013c.ebuild
Comment on attachment 357018 [details, diff] patch against timezone-data-2013c.ebuild > emake \ >+ DESTDIR="${EPREFIX}" \ why ? this is the compile phase, not install ... >+ emake install ${zic} DESTDIR="${D}${EPREFIX}" || die isn't this what $ED is for ? and shouldn't the die get dropped ?
Created attachment 357974 [details, diff] patch against timezone-data-2013d.ebuild (In reply to SpanKY from comment #11) > Comment on attachment 357018 [details, diff] [details, diff] > patch against timezone-data-2013c.ebuild > > emake \ > >+ DESTDIR="${EPREFIX}" \ > why ? this is the compile phase, not install ... Right, removed > >+ emake install ${zic} DESTDIR="${D}${EPREFIX}" || die > isn't this what $ED is for ? and shouldn't the die get dropped ? I want to keep the changes minimal, removed this and one more die.
(In reply to Christoph Junghans from comment #12) i'll merge this with the next timezone-data version bump
Actually, the patch is EAPI=3 (I remember that was the highest you wanted to bump the base-system packages), so the two dies have to stay as EAPI=4 comes with auto-die.
(In reply to Christoph Junghans from comment #12) > Created attachment 357974 [details, diff] [details, diff] > patch against timezone-data-2013d.ebuild > > (In reply to SpanKY from comment #11) > > Comment on attachment 357018 [details, diff] [details, diff] [details, diff] > > patch against timezone-data-2013c.ebuild > > > emake \ > > >+ DESTDIR="${EPREFIX}" \ > > why ? this is the compile phase, not install ... > Right, removed hang on: Makefile:TOPDIR= $(DESTDIR)/usr Makefile:TZDIR= $(TOPDIR)/share/zoneinfo tzfile.h:#ifndef TZDIR tzfile.h:#define TZDIR "/usr/local/etc/zoneinfo" /* Time zone object file directory */ tzfile.h:#endif /* !defined TZDIR */ and tzselect.8:\f3TZDIR\fP ... So perhaps it would be better to define TZDIR, but it was put there with a reason like this. Don't have the time now to check for more/other problems.
(In reply to Fabian Groffen from comment #15) > (In reply to Christoph Junghans from comment #12) > > Created attachment 357974 [details, diff] [details, diff] [details, diff] > > patch against timezone-data-2013d.ebuild > > > > (In reply to SpanKY from comment #11) > > > Comment on attachment 357018 [details, diff] [details, diff] [details, diff] [details, diff] > > > patch against timezone-data-2013c.ebuild > > > > emake \ > > > >+ DESTDIR="${EPREFIX}" \ > > > why ? this is the compile phase, not install ... > > Right, removed > > hang on: > > Makefile:TOPDIR= $(DESTDIR)/usr > Makefile:TZDIR= $(TOPDIR)/share/zoneinfo > > tzfile.h:#ifndef TZDIR > tzfile.h:#define TZDIR "/usr/local/etc/zoneinfo" /* Time zone object file > directory */ > tzfile.h:#endif /* !defined TZDIR */ > > and > > tzselect.8:\f3TZDIR\fP > ... > > So perhaps it would be better to define TZDIR, but it was put there with a > reason like this. Don't have the time now to check for more/other problems. You are absolutely right, I should not have rushed with that. LOCALE_HOME and TZDIR seem to be the variables used in the code.
Created attachment 358068 [details, diff] patch against timezone-data-2013d.ebuild Update: - added back dies due to EAPI=3 - set TOPDIR in src_compile as all other variables are build from that. - at TOPDIR is "$(DESTDIR)/usr", DESTDIR="${ED}" is correct in src_install
Isn't it that the use of 'usex' function in 'src_compile' require EAPI >= 5? export NLS=$(usex nls 1 0) p.s. Not sure that is good place to ask... but this patch is introducing EAPI changes, so may be it make sense.
(In reply to nkulikov from comment #18) > Isn't it that the use of 'usex' function in 'src_compile' require EAPI >= 5? > > export NLS=$(usex nls 1 0) > > p.s. Not sure that is good place to ask... but this patch is introducing > EAPI changes, so may be it make sense. No, this was not a good place to ask as the patch hasn't changed anything related to usex. Anyhow, usex gets defined in eutils.eclass for EAPI<=4.
(In reply to Christoph Junghans from comment #17) ok, i'll merge this the next time they do a timezone-data release
I merged this for 2013f. There's also a number of updates in the upstream Makefile, so please review the interaction of this patch with my latest Makefile patch.
