svn commit: r361646 - in head/net/samba36: . files

[Vsevolod Stakhov]

On 15/07/14 18:05, Alexey Dokuchaev wrote:
> On Mon, Jul 14, 2014 at 11:56:10PM +0200, John Marino wrote:
>> On 7/14/2014 22:01, Timur I. Bakeyev wrote:
>>> You bumped PORTREVISION, although there wasn't any pkg list change - so
>>> all the users now have to recompile not so tiny samba36 just to fix
>>> shebang in one rarely used file.
>>
>> Kind of like being "almost" pregnant?
>> If the contents of the package changes *at all* you are supposed to
>> revbump, not just if the pkg-plist changes.  It's not a judgement call
>> -- if the file is important enough to be in the package, it's important
>> enough to bump when it changes.
> 
> Sorry, but I'm on Timur's side here: portrevs bumps are IMHO being abused
> way too often for little to no benefit.  I'm wasting huge deal of CPU cycles
> for countless rebuilding of perfectly fine packages just because folks tend
> to bump revs on even teeniest changes.
> 
> FWIW, having both "not a judgement call" and "important enough" in the same
> sensence looks like oxymoron to me.
> 
> ./danfe
> 

Let me explain the situation with pkg. Pkg needs to find so called
``upgrade chains'' that are used to upgrade packages. To find out
packages that are suitable for upgrade we use origins in pkg 1.2 and
name~origin in pkg 1.3.

However, each package is identified by a special field called
`manifestdigest'. In pkg 1.2, this field is just sha256(manifest).
Unfortunately, this means that if *any* field of a package is changed a
version bump is required. By fields I mean files and directories as well
which leads thus to a policy where we need to bump a revision even if we
have meaningless changes in the files a package provides (that happens
after this particular change).

With pkg 1.3 this behaviour has been changed to recognize the following
fields only:

*  name
*  origin
*  version
*  arch
*  maintainer
*  www
*  message
*  comment
*  options

Hence, I think that with the release 1.3 of pkg we should define
revision bump policy to reflect this change.

-- 
Vsevolod Stakhov