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

Ken Smith kensmith at
Sun Mar 28 14:46:02 UTC 2010

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 at>
> To: Garrett Cooper <gcooper at>
> Cc: FreeBSD-gnats-submit at, freebsd-bugs at
> 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 at> wrote=
>  :
>  > On Sun, Mar 28, 2010 at 1:50 AM, =A0<FreeBSD-gnats-submit at> 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:
>  >>
>  >>
>  >>
>  >>>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 at mailing list
> To unsubscribe, send any mail to "freebsd-bugs-unsubscribe at"

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>

main(int argc, char *argv[])
        struct utsname un;

        if (uname(&un)) {
                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
release: 8.0-RELEASE-p2
version: FreeBSD 8.0-RELEASE-p2 #0: Fri Mar 26 16:58:16 EDT 2010
root at
machine: amd64
bauer 13 %

So unless I'm mis-reading your patch it would be looking for
packages in


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/ 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 at
  there, funny things are everywhere.   |
                      - Theodore Geisel |
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla -


More information about the freebsd-bugs mailing list