From owner-freebsd-bugs@FreeBSD.ORG Sun Mar 28 19:07:08 2010 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D570106567C; Sun, 28 Mar 2010 19:07:08 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.223.171]) by mx1.freebsd.org (Postfix) with ESMTP id 317E28FC2F; Sun, 28 Mar 2010 19:07:07 +0000 (UTC) Received: by iwn1 with SMTP id 1so6851601iwn.27 for ; Sun, 28 Mar 2010 12:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=9Qx5Fh/cx5fFl5btVlcehlJGVioA0WRJ2qy0rWgNRrg=; b=SBfvukH1FHSpddNv8HQMSTQIqLP/fXlzKqEQtI11VIR/Ol2MBJsiA8bUasRURgi8UG m048rfX5zfaEE7+3kmu+5H5DaZZzphOorzrjjndWZVD1e8jRBLU5sLeWB9DKNNplIQ6z xOd1heLN1v7ppTsTMFtHirMwuRDLRN3JQh9vM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Q9CtIqbIt9Ufqmfk5rn0NhA0qYOLi4GarPE3CDNnr/B+WZXnU8DcD5iV7gBHAiCin2 3488SzE4vEAD7GjyZS4LV29S3PW/X4hihz8yNPtmIhhD4sRbrTYbJQoTZBPfnnfOlHcC xrh1NI+vaRRBYUGiap92R8h5f5RGvik0qq978= MIME-Version: 1.0 Sender: yanegomi@gmail.com Received: by 10.231.173.195 with HTTP; Sun, 28 Mar 2010 12:07:07 -0700 (PDT) In-Reply-To: <364299f41003280217x68c07210lac03230038d22b9f@mail.gmail.com> References: <201003280844.o2S8ihqt007800@www.freebsd.org> <201003280850.o2S8o2v6038902@freefall.freebsd.org> <364299f41003280213x6f67ef45peb891f73fb4d140f@mail.gmail.com> <364299f41003280217x68c07210lac03230038d22b9f@mail.gmail.com> Date: Sun, 28 Mar 2010 12:07:07 -0700 X-Google-Sender-Auth: 0fd16dc3058e78ba Received: by 10.231.150.74 with SMTP id x10mr2009515ibv.97.1269803227354; Sun, 28 Mar 2010 12:07:07 -0700 (PDT) Message-ID: <364299f41003281207o3fb924cdyc84bb24321b82566@mail.gmail.com> From: Garrett Cooper To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-bugs@freebsd.org, bug-followup@freebsd.org 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 List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 19:07:08 -0000 Hi Ken, On Sun, Mar 28, 2010 at 2:17 AM, Garrett Cooper wrote= : > On Sun, Mar 28, 2010 at 2:13 AM, Garrett Cooper wro= te: >> On Sun, Mar 28, 2010 at 1:50 AM, =A0 w= rote: >>> 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//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[]) > { > 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@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 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? Thanks, -Garrett