Bo Ørsted Andresen wrote: > On Friday 21 December 2007 05:25:00 Zhang Le wrote: >> The question is really simple. >> Whether we should have two different place to define EAPI? > > We need two places because it wasn't implemented properly in the first place > and we want to retain backwards compatibility for people who use old versions > of portage. The whole point is to keep a sane upgrade path available > indefinitely for people with old versions of portage.
Thanks, now I understand this. However, in the first draft the majority part of the glep talks about how to decide EAPI value, which could make others misunderstand the real point behind it. It should be made more clear in the first place, fortunately peper has done that in the new draft of glep-55. BTW, thanks to peper for drafting this glep! However, this doesn't mean I have wholehearted accept this glep. This just means if we ever decided we need ".ebuild-1" suffix, then surely we need such an agreement on how to decide EAPI value. > >> Proponents are trying to prove that we should at least need it be in file >> name. > > We need the file name to change because otherwise old versions of portage > will > try to source the ebuild when the EAPI is unknown. This either blocks new > useful features that will make old versions of portage fail to source them or > results in more bug reports with zillions of dupes (like the bugs in [1]) > because people with ancient versions of portage feel the need to report bug > reports when portage fails after a sync. I think we can educate our user about what is really going on and how to sovle this problem (upgrade PM), by GWN/NEWs on front page/IRC topics/Forums stick threads and so no. > At the very least it means waiting for a year between a release with a > version > of portage that supports this and an EAPI that takes advantage of it. So now > that leaves the question whether we want to change the file name once and > hope that we won't need to do it again or whether we want to use the > technically more flexible way where the file name changes whenever a new EAPI > gets agreed upon. This is another thing needed to be sorted out before we decide to take this suffix approach. > > Or alternatively whether we want to limit ourselves by using an inferior > solution that limits or delays progress considerably and results in more bug > reports with zillions of dupes... Honestly I really don't think our progress would be delayed in any way. The argument to which other approach would delay our progress is that we need to wait people to upgrade their PM. (If this assertion is wrong please ignore th e following sentence) But upgrading PM is very easy, we can use all the channels we have to inform user to upgrade their PM. And people are themselves doing this all the time. BTW, if we decide to use .ebuild-1, will we provide a ebuild file for each EAPI for a specific version of software? I guess probably not, coz that is a huge waste of time and energy. If this is the case, then presumably we only provide new EAPI ebuild for new versions. If a user want to use the new version, he *has* to upgrade his PM so that it could support the new EAPI. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
