Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Peter Volkov <pva@gentoo.org>]

В Сбт, 14/08/2010 в 20:06 +0300, Markos Chandras пишет:
> On Sat, Aug 14, 2010 at 06:26:36PM +0200, Thilo Bangert wrote:
> > > So you want me to force everyone to update the package just to respect
> > > the LDFLAGS.
> > 
> > yes. IIRC it has been stated on this list before, that a change which 
> > changes the resulting binary always needs to be done in a revbump. 
> List? Really? I use devmanual for ebuild development not list archives.

Heh, devmanual is second source of information and first is good old
official documentation. Take a look at our "Ebuild policy":

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1

Now let me read it:


"Versioning and revision bumps"

"Package revision numbers should be incremented by Gentoo Linux
developers when the ebuild has changed to the point where users would
want to upgrade."

This general and a unclear sentence. Below it is explained quite well:

"Typically, this is the case when fixes are made to an ebuild that
affect the resultant installed files, but the ebuild uses the same
source tarball as the previous release."

For this this clear: if installed files changed do bump revision. And to
make this more clear later text discusses cases when no revbump
required:

"If you make an internal, stylistic change to the ebuild that does not
change any of the installed files, then there is no need to bump the
revision number. Likewise, if you fix a compilation problem in the
ebuild that was affecting some users, there is no need to bump the
revision number, since those for whom it worked perfectly would see no
benefit in installing a new revision, and those who experienced the
problem do not have the package installed (since compilation failed) and
thus have no need for the new revision number to force an upgrade."

Clear, right? And some exceptions, people mentioned in this tread:

"A revision bump is also not necessary if a minority of users will be
affected and the package has a nontrivial average compilation time; use
your best judgement in these circumstances."


Yes, we need to merge two piecies of information. But at the moment
we'll have to use both and in case devmanual has something unclear try
to look at other documentation. So, please, do revbumps for all changes
that affect installed files. ~arch is _supposed_ to be fast moving
target and for ~arch it's ok to rebuild package just for small fix. In
case users want something more stable that should use stable...

-- 
Peter.