X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C861FA.66D190D9@onstor-exch02.onstor.net>; Mon, 28 Jan 2008 15:09:07 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: Review request
Date: Mon, 28 Jan 2008 15:09:07 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E056C9320@onstor-exch02.onstor.net>
In-Reply-To: <20080128135634.3e3da5a2@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Review request
Thread-Index: Achh+KVYZgqrU//HT6GRdXJnvwJADAAAQLiA
From: "Larry Scheer" <larry.scheer@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>
Cc: "Tim Gardner" <tim.gardner@onstor.com>

Either we do it at the time the bom file gets created or at install
time. I would still use the descr file to facilitate this functionality.
I would use the ignore tag to pull the files out of the bom and the
services and config tags at install time. How does that sound?

-----Original Message-----
From: Andy Sharp=20
Sent: Monday, January 28, 2008 1:57 PM
To: Larry Scheer
Cc: Tim Gardner
Subject: Re: Review request

On Mon, 28 Jan 2008 13:45:13 -0800 "Larry Scheer"
<larry.scheer@onstor.com> wrote:

> Why is it needed? It is needed mainly to deal with the links to
> /bin/lsmod.modutils. I asked you about this in a previous email. Those
> links were placed in the file system and I don't know by what
> packages. It is also needed to deal with minor differences between
> developers and production root file systems such
> as /etc/rc0.d/K19autofs. I moved my autofs scripts
> to /etc/rc[S0-6].d/[KS]22autofs so /homes and /n would get mounted
> correctly.

Can't we just suck those names out of the bom then?

> -----Original Message-----
> From: Andy Sharp=20
> Sent: Monday, January 28, 2008 1:12 PM
> To: Larry Scheer
> Cc: Tim Gardner
> Subject: Re: Review request
>=20
> On Mon, 28 Jan 2008 13:08:11 -0800 "Larry Scheer"
> <larry.scheer@onstor.com> wrote:
>=20
> > Tim, Andy,
> >     I will be using the descr file with system upgrade to identify
> > files that upgrade doesn't need to replace. This file was used in
> > the BSD upgrade for this purpose and I am porting that
> > functionality to cougar and bobcat Linux. How this file was used in
> > the BSD release was any file tagged as services or config was not
> > upgraded unless the file didn't exist on the disk in this case it
> > was installed if it was missing. In Linux I added a tag called
> > ignore which means if the file doesn't exist don't install it.=20
>=20
> Uh, why would such a thing be needed?  If it's never to be installed,
> it shouldn't be on the upgrade list or in the tarball, ja?
>=20
> > If you can think of any config files I might have left out, let me
> > know
> >=20
> > My workspace /home/larrys/perforce/trees/dev  is local to
> > linux-compile (10.0.0.143) and is mounted on ripper.
> > This p4 client is larrys-r14-dmip
> >=20
> > Thanks,
> >=20
> > Larry
> >    =20
> >=20
> > Change 27484 by larrys@larrys-r14-dmip on 2008/01/28 07:30:05
> > *pending*
> >=20
> >         The mysterious descr file is used by system upgrade to
> > prevent replacing
> >         system configuration and other files during the software
> > upgrade process.=20
> >         This change renames descr to descr-ch (for cheetah) and adds
> > the Linux
> >         platform versions (cougar and bobcat.) By adding the product
> > variant
> >         to the file name a make rule using descr-$(PROD) can put
> > this file
> >         in the appropriate release directory. This file ends up on
> > the NAS
> >         Gateway as /onstor/etc/descr.
> >         Reviewed by: TimG, AndyS
> >=20
> > Affected files ...
> >=20
> > ... //depot/dev/descr#3 delete
> > ... //depot/dev/descr-bl#1 add
> > ... //depot/dev/descr-cg#1 add
> > ... //depot/dev/descr-ch#1 branch
