From owner-freebsd-stable Mon Mar 23 07:19:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA01250 for freebsd-stable-outgoing; Mon, 23 Mar 1998 07:19:01 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA01201 for ; Mon, 23 Mar 1998 07:18:54 -0800 (PST) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id HAA08026; Mon, 23 Mar 1998 07:18:49 -0800 (PST) Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by passer.osg.gov.bc.ca, id smtpdaactma; Mon Mar 23 07:18:41 1998 Received: (from uucp@localhost) by cwsys.cwsent.com (8.8.8/8.6.10) id HAA10493; Mon, 23 Mar 1998 07:18:37 -0800 (PST) Message-Id: <199803231518.HAA10493@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpd010486; Mon Mar 23 07:18:14 1998 X-Mailer: exmh version 2.0.1 12/23/97 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: cy To: gkshenaut@ucdavis.edu cc: stable@FreeBSD.ORG Subject: Re: Binary package updates, etc. In-reply-to: Your message of "Sun, 22 Mar 1998 22:57:12 PST." <199803230657.WAA10963@myrtle1.bogs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Mar 1998 07:18:13 -0800 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk > In message , "Dan iel O'Callaghan" cleopede: > > > >I think Derek is doing a great job! Congrats. However, I do also think > >that Cy Schubert made a very valid point that we need to identify what it > >is that is going to be updated using this package mechanism. > > > >If the pkg mechanism include feature enhancements to the system, then > >people may be reluctant to use it, lest they change somethin on > >which their system depends. Alex changed the size of the ipfw structure > >and created an incompatibility between ipfw(8) and ip_fw.[ch] last > >November/December. The result was that a kernel upgrade meant a > >userland upgrade for ipfw(8). This is likely to be a good reason many > >will shy away from enhancement packages. > > > >If the pkg mechanism is only for bug fixes, that's fine, until you need > >to produce a package for a bug fix in an enhancement. > > > >The only way to cater for both scenarios is to flag each package as > >either ENHANCEMENT or FIX, and make any FIX packages dependent on the > >ENHANCEMENT package. > > I think patches are very different from packages. Packages are > optional modules which can be added to a system; patches fix bugs > in the system. Packages are distributed with the CD-ROM; it would > make no sense for a patch to be distributed with a CD-ROM. It may > or may not be the case that a mechanism similar to that which is > currently being used for packages could be bent to implement patches, > but I can't see what this buys us. I don't think it really matters > very much how a particular patch is implemented--it should be up > to the developer. What we need to do is to specify the semantics > of a patch so that the patches can be distributed and applied with > a minimum of fuss. ... and backed out with a minimum of fuss... Sun basically uses their package software to manage patches. They take checksums (could be MD5 for our purposes) of each binary (could be done with source code patches too) and abort if the checksums don't match. If they have prerequisites, they bundle the prereqs and the patches themselves into a jumbo patch. This is a simpler approach and should work as well. The only problem with their approach is that their software tells me that something doesn't match. It doesn't tell me why it doesn't match. It doesn't matter what we do, packages, RPM's, Sun's approach, IBM's approach, or something that we've dreamed up. What does matter is that carefully choose something that works, and stick with it. You will also notice that the examples I gave, packages, RPM's, Sun's approach, and IBM's approach all manage the base software as a prerequisite. In order to make this work managing the base software using packages or whatever we decide to use is a requirement to doing this successfully. Managing patches is an all or nothing proposition. You either manage the whole system that way or you don't do it at all. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message