Post by Bill Evanshttps://i.imgur.com/VJdZyV9.png
If I just mark "lazarus" for complete removal, the others are NOT highlighted to be removed as well. Therefore, should I also be marking "lazarus-2.2", "lazarus-ide-gtk2", etc... basically everything with "lazarus" in the name here, or ? Also, I understand "fpc" was also installed at the same time (according to https://ubuntuhandbook.org/index.php/2021/11/install-lazarus-ide-ubuntu/). Should I do a complete removal by marking "fpc-source-3.2.2"? What about the "lcl-2.2" and others?
https://i.imgur.com/QdXNgH9.png
At least "git" is much simpler with only a single entry to remove. It also does NOT appear as Lazarus does in the Software center.
git clone https://github.com/ok2cqr/cqrlog.git
cd cqrlog
make
sudo make install
After the steps from git clone to sudo make install were done, CQRlog then appeared in my programs. Of course, when I tried to open, I get the messages about more files needed and that's when I decided to not use it. It appears in my programs list as well as the Software Center with the uninstall option.
I'm a bit lost when you begin discussing the build commands, which is why I repeated them here. Where is the Makefile located? In the CQRlog directory?
"And you MUST complete your tree-cleaning, before doing the next step.
If you did the next step first, then it would no longer be
possible to do "sudo make remove" or similar. You remove the
side-effects of your work, before cleaning up the scene of
the crime."
Sorry, I don't follow. How do I complete the "tree-cleaning" and such?
Since CQRlog is showing in the Software Center with uninstall option, might it be simpler to just uninstall it from there? As a side note, interestingly, although CQRlog shows up in Synaptic, it does not show as installed even though it does in the Software Center.
When you select "lazarus" as a metapackage, it seems to have selected elements
of the latest version for inclusion in the install.
By selecting lazarus for removal, in principle at least, it should be
removing the 2.2 version items install. If it did not, you could use the
search to list all lazarus instances, and manually remove the subpackages
if any remained installed.
When the boxes are empty, the files are not on the machine (fresh install).
The listing is a list of things the Repository has. When the boxes are
filled ("ticked"), like in the 2.2 version items, then at some point the
files were downloaded and installed. When you do the remove, the files
should be removed from active participation in your tree. OSes always have
caching mechanisms, and if you were tight for space, it might be a
significant effort to remove them all. Perhaps "complete removal"
ensures that any .deb files still on the machine and related to that,
are removed.
There are also commands for the package manager, that notice dependencies
that don't have a master program, and those can be removed automatically.
Sometimes on a Software Update, you will notice an effort is being
made to consolidate the contents of the tree, so only "wired together stuff"
is kept.
But for the time being, I interpret your request as "how do I prevent what
I've done from interfering with normal day to day operation". I have
not gone the extra mile to "make my slash as small as possible". That's
out of my pay scale. Don't know how to do it. Would take hours and
hours of research. I've used several OSes where I don't know how to
do that, comprehensively and with confidence. That's "work" as it were.
I do clean out browser caches, because at least I could find those.
*******
During your build, if you do
sudo make install
then that puts items in /usr/bin or /usr/lib or the like. To prevent
interference with day to day operation, maybe you would want to remove
/usr/bin/CQRlog executable.
If you go back to the build directory and run
sudo make -n install
and do a dry run, the trace in the window will give you some idea
where it has stored its stuff. You could manually go into the tree
and remove the items. But I don't recommend doing that unless you're
good at that sort of forensics.
Executing sudo make -n install does not always run to completion.
The command can fail at some point, because it's not really installing
stuff, and some order-of-execution issue might affect its ability to
complete. I use commands like that (without EVER installing the package),
to see what the build tools think the important items are. Like whether
it installs libraries or not.
Makefiles can be in each subfolder of the build tree. Each subfolder
needs to be told what to do when make sees "source.c" and that it
should be compiled to "source.o". The template at the top level,
such as Makefile.in , it can inform the ./configure run, how
to build a custom Makefile in each subfolder. Using ./configure,
is one way to have the build tree make custom Makefile items.
Before ./configure came along, the Makefile was static and the
build was "one flavor only". You wouldn't even need a template, if
there was only one way to use the build tree, so each subfolder
would have a pre-made Makefile.
But you would normally be CDed to the top level of the build, when
you did the build or when you did the install. By being at the
top of the build tree, all of the install materials from
all of the subfolders, are considered. And the Makefile
will have an "install: " target followed by a list of
module names, like "source.so.2" shared library.
Make is not the only build tool. There is CMAKE, Ninja, I don't
think I can do a credible job of listing all of them. I don't like
all of them equally, because some are a rat bastard to get working,
as if the developer just doesn't care.
Adobe released a CMAKE one once, where they failed to integrate the
"demo app" into the tree, and it took me *one week* of work to fix that.
Then I discover the "demo app" is utter crap. And that really
explains it all -- no end-user got as close as I did, because
the build tree was broken. I did the extra work to discover
the developer of it... was a "munchkin" :-\ But that's how it
goes when you compile from source. That's part of the terrain.
I've also acquired FOSS tarballs, where one file is missing
on purpose, because the individual "wanted free storage for
their executable", but did not want people compiling from
source. I've had a variety of experience with this stuff,
and there are more than a few scumbags out there.
*******
Leaving library items behind is only an issue if it interferes
with some other, later project. I would put in an effort to
see they are removed. Maybe they can be spotted by their
datestamp, and a simple listing in time order, will identify them.
Paul
