Hola y'all. This has been requested, and discussed before, but bringing it up again. Basically, portage releases (upstream, the actuall tarball naming) needs to drop the -r* version component.
Why? Because that component is used by the ebuild maintainer, so that you can have multiple revisions of an upstream version, fex, to include patches in the revision of the -upstream- release. Basically, an addition version component for ebuild maintainers to fool around with, yet the same pkg release. Portage releases happen, but so do bugs, and there isn't any reason why we -shouldn't- be able to revbump a portage release (in the tree) so we can include patches. To head of the "well, we'll just do a release with the fix", yeah, that may be, but going by past experiences, time between releases is somewhat variable, regardless of bugs. Or, you get emails to -core/-dev telling people to re-emerge an ebuild. Re: sticking the change into the existing revision in the tree, this is naughty, oh so naughty. Tree policy states that if an ebuild is changed such that the contents of what are installed are changed, the ebuild -must- be revbumped, with one exception- typically, package.mask'd ebuilds (the most unstable, of unstable ebuilds that are under active development). I posit portage, even if package.mask'd, should not use this exemption. Why? Because portage is a critical app, expecting users to notice a posting to -dev or -core to re-emerge portage is rather crappy QA imo. Mistakes happen, but I'd think it's -much- better to revbump the ebuild in the tree, such that any user who syncs (and had -r14 fex), would see, "oh, -r15 is available. time to merge it" rather then running across a posting to a list they may not even suscribe to, stating "re-emerge -r14 if you emerged it prior to xyz". Portage already can handle determining if a new version is available, there is no reason not to go this route. Offhand, if the glibc maintainers pulled the type of trickery involving changing the ebuild without revbumping it, they'd be stoned to death. Why is portage (the pkg that is pretty much equal in it's ability to screw things up) allowed to get away with this? So yeah, my two cents. At the time 2.0.51 as being conceived for release, I (and others) brought this up- the -r* release strategy stuck. I'm again pointing out the issues with it, and requesting the portage release version scheme be adjusted. At this point, it would involve having 4 version components- yes it's a pita, but that's the case atm for correcting it. Later releases could use a slightly saner major.minor release versioning, eg 2.1 instead of just building upon 2.0.x . Either way, I don't care as much about the versioning (major minor? major minor + extra component?) used, as long as it drops -r*, and the changing the ebuild w/out revbumping is stopped. Thoughts/Flames? ~brian -- [email protected] mailing list
