updating without ldap and mdns

[Sarton O'Brien-2]

I've recently started building CURRENT with the mk.conf options:

MKLDAP=no
MKATF=no
MKISCSI=no
MKMDNS=no

And was wondering what the best way is to cull the left over files from
the filesystem. Is there some automated way that does a destdir
comparison or other?

TIA,

Sarton

[Alistair Crooks]

On Wed, Oct 28, 2009 at 04:51:21PM +1100, Sarton O'Brien wrote:

> I've recently started building CURRENT with the mk.conf options:
>
> MKLDAP=no
> MKATF=no
> MKISCSI=no
> MKMDNS=no
>
> And was wondering what the best way is to cull the left over files from
> the filesystem. Is there some automated way that does a destdir
> comparison or other?

If you started a "from-scratch" build, I'm unsure what the "left over"
files are - please file a PR for the files if this is the case.

If you modified build options and then did an update build, well,
you'll run into a number of problems, I should think.

HTH,
Alistair

[Steven Bellovin]

On Oct 28, 2009, at 9:42 AM, Alistair Crooks wrote:

> On Wed, Oct 28, 2009 at 04:51:21PM +1100, Sarton O'Brien wrote:
>> I've recently started building CURRENT with the mk.conf options:
>>
>> MKLDAP=no
>> MKATF=no
>> MKISCSI=no
>> MKMDNS=no
>>
>> And was wondering what the best way is to cull the left over files  
>> from
>> the filesystem. Is there some automated way that does a destdir
>> comparison or other?
>
> If you started a "from-scratch" build, I'm unsure what the "left over"
> files are - please file a PR for the files if this is the case.
>
> If you modified build options and then did an update build, well,
> you'll run into a number of problems, I should think.
>

I assumed the question referred to the target system after  
installation, not the build images.

                --Steve Bellovin, http://www.cs.columbia.edu/~smb

[Sarton O'Brien-2]

On 29/10/2009 12:46 AM, Steven Bellovin wrote:

>
> On Oct 28, 2009, at 9:42 AM, Alistair Crooks wrote:
>
>> On Wed, Oct 28, 2009 at 04:51:21PM +1100, Sarton O'Brien wrote:
>>> I've recently started building CURRENT with the mk.conf options:
>>>
>>> MKLDAP=no
>>> MKATF=no
>>> MKISCSI=no
>>> MKMDNS=no
>>>
>>> And was wondering what the best way is to cull the left over files from
>>> the filesystem. Is there some automated way that does a destdir
>>> comparison or other?
>>
>> If you started a "from-scratch" build, I'm unsure what the "left over"
>> files are - please file a PR for the files if this is the case.
>>
>> If you modified build options and then did an update build, well,
>> you'll run into a number of problems, I should think.
>>
> I assumed the question referred to the target system after installation,
> not the build images.

Exactly :)

The part where I mentioned a comparison with destdir seems to have been
snipped which now makes this message rather out of context.

To clarify, I'll restate:

After a 'build.sh install=/', having built with the options mentioned
above, is there a way to cull the remaining files in the _target_
filesystem that remain from a previous installation that occurred
without the options mentioned above?

Well that was a mouthful.

I'd like them to be considered obsolete but I really don't know how that
part of postinstall works at all.

I could have used the flist error when building but only thought of that
after the fact.

Sarton

[Sarton O'Brien-2]

On 29/10/2009 12:42 AM, Alistair Crooks wrote:
> If you modified build options and then did an update build, well,
> you'll run into a number of problems, I should think.

Really? From what I have witnessed, at the end of the build there is an
flist error and the unneeded files are listed but that's it.

 From what I can see, the options merely exclude components from the
build, is there something fundamentally integrated that I should be
aware of with regards to the options I listed?

I've done two builds on two separate machines, one update and the other
'from-scratch' with no discernible difference. In both cases the target
filesystem still ends up with more files than needed which could
potentially cause me some package grief down the track, which is my
primary concern.

Sarton