[blfs-support] Knowing when to ditch an old (desktop) system
list1 at michaelshell.org
Wed Dec 31 18:02:01 PST 2014
On Tue, 30 Dec 2014 16:02:13 -0800
William Tracy <afishionado at gmail.com> wrote:
> I actually wanted to take the concept a step further, and make it possible
> to install and use packages even if you don't trust the package author.
I'm all for this. It is a testimony to the integrity and vigilance of the
people of the open source community that we have not yet had a total
catastrophe given the way we normally install things. That old saying
about Unix being selective about who it makes friends with sometimes works
against us with respect wider adoption, but it also can help to keep out
some kinds of "braindead or malicious rift-raft" - because Linux users
themselves tend to be more thoughtful and selective about what they allow
to be installed. So, we aren't targeted as much as those who like to click
and install on every pretty web banner ad they see. Also, LFS users (and
those who install from source in general) tend to notice if something
strange is taking up CPU time or network resources.
Anyway, there are two contradictory ways to look at system organization:
1. Organize according to general system function type,
e.g., "/bin", "/etc".
2. Organize according to specific package,
The former is the way we traditionally do things in Unix and is very
efficient. It is perhaps the best way to go with the trusted core system
components, e.g., "LFS". The latter approach is better for separating
and compartmentalizing packages. However, that way will likely require
the use of a filename directory lookup cache (for bin, etc, man, lib, ..)
that will have to be rebuilt everytime a package is added or removed
(as is done with the TeX system). That system file name cache could
replace all the separate ones for lib, man(db), etc.
I would like it if we could choose which type of installation we want
when we compile the package. Also, "make install" (or maybe a new
"make export") would create the installation files under an ./install,
or ./export directory within the source tree. Then, we would use our
own copy tools, possibly even porg with a copy/install feature, to
complete the installation or package the files as we see fit. There
would also have to be a file that contained a list of recommended
permission settings for each file to be installed. Copying into the
core system tree (e.g., /bin, /boot) should require the use of a
special option (e.g., "-S") to be invoked. Also, the installer should
warn which, if any, existing files are going to be overwritten before
they actually are.
Finally, if porg et al. also made a copy of the installation of the
package in a directory of it's own e.g.,
This would allow us a means to easily change versions, remove or restore
packages at will, provide for a backup, etc. Although, of course, this
would come at the cost of some disk space.
If anyone undertakes any work in this regard, my own humble suggestion
would be to try to get the GNU folks onboard with it - if they start
using it, many more will follow.
Cheers and thanks for the info,
More information about the blfs-support