Date: Sun, 28 Mar 2010 10:39:57 -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: <4BAF6A3D.8090505@buffalo.edu> In-Reply-To: <201003280920.o2S9K5qB064319@freefall.freebsd.org> References: <201003280920.o2S9K5qB064319@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 5:20 AM, Garrett Cooper wrote: > The following reply was made to PR bin/145100; it has been noted by GNATS. > > From: Garrett Cooper <gcooper@FreeBSD.org> > To: Garrett Cooper <gcooper@freebsd.org> > Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org > Subject: Re: bin/145100: [patch] pkg_add(1) - remove hardcoded versioning data > from add/main.c > Date: Sun, 28 Mar 2010 02:17:17 -0700 > > On Sun, Mar 28, 2010 at 2:13 AM, Garrett Cooper <gcooper@freebsd.org> wrote= > : > > On Sun, Mar 28, 2010 at 1:50 AM, =A0<FreeBSD-gnats-submit@freebsd.org> wr= > ote: > >> Thank you very much for your problem report. > >> It has the internal identification `bin/145100'. > >> The individual assigned to look at your > >> report is: freebsd-bugs. > >> > >> You can access the state of your problem report at any time > >> via this link: > >> > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D145100 > >> > >>>Category: =A0 =A0 =A0 bin > >>>Responsible: =A0 =A0freebsd-bugs > >>>Synopsis: =A0 =A0 =A0 [patch] pkg_add(1) - remove hardcoded versioning d= > ata from add/main.c > >>>Arrival-Date: =A0 Sun Mar 28 08:50:02 UTC 2010 > > > > Supported hierarchies are done like: > > > > =A0 =A0/<machine>/packages-<release-lowercase> > > > > Corrected with this diff. > > One other minor sidenote: this patch requires minor a basename(3) > addition to pkg_add(1) as described in bin/121165 . It's relatively > trivial to add, and only needs to be done for lib/lib.h and add/main.c > ; so either I can yank the diagnostic message, or add the minor change > to the diff -- whichever is more preferred. > Thanks, > -Garrett > _______________________________________________ > freebsd-bugs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" > > There are a couple of issues this patch doesn't seen to address. Here is an example of what's in the uname structure on a machine that's had two patches applied to it (SA/EN as published by the Security Team): bauer 11 % cat uname.c #include <stdio.h> #include <stdlib.h> #include <sys/utsname.h> int main(int argc, char *argv[]) { struct utsname un; if (uname(&un)) { perror("uname"); exit (1); } printf("sysname: %s\n", un.sysname); printf("nodename: %s\n", un.nodename); printf("release: %s\n", un.release); printf("version: %s\n", un.version); printf("machine: %s\n", un.machine); } bauer 12 % ./uname sysname: FreeBSD nodename: bauer.cse.buffalo.edu release: 8.0-RELEASE-p2 version: FreeBSD 8.0-RELEASE-p2 #0: Fri Mar 26 16:58:16 EDT 2010 root@bauer.cse.buffalo.edu:/usr/obj/usr/src/sys/FIREWALL machine: amd64 bauer 13 % So unless I'm mis-reading your patch it would be looking for packages in /ftp/pub/FreeBSD/ports/amd64/packages-8.0-release-p2 which doesn't exist. That problem isn't too hard to solve but the other problem is. There are times during release cycles that branches wind up with even weirder names than just tacking -p<something> on to the end of the name. For example during the 7.3 release cycle the stable/7 branch was named 7.3-PRERELEASE during the entire cycle. Once it got created the releng/7.3 branch was named 7.3-RC1, and progressed to 7.3-RC2. And take a look at what a system installed from one of the Monthly Snapshots gives for uname output, I don't have one handy at the moment but if I recall correctly it has the snapshot's name embedded in the uname output. The mechanism that does that is what I use to name the BETA releases as well, I never actually commit the BETA1, BETA2, etc. names to a stable branch because it tends to freak out people using those branches (we wind up getting mail saying "Hey, RELENG_7 is a stable branch! Why does a machine updated today on RELENG_7 say it's *BETA1*???") during release cycles; the PRERELEASE thing is an attempt to avoid that...). If you do a release build specifying BUILDNAME on the command line it will use that as what gets put into sys/conf/newvers.sh as the $RELEASE. And that's the source of what uname gives as the release field. - -- 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/ iEYEARECAAYFAkuvaj0ACgkQ/G14VSmup/YP7ACePwnKERnZfHQnSSHvroNVt3mw 2wEAn1MKU/tG/CAYRXhowJPUR9b7Ze1A =VBf8 -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BAF6A3D.8090505>