Date: Sun, 5 Dec 2010 15:26:43 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: bcr@FreeBSD.org Cc: doc-committers@FreeBSD.org, mexas@bristol.ac.uk, cvs-doc@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: doc/en_US.ISO8859-1/books/handbook/cutting-edge chapter.sgml Message-ID: <20101205152643.00002ae2@unknown> In-Reply-To: <4CFAB0F0.90501@FreeBSD.org> References: <201012041756.oB4HuFjD001878@repoman.freebsd.org> <20101204203805.00006179@unknown> <4CFAB0F0.90501@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 04 Dec 2010 22:21:52 +0100 Benedict Reuschling <bcr@FreeBSD.org> wrote: > Am 04.12.10 20:38, schrieb Alexander Leidinger: > > On Sat, 4 Dec 2010 17:56:15 +0000 (UTC) Benedict Reuschling > > <bcr@FreeBSD.org> wrote: > > Improvement suggestions: > > - While this is already covered in "implemented elsewhere": > > Changing the version number of a library can also be a > > reason. Strictly speaking this is "elsewhere", from another > > point of strict-view this is not elsewhere but in the the > > same library, just another version. > This is more precise than my (rather crude) description and should not > be too difficult to rewrite. > > > - There is not only the argument of storage space, but also > > security (if an old lib-version is used which may contain > > a security hole or not), and stability (old lib version > > may have a little bit different behavior, or may cause crashes > > if mixed with more recently compiled stuff which includes > > a reference to a more recent version of the same lib). This > > is mentioned at the end of the description, but IMHO it would > > be better to describe this in the beginning. > Same here. > > > - check-old includes check-old-libs, no need to run both. > I see. Is there any reason why someone would just run check-old-libs? > If so, perhaps we can add a little bit of information about that to > that section as well. If someone wants to keep some outdated files, but not outdated libs, and he only wants to see the outdated libs, this targetr could be useful. IMO this is a very small edge-cases. > > - I suggest to delete the files after a mergemaster was done, > > and not directly after the installworld. This way an outdated > > rc- script can not reference something which gets deleted. > I think this contradicts the description in /usr/src/UPDATING: > ... > mergemaster -p > make installworld > make delete-old > mergemaster > ... > > I used it like this in the past and never had a problem with it (to be > fair: I cowardly skip over the make delete-old-libs step each > time). :-) If we change this, then perhaps we also need to update the > description in /usr/src/UPDATING. I agree that it would be better placed after the 2nd mergemaster in UPDATING. > > - Running delete-old-libs blindly is not a good idea. Before > > the delete-old-libs there should be a check if something > > references those libs (e.g. with sysutils/libchk), and if > > yes, the ports/programs/libs should be recompiled before > > the delete-old-libs target is executed. It is mentioned > > at the end that you shouldn't remove files/libs which > > are still used, but IMHO it would be better to mention > > it before telling to do delete-old(-libs). > This is true and also a crucial/dangerous step in the process. Moving > the section from the end closer to where you suggested it should be > relatively easy. > > > - BATCH_DELETE_OLD_FILES does not need to be an env-var, > > as a make-var it works too: > > "make -DBATCH_DELETE_OLD_LIBS delete-old" > I see, this can also be fixed quite fast. > > > - As portmaster is mentioned, I suggest to mention portupgrade > > too. > What would be the exact invocation of portupgrade? Rebuild all > installed ports or just the ones that are affected by that lib? The same as for portmaster, rebuild what references the old lib (in dependency order). Bye, Alexander.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101205152643.00002ae2>