Date: Mon, 29 Mar 2010 00:09:29 -0400 From: Ken Smith <kensmith@buffalo.edu> To: freebsd-bugs@freebsd.org Subject: Re: bin/145100: [patch] pkg_add(1) - remove hardcoded versioning data from add/main.c Message-ID: <4BB027F9.5060402@buffalo.edu> In-Reply-To: <201003281910.o2SJACE3090460@freefall.freebsd.org> References: <201003281910.o2SJACE3090460@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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@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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BB027F9.5060402>