Hello,
<snip things about PKG_VERSION and so on>
Le 19/04/2012 18:40, Emmanuel Deloget a écrit :
I have no idea on how we can fix this, other than setting the correct
version numbers in the CONFIG_EGLIBC_VERSION.
I can provide a patch to fix the current state, but that would not make
much sense if 2.12 is to be removed from the tree. Of course, such a patch
shall also cure the problem when the user handpick a revision in the eglibc
trunk (but again, this might be removed as well).
No answer on that, so I submit and you decide.
I think the best course of action is to re-fetch the source in those cases:
* if the package is not prepared yet (i.e. if the user cleans the package
or before the package is built for the first time).
* if the package fails to compile
But we should avoid re-fetching the source once the package has been
successfully built.
For packages, these conditions can be factorized into the following one:
$(PKG_BUILD_DIR)/.built exists.
No patch for this, as I didn't come with any working and elegant solution.
Introducing OPENWRT_BLEEDING_EDGE raises the impression of
over-engineering to me. We still should try to avoid fetching HEAD of
sources (see above), however IF we provide the possibility - which is
opt-in and just for developers anyway - I don't see the point of
"un-hide" respective options first.
Fine with me. That was just yet another idea :)
Do you want me to resubmit a patch without OPENWRT_BLEEDING_EDGE?
No response on this subject, so I'll submit, and you'll decice :)
I'm going to post 3 patches. The first one correct the current
compilation issues. It's indepependant of the other patches (but
rely on the SVN revision to be correctly defined, otherwise it
won't work ; so applying either patch 2 or 3 is still a good
idea otherwise the user might break things by selecting bad eglibc
revisions).
The second one disable the possibility to select a specific revision
for known versions of eglibc.
The third one provide the same functionnality, and removes the
possibility to select the trunk version. Of course, this patch is not
compatible with the previous one, so you either apply 1 and 2 or you
apply 1 and 3 - but not 1, 2 and 3.
All patches will be posted in the next 10/15 minutes.
Best regards,
-- Emmanuel Deloget
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
