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

[Benjamin Kaduk]

On Wed, 16 Jul 2014, Alexey Dokuchaev wrote:

> [ CC list trimmed; bjk@ added (see below) ]
>
> On Tue, Jul 15, 2014 at 06:14:55PM +0100, Vsevolod Stakhov wrote:
>> 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.
>
> I've recalled that bjk@ mentioned once that he was giving a talk about some
> interesting features of Debian packaging at the ports devsummit at BSDCan.
> Maybe we can learn a thing or two from those guys?  Ben, can you share your
> opinion on Vsevolod's proposal (you might want to see other messages in the
> thread first)?  Thanks.


I do not think that Alexey would like the Debian way ;)

The *only* things that are officially part of Debian are packages.  This 
includes both the binary packages containing the actual compiled software, 
and source packages, which contain the exact sources used to build the 
software.  The packaging files, patches, etc., are included in the source 
package, but any use of version control to maintain them is up to the 
individual package maintainer -- there is no official authoritative Debian 
repository for them. [1]  (The Debian project does provide hosting that 
many people use, but it is not official.)  Package maintainers upload 
pgp-signed source packages to the master FTP site (along with a single 
binary package for one architecture to prove it builds), the signatures 
are verified, and then a set of build daemons goes off to build the binary 
packages for all other architectures.  End users only ever interact with 
binary packages, and pretty much the only people building things from 
source are the maintainers of the package in question.

Because of the way the distribution process works (maintainer uploads a 
signed package, official builds are made from that source package, the 
checksums of the resulting binary packages are placed in a signed manifest 
that is fetched by end users' clients), literally any change in the binary 
package requires a new version number, as otherwise the signatures would 
be invalidated and the new package would not be installable via the normal 
channels.

Trying to transition this logic to the FreeBSD universe, where we do 
maintain an official source code repository for the packaging, the 
conclusion would be only change that should trigger a package rebuild 
should get a version bump.  This is different from saying that any change 
which causes a difference in the binary package requires a version bump, 
since there are some changes which are not urgent and for which there is 
no real benefit of immediately starting to distribute them to users.

I am inclined to agree with the suggestion elsewhere in the thread that 
changes to maintainer, www, message, and comment need not immediately 
trigger distribution of the update to users (and if change to those fields 
should trigger immediate distribution of updates to users, the maintainer 
is responsible for incrementing the version number).  That is just using 
the current list (quoted above) as a starting point.  I don't know if 
there are other fields which might be considered for triggering mandatory 
version increments, but it seems a little unlikely since none have come up 
yet.


-Ben

[1] One could say that the actual Debian package repository constitutes a 
version control system, with the version numbers being the package version 
numbers, and one can retrieve the packaging at a given revision by 
extracting that source package.  All the packages' checksums are signed, 
so if the signatures and the packages themselves are kept around 
indefinitely, all revisions are retrievable.  But it seems rather 
ridiculous to claim that this is a usable VCS.