Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Jan 2015 17:20:48 -0800
From:      Garrett Cooper <yaneurabeya@gmail.com>
To:        Dmitry Marakasov <amdmi3@amdmi3.ru>
Cc:        freebsd-current@FreeBSD.org
Subject:   Re: OptionalObsoleteFiles.inc completeness improvement, try 2
Message-ID:  <8162C656-E851-492D-840A-27A222E3A7CC@gmail.com>
In-Reply-To: <20150124011610.GJ1101@hades.panopticon>
References:  <20150124002956.GI1101@hades.panopticon> <4F0C24D1-9313-49BC-992E-5C31DAC6DADC@gmail.com> <20150124011610.GJ1101@hades.panopticon>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_0CA27C11-562F-4509-8911-BA879DD8017C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On Jan 23, 2015, at 17:16, Dmitry Marakasov <amdmi3@amdmi3.ru> wrote:

> * Garrett Cooper (yaneurabeya@gmail.com) wrote:
>=20
>>> Some years ago I've started a project of improving
>>> OptionalObsoleteFiles.inc completeness, which allows make delete-old
>>> / delete-old-libs / delete-old-dirs targets completelty remove files
>>> which are normally installed when specific src.conf WITHOUT_* knobs
>>> are set.
>>>=20
>>> In other words, if a user has some WITHOUT_* set in src.conf,
>>> specific files are not installed by installworld, but not removed
>>> by remove-old, which I try to fix.
>>>=20
>>> In yet other words, I want to make it so `make installworld
>>> -DWITHOUT_foo=3Dyes` and `make installworld && make delete-old
>>> -DWITHOUT_foo=3Dyes` result in the very same file sets.
>>>=20
>>> Though the project seems to be useful and have real demand (added
>>> to IdeasPage by netchild@, though removed later by brooks@ [1])
>>> and interest ([2]), the change was ignored back then and now the
>>> patch is completely rotten. I can redo it, but I need a reviewer.
>>> Here's a first small part of the patch:
>>>=20
>>> https://reviews.freebsd.org/D1600
>>>=20
>>> The WIP branch with other changes is [3]
>>>=20
>>> Also there is a question of delete-old-dirs removing directories
>>> which are created by mtree run by installworld unconditionally.
>>> This seems to be incorrect - either directories should be installed
>>> conditionally or not removed by delete-old-dirs. My patch will
>>> address this issue as well, by not remiving unconditionally =
installed
>>> dirs.
>>>=20
>>> [1] =
https://wiki.freebsd.org/action/diff/IdeasPage?action=3Ddiff&rev1=3D260&re=
v2=3D261
>>> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D168341#c6
>>> [3] https://github.com/AMDmi3/freebsd/compare/obsolete-files
>>=20
>> Hi Dmitry,
>> 	Seems like we=92ve duplicated work a bit. Have you looked at =
^/projects/building-blocks yet ?
>=20
> Hm, seems so, partly. How do you gather missing entries? My way is
> pretty dumb, I just do bunch of installworlds + delete-old's and add
> diff to the file, you probably do it more cleverly. Will committing
> my changes interfere with your work? If so, it may be better to direct
> them to your branch instead. Especially if you are more aware of knob
> combinations and their effects.

I wrote this script to track what files get installed by directories:=20
=
https://svnweb.freebsd.org/base/projects/building-blocks/tools/add-optiona=
l-obsolete-files-entries.sh?revision=3D275238&view=3Dmarkup . It=92s not =
perfect (doesn=92t work for =93kitchen sink=94 directories like etc/ and =
share/=85), but it=92s a reasonable starting point for grabbing all of =
the files.

I=92m going to hold off on the rc.d deletions/rewrites for dependent =
services after I do more targeted review/testing, as it might screw up =
boot order in unexpected ways with services and programs that get run =
out of order, but I=92m reasonably confident that the contents of the =
branch work.

I was going to start cherry-picking changes from the branch this =
weekend.

Thanks!

--Apple-Mail=_0CA27C11-562F-4509-8911-BA879DD8017C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJUwvNwAAoJEMZr5QU6S73eWZwH/i2qFvTPQX3ziU0h2jQ2h3FZ
bjk3CDAYN1eL73lProxq75e+AAram7NlQUg6h6trGzPW+SDB1ajJLBTwIpkzMff5
lVrVFtGiishyRUic7kvYfGXkDpaEG8HsCrIRorEZ4C5L7UUNL5aZrtKS9WNYm4qS
H7sYel5apLZwBapshWzwkziWqQjTjCXNivsRbmpC3+rAOm9EJ/IPD/VASpd1LeW9
RLuLhACRpBujPDiCEgyru/IHycTSvdeWZ6dc63mk5nXn31uC8ATsBK9527RtBNMb
d80qmjDv19J/AQjh5ntOvHMxr0Sd2EJm/AMQgjZvQMxwqAyYTnqGEzl9nRuuW1U=
=wzWi
-----END PGP SIGNATURE-----

--Apple-Mail=_0CA27C11-562F-4509-8911-BA879DD8017C--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8162C656-E851-492D-840A-27A222E3A7CC>