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

[Garrett Cooper]

On Sun, Mar 28, 2010 at 12:08 PM, Garrett Cooper <gcooper at freebsd.org> wrote:
> On Sun, Mar 28, 2010 at 12:07 PM, Garrett Cooper <gcooper at freebsd.org> wrote:
>> Hi Ken,
>>
>> On Sun, Mar 28, 2010 at 2:17 AM, Garrett Cooper <gcooper at freebsd.org> wrote:
>>> On Sun, Mar 28, 2010 at 2:13 AM, Garrett Cooper <gcooper at freebsd.org> wrote:
>>>> On Sun, Mar 28, 2010 at 1:50 AM,  <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=145100
>>>>>
>>>>>>Category:       bin
>>>>>>Responsible:    freebsd-bugs
>>>>>>Synopsis:       [patch] pkg_add(1) - remove hardcoded versioning data from add/main.c
>>>>>>Arrival-Date:   Sun Mar 28 08:50:02 UTC 2010
>>>>
>>>> Supported hierarchies are done like:
>>>>
>>>>    /<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.
>
> ----
>
>>> 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 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
>>>
>>>  /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.
>>
>>    Ouch. 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.
>>
>>    Here 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