Summary: | gnome2.eclass should reuse .la punting code from eutils.eclass | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
Component: | Eclasses | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 262490, 383901 |
Description
Michał Górny
2011-09-21 09:31:38 UTC
It is not possible to reuse that eclass since it does not support EAPI < 2. The best we could do is to copy/paste the code :(, it that what you are suggesting ? Well, I was thinking mostly about the eclass but you still can take a look if you want to. By the way, do you really want to support ancient EAPIs that long? I don't think there's a real benefit from it, and GNOME is probably alive enough to get things bumped. (In reply to comment #2) > By the way, do you really want to support ancient EAPIs that long? I don't > think there's a real benefit from it, and GNOME is probably alive enough to > get things bumped. I don't really care, but it would be annoying to update all the ebuilds still using older EAPIs. Plus I don't remember the outcome of the last discussion on eclass API breakage on gentoo-dev :( Well, there's no hurry. I'd just suggest bumping EAPIs on package bumps. That usually helps a lot keeping the tree up-to-date. (In reply to comment #4) > Well, there's no hurry. I'd just suggest bumping EAPIs on package bumps. > That usually helps a lot keeping the tree up-to-date. I try to bump eapi on every change/bump but there are still old packages using old eapis. Maybe the way to go would be to use that eclass for eapi >=2 and copy that function to gnome2.eclass for older eapis (to finally drop this compat when there are 0 ebuilds using gnome2.eclass and old eapis) now, eapi problem should be gone, but I doubt between how to handle "--all" option for prune_libtool_files function, as we are currently having ebuilds that would fit on "--all" (most) but a few of them (like libgphoto2) that rely on .la files. (In reply to comment #6) > now, eapi problem should be gone, but I doubt between how to handle "--all" > option for prune_libtool_files function, as we are currently having ebuilds > that would fit on "--all" (most) but a few of them (like libgphoto2) that > rely on .la files. --all is mostly for plugins. Usually, the function should handle everything; if it doesn't, feel free to report and I'll try to improve it. There are two options also: - Keep GNOME2_LA_PUNT variable, that would drop .la files always (as currently done, depending on static-libs USE) - Deprecate GNOME2_LA_PUNT and always call prune_libtool_files: shouldn't hurt as we have "lafilefixer" and "fixlafiles" portage FEATUREs but, as this would affect all ebuilds inheriting gnome2.eclass without a revbump... Anyway, if eapi5 is near, we would surely default to run prune_libtool_files always for that eapi, but no idea about package managers handling that removal themselves :/ + 17 Nov 2012; Pacho Ramos <pacho@gentoo.org> gnome2.eclass: + Rely on prune_libtool_files for eapis >= 5 as discussed with the team via + mail. + |