bin/145100: [patch] pkg_add(1) - remove hardcoded versioning
data from add/main.c
kensmith at buffalo.edu
Mon Mar 29 04:15:03 UTC 2010
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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
The branches that would typically be called -CURRENT should use
packages-*-current, while branches called -STABLE should use
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.
- - 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/
-----END PGP SIGNATURE-----
More information about the freebsd-bugs