Date: Mon, 23 Mar 1998 07:18:13 -0800 From: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca> To: gkshenaut@ucdavis.edu Cc: stable@FreeBSD.ORG Subject: Re: Binary package updates, etc. Message-ID: <199803231518.HAA10493@cwsys.cwsent.com> In-Reply-To: Your message of "Sun, 22 Mar 1998 22:57:12 PST." <199803230657.WAA10963@myrtle1.bogs.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> In message <Pine.BSF.3.91.980323172519.300J-100000@panda.hilink.com.au>, "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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803231518.HAA10493>