From owner-freebsd-bugs@FreeBSD.ORG Sun Mar 28 22:50:04 2010 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 517D7106564A for ; Sun, 28 Mar 2010 22:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2625A8FC19 for ; Sun, 28 Mar 2010 22:50:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o2SMo4jL083994 for ; Sun, 28 Mar 2010 22:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2SMo3TS083993; Sun, 28 Mar 2010 22:50:03 GMT (envelope-from gnats) Date: Sun, 28 Mar 2010 22:50:03 GMT Message-Id: <201003282250.o2SMo3TS083993@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Garrett Cooper Cc: Subject: Re: bin/145100: [patch] pkg_add(1) - remove hardcoded versioning data from add/main.c X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Garrett Cooper List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 22:50:04 -0000 The following reply was made to PR bin/145100; it has been noted by GNATS. From: Garrett Cooper To: Garrett Cooper Cc: bug-followup@freebsd.org, freebsd-bugs@freebsd.org, kensmith@freebsd.org Subject: Re: bin/145100: [patch] pkg_add(1) - remove hardcoded versioning data from add/main.c Date: Sun, 28 Mar 2010 15:42:47 -0700 On Sun, Mar 28, 2010 at 12:08 PM, Garrett Cooper wrot= e: > On Sun, Mar 28, 2010 at 12:07 PM, Garrett Cooper wr= ote: >> Hi Ken, >> >> On Sun, Mar 28, 2010 at 2:17 AM, Garrett Cooper wr= ote: >>> On Sun, Mar 28, 2010 at 2:13 AM, Garrett Cooper w= rote: >>>> On Sun, Mar 28, 2010 at 1:50 AM, =A0= 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 versionin= g data from add/main.c >>>>>>Arrival-Date: =A0 Sun Mar 28 08:50:02 UTC 2010 >>>> >>>> Supported hierarchies are done like: >>>> >>>> =A0 =A0//packages- >>>> >>>> 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 >>> #include >>> #include >>> >>> 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 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? One other thing that would be nice is that folks can now split up releases into multiple trains, say if they built package set A with a certain set of options, and package set B with a separate set of options. If I were to install package set B on a series of mips boards with Cavium support, they might not have the same set of requirements, or CFLAGS enabled that a mips port to qemu might have. Maybe a getenv check to $UNAME_r should be added s.t. this falls back to old behavior in the event of there not being a release defined in the environment? I'm still not sold on the fact that that would be the best solution because some degree of parsing needs to occur -- perhaps some sscanf fun with (struct utsname).release would be the the best way to go (scan for integers and the first period -- set the release accordingly) if $UNAME_r is undefined? Thanks, -Garrett