bin/145100: [patch] pkg_add(1) - remove hardcoded versioning data from add/main.c

[Ken Smith]

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

On 3/28/10 3:10 PM, Garrett Cooper wrote:
>     Here are some questions though:
>  
>  1. What happens if compat libraries are used with a specifically built
>  copy of pkg_install? Game over, right -- because the __FreeBSD_version
>  is encoded in the binary?

Under the current implementation yes, __FreeBSD_version will be
determined by what is seen at compile time.  So if pkg_install is
built on a different system or otherwise tricked into having a
value of __FreeBSD_version present at compile time that doesn't
truly match the system it's being run on you get strange results.
If that's the case I can't picture a case where it would not be
done intentionally so I'm guessing in this scenario that's a
feature(?).

>  2. Should prereleases really be allowed to use release-based packages?
>  Probably not right -- generally the functionality is fixed in each
>  release, but it can change dramatically before the official release is
>  made, correct (take the 7.0-RELEASE for example...)?

Packages to be used during the release cycle do get a bit weird.  At the
point I do the branching (e.g. create releng/7.3) we're typically at the
RC1 stage.  It's possible but not likely at that point we will have
packages-7.3-release available, but it is likely portmgr@ will have
used me doing the branch as the trigger to start their release package
builds.  How long it takes for packages-7.3-release to show up varies
among the architectures but it could be a matter of a few days for the
more popular architectures (amd64/i386) while more on the order of
weeks for the less popular architectures (sparc64).

The way things go during the current release cycles only the release
branches (releng/*) should try to get packages from packages-*-release,
and those are typically X.Y-RC1, X.Y-RC2, both when installed from
ISOs I build and when a user updates to the RELENG_X_Y branch using
csup/cvsup.

The branches that would typically be called -CURRENT should use
packages-*-current, while branches called -STABLE should use
packages-*-stable.

The branches called -BETA1, -BETA2, etc. are the worst to handle.
If we're talking about a release cycle for an X.0-RELEASE I do
commit the BETA names to newvers.sh because it doesn't freak out
users - they've been trained to think -BETA1 is an upgrade from
- -CURRENT... :-)  However for these releases it's still most
appropriate for packages to come from packages-X-current because
that will be all that's available.  But for X.Y-RELEASE cycles
where Y > 0 (X.1-RELEASE, X.2-RELEASE, etc) a user's machine
that gets installed from the ISOs I build will say it is
X.Y-BETA1 but if a user updates using csup/cvsup it will say
it is X.Y-PRERELEASE because of what I mentioned before.  In
the past when we committed X.Y-BETA1 to a stable/X source tree
we inevitably wound up with a couple messages to stable@ from
people who hadn't noticed we were in a release cycle and freaked
out over the word BETA appearing in a "stable branch"...  For
these releases of X.Y-RELEASE where Y > 0 both PRERELEASE and
BETAs should use packages-X-stable (which, for BETAs, is different
from what should be used for an X.0-RELEASE cycle).

>  3. What also happens if FreeBSD developer goes and messes up a package
>  before the release 7.2-RC2, but it was working in 7.2-RC1 -- the
>  individual will be toast right because they'll `automatically upgrade'
>  to the latest version and can't go back to the earlier version without
>  grabbing the CD, correct?

Correct but I'm not quite sure what that has to do with the current
thread - that event you describe happening has no correlation to
__FreeBSD_version or any other aspect of the baseline system's
version.  It's strictly an issue with the package which has its own
version scheme independent of the baseline system.  Though I might
be missing a point you're making regarding this.

Thanks.


- -- 
						Ken Smith
- - From there to here, from here to      |       kensmith at buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuwJ/kACgkQ/G14VSmup/ahtACfUS6Qlx7Wp9t4ShYUiaBs4xHn
8hAAn2nDrATvSb4zpvOVoIJ5Vf3b9HXM
=ZULg
-----END PGP SIGNATURE-----