Tiziano Müller wrote: > Am Freitag, den 15.05.2009, 23:30 +0300 schrieb Petteri Räty: >> William Hubbs wrote: >>> On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote: >>>> On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote: >>>>> Thanks Robin for finally pushing this in the tree, just didn't find the >>>>> time to. >>>>> >>>>> Maybe it's a good time to emphasize this: Keep in mind that changing the >>>>> EAPI in an ebuild requires a revision bump (including reset to unstable >>>>> keywords, etc.). >>>> That's going to cause a large problem. >>>> The entire point is that the STABLE ebuilds need to be changed, >>>> otherwise they will try to depend on the libusb-1 series (and fail >>>> dismally). >>>> For switching from EAPI0 to EAPI1, if the ebuild still compiles fine, >>>> then I see no reason that a slot dep change cannot be just put in with >>>> the EAPI change. (The same cannot be said for EAPIx -> EAPI2, as further >>>> changes are needed for that case). >>> >>> As far as I know, the only time you need to do a rev bump and reset to >>> unstable is if you change the files that are installed by the package. >>> >>> So, as far as I know, unless you are migrating to an EAPI that is not >>> stable or changing the files that are installed by the package, it is >>> not necessary to do a rev bump just for changing the EAPI as long as >>> you make sure that the ebuild emerges fine under the new EAPI. >>> >> Indeed there's no problem switching EAPIs as long as a stable Portage >> supports the EAPI you are migrating to. Portage was buggy with this when >> EAPI 2 was introduced but that has since been fixed. > > Wrong. For example: > - stuff like docompress may change the content being installed depending > on the package manager > - --disable-static (maybe in a later EAPI) changes content > - slot-dep-operators change the rdepend of installed packages, so it > changes how the package manager has to handle reverse packages on > uninstall (in EAPI 3) >
Switching EAPIs in my mind means taking care it works with new EAPIs. Why switch in the first place if you aren't making modifications to the ebuild? > On the other hand you also have to make sure you have a stable portage > for a time long enough so mostly everyone has it installed. Otherwise > you could break users systems pretty badly depending on the packages. > And Arch-Teams usually do a pretty good job in catching such cases. > How would this breakage happen? The ebuild in the vdb still has the old EAPI. > And we also always said that a rev bump should be done on non trivial > changes or non-build-fixes and changing the EAPI is technical seen > mostly a non-trivial change. > Switching between EAPI 0 and 1 for example is quite trivial. In Java ebuilds we should always use slot deps because jars get installed to a SLOT dependent path. I doubt our users would want to see us revision bumping our ebuilds for that. > Do we want to document the following? (do we have already?) > - When is it allowed to use an EAPI in the tree (given as offset to the > release of portage supporting that eapi) > - When is it allowed to use an EAPI in the stable tree (given as offset > of when a portage version supporting that EAPI got stable) > Currently: 1. Usage of an EAPI in the tree is allowed after council gives the OK. 2. When the Portage version supporting it goes stable If you want please check devmanual and file a bug if it needs updating/new info regarding this. Regards, Petteri
signature.asc
Description: OpenPGP digital signature
