Date: Sun, 28 Mar 2010 12:08:07 -0700 From: Garrett Cooper <gcooper@FreeBSD.org> To: Garrett Cooper <gcooper@freebsd.org> Cc: freebsd-bugs@freebsd.org, kensmith@freebsd.org, bug-followup@freebsd.org Subject: Re: bin/145100: [patch] pkg_add(1) - remove hardcoded versioning data from add/main.c Message-ID: <364299f41003281208i52b30a80k142efd19c6d070e0@mail.gmail.com> In-Reply-To: <364299f41003281207o3fb924cdyc84bb24321b82566@mail.gmail.com> References: <201003280844.o2S8ihqt007800@www.freebsd.org> <201003280850.o2S8o2v6038902@freefall.freebsd.org> <364299f41003280213x6f67ef45peb891f73fb4d140f@mail.gmail.com> <364299f41003280217x68c07210lac03230038d22b9f@mail.gmail.com> <364299f41003281207o3fb924cdyc84bb24321b82566@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 28, 2010 at 12:07 PM, Garrett Cooper <gcooper@freebsd.org> wrot= e: > Hi Ken, > > On Sun, Mar 28, 2010 at 2:17 AM, Garrett Cooper <gcooper@freebsd.org> wro= te: >> On Sun, Mar 28, 2010 at 2:13 AM, Garrett Cooper <gcooper@freebsd.org> wr= ote: >>> On Sun, Mar 28, 2010 at 1:50 AM, =A0<FreeBSD-gnats-submit@freebsd.org> = wrote: >>>> 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= data 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. >> >> =A0 =A0One 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. ---- >> 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[]) >> { >> =A0 =A0 =A0 =A0struct utsname un; >> >> =A0 =A0 =A0 =A0if (uname(&un)) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0perror("uname"); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0exit (1); >> =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 =A0printf("sysname: %s\n", un.sysname); >> =A0 =A0 =A0 =A0printf("nodename: %s\n", un.nodename); >> =A0 =A0 =A0 =A0printf("release: %s\n", un.release); >> =A0 =A0 =A0 =A0printf("version: %s\n", un.version); >> =A0 =A0 =A0 =A0printf("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 >> >> =A0/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. =A0For example during the 7.3 release cycle >> the stable/7 branch was named 7.3-PRERELEASE during the entire >> cycle. =A0Once it got created the releng/7.3 branch was named >> 7.3-RC1, and progressed to 7.3-RC2. =A0And 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. =A0The 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! =A0Why does >> a machine updated today on RELENG_7 say it's *BETA1*???") >> during release cycles; the PRERELEASE thing is an attempt >> to avoid that...). =A0If 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. =A0And that's >> the source of what uname gives as the release field. > > =A0 =A0Ouch. You pointed out a flaw in my assumptions that would > definitely invalidate this proposed change. Now I'm teetering between > whether or not it's wise to actually make this change. > > =A0 =A0Here 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? > 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...)? > 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? Forgot to actually CC ken :/... -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?364299f41003281208i52b30a80k142efd19c6d070e0>