cvs commit: src Makefile.inc1 ObsoleteFiles.inc src/share/man/man7 build.7

John Baldwin jhb at FreeBSD.org
Wed Aug 3 11:59:53 GMT 2005


On Wednesday 03 August 2005 06:11 am, Alexander Leidinger wrote:
> "M. Warner Losh" <imp at bsdimp.com> wrote:
> > In message: <20050802140536.zstn68rcgsg84g0w at netchild.homeip.net>
> >
> >            Alexander Leidinger <netchild at FreeBSD.org> writes:
> > : When an user calls delete-old with DESTDIR set to the root of a
> > : non-native machine architecture he may remove non-obsolete files when
> > : he
> >
> > forgets to set
> >
> > : TARGET_ARCH. I want to prevent this situation. I think "failsafe" is
> > : more important than "POLA" in this case.
> >
> > If TARGET_ARCH is set, then the right set of files will be deleted if
> > you use TARGET_ARCH rather than MACHINE_ARCH.
>
> Yes. I'm not talking about technical problems. I talk about problems which
> sit on a chair. If we change MACHINE_ARCH to TARGET_ARCH and an user runs
> "make delete-old-libs" without setting TARGET_ARCH in a cross-arch
> environment, he will remove non-obsolete libs. And I think we should go the
> failsafe route.

This is UN*X, not Windows.  UN*X tends to allow a certain bit of foot-shooting 
to enable people to get useful things done.  It seems that since these 
targets have the same semantics as installworld they should follow the same 
policy.  A user can already blow their feet off in a much worse fashion by 
forgetting TARGET_ARCH when doing an installworld.  The fact that we don't 
have lots of complaints about that particular case now indicates that your 
fears are probably not well-founded.  If someone is doing cross-builds and 
cross-installs, I think we can expect them to be able to set TARGET_ARCH 
correctly for the delete-foo targets since they already have to be setting it 
correctly for buildworld, buildkernel, installworld, and installkernel.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the cvs-src mailing list