bin/145100: [patch] pkg_add(1) - remove hardcoded versioning data from add/main.c

[Garrett Cooper]

The following reply was made to PR bin/145100; it has been noted by GNATS.

From: Garrett Cooper <gcooper at FreeBSD.org>
To: Garrett Cooper <gcooper at freebsd.org>
Cc: bug-followup at freebsd.org, freebsd-bugs at freebsd.org, kensmith at 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 <gcooper at freebsd.org> wrot=
 e:
 > On Sun, Mar 28, 2010 at 12:07 PM, Garrett Cooper <gcooper at freebsd.org> wr=
 ote:
 >> Hi Ken,
 >>
 >> On Sun, Mar 28, 2010 at 2:17 AM, Garrett Cooper <gcooper at freebsd.org> wr=
 ote:
 >>> On Sun, Mar 28, 2010 at 2:13 AM, Garrett Cooper <gcooper at freebsd.org> w=
 rote:
 >>>> On Sun, Mar 28, 2010 at 1:50 AM, =A0<FreeBSD-gnats-submit at 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 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/<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 at 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?
 
 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