В Срд, 04/08/2010 в 09:42 +0000, Jorge Manuel B. S. Vicetto пишет: > If you take KDE's team example, we provide ebuilds to track the stable > branch from upstream in our overlay. They're called <version>.9999. > It's true that our ebuild does use the live vcs, but in this case the > difference is that instead of the users using a live ebuild, they get > a snapshot of the tree done by our maintainer from time to time. > Trying to pretend these "snapshot" ebuilds are the release version is > very wrong and no one should assume they'll build fine.
Even for official upstream releases build tests are not enough. So there is not difference with _p here. > There are already a few bugs that can be attributed to this. Ok, let's say that this depends on upstream. And for Gentoo this means that the decision how to set version for the package depends on maintainer. Lot's of packages do not have dedicated release tests upstream (even build tests) and for this packages I don't see difference between stable branch and release. In such case our version just indicates that our package is base on tarbal of that version and nothing more. > The point here is that one thing is for a maintainer to pick specific > commits from the stable branch and back port them to fix some bugs, > another thing is to blindly fetch a snapshot of the stable branch. In reality it's hard to see difference if commit was done blindly or it was well tested until obvious crash happens. > It would be based on a release if it only applied specific patches to > fix known issues. The minute you start "tracking" a stable branch you > should stop calling it a release and 300kloc is not a "small" patch. Actually I think this limit depends on size of project. In any case until we have something documented that's up to maintainer... > This is unfortunately the main issue here. You may work on a specific > package on Gentoo, but when that package is essential for the system > use / stability, it stops being just "your" package. This latest > example has lead users to a point where their PM stopped working. > Breaking the PM is not a small "oops" That's completely different topic... I'm not talking about stability at all. Of course, python is special package and should be treated/tested by maintainers as such! Probably for such core packages ~arch is not enough and we need different process... But that a different topic. Bug I mentioned pretends that we have policy how to set version for packages that use backported upstream patches. My point is that there is no such policy and line between _p or -rN is very fuzzy to set such policy. Thus bug itself is INVALID... -- Peter.
