Re: CVS commit: src/distrib/sets

[Jim Wise <jwise%draga.com@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 13 Jun 2003, Alistair Crooks wrote:

>On Thu, Jun 12, 2003 at 08:34:49PM -0400, Jim Wise wrote:
>> Is there a reason the ability to explicitly version system packages was
>> discarded?  Previously, a system package on a release branch was
>> versioned with the current OS version of the branch, plus a `tiny'
>> version number of the syspkg, such as
>>
>>      base-util-bin-1.6.0.0
>>
>> for the version of that package that shipped with 1.6.0, and
>>
>>      base-util-bin-1.6.0.1
>>
>> for a hypothetical first `relevant' update to that package (such as when
>> an SA was issued for a binary in the package).  This allows tracking of
>> `important' changes in such a syspkg, much like the `nbXX' version
>> add-ons in pkgsrc.
>
>The old versions don't work at all well on -current, and anything
>which discourages people from running the -current branch should be
>discouraged, IMO.
>
>The old versions numbers were coming out as 1.6T-0. This is too
>large a granularity, and are not at all friendly.

I guess I don't buy this -- the version numbers are consistent, add a
single piece of information to the version number we _already_ use for
the release, and increase monotonically.

>The date-based versioning has worked fine for us in pkgsrc - that's
>how the versions required are all calculated and used.

Which is well and good, but the version in pkgsrc is taken from a set
date _in the source code_, and is depended upon at that granularity.

As far as I can tell, with regpkg as currently committed, if I compile
_identical_ code on two different dates, I get different version
numbers.  Plus which, is a pkg versioned 20030614 built from the branch
`newer' or older than one with the same version number built from
- -current?

More damningly, if i compile newer code and then compile older code, the
older code gets a newer version number.  This, obviously, makes it
infeasible to include `affected' syspkg versions in SAs.

In contrast, the system which was discussed on the mailing lists,
documented, implemented, and committed previously, provides a constant
version number for constant code, provides correct ordering for newer
and older code, and gives us control over the granularity we want for
syspkg version numbers.

Given that this was the version discussed on the lists, and this change
was made without (as far as I can tell) _any_ discussion, I am going to
go ahead and commit this change, which restores a specific and
documented functionality removed by your commit.

I'm sorry we disagree about this, but if we're going to toss out a
capability which is already there, that _needs_ to be discussed on the
lists.


>> regpkg and regpkgset are very nice, and address a very real
>> maintainability issue with the old code.  _But_ I think this feature
>> should not be lost.
>>
>> Barring any objections, I'll put something together to re-add this
>> functionality, and either commit it, or mail it off to you.
>>
>> Sound good?
>
>No, please see my previous reasons.

As I said, given that the commit which was done without discussion and
throws out functionality which was already there, I'm going to commit
the proposed change until such time as we can reach consensus on the
lists that this functionality needs to be removed.

- -- 
                                Jim Wise
                                jwise%draga.com@localhost
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (NetBSD)

iD8DBQE+6TXqlGcH240chEIRAnvxAJ4vb8Pe9QcHgdTWV5AAempHdqlQRwCgwRbM
5ZtmiFHYD3rBNP0VP58PhnA=
=kiHZ
-----END PGP SIGNATURE-----