I use meld to diff two css files that are quite long, looking for changes.
I got the author to fix a bug in the line number display.
The fixed program is not in the repository of Mint 21.1 so I downloaded the tar.gz file from gitlab and in it there is
the python script to run meld. It works and the fix is there when I run it. I made a /bin/meld file to launch it and
all my scripts are totally unaware of the change. So this is great.

So here is the issue: .. using apt purge cli.
I tried to remove meld. But it installs kdiff3 in it's place
So I remove kdiff3 but that wants to put meld back in.
So I remove kdiff3 and meld (which isn't install) but that wants to put diffuse in its place.
So I remove kdiff3 and meld and diffuse (the latter 2 not installed) but now that wants to put a huge chunk of junk in:
"The following additional packages will be installed:
kompare kpart5-kompare ktexteditor-data ktexteditor-katepart libeditorconfig0 libkf5syntaxhighlighting-data
libkf5syntaxhighlighting5 libkf5texteditor-bin libkf5texteditor5 libkomparediff2-5 libkompareinterface5
The following packages will be REMOVED:
kdiff3* kdiff3-doc* meld*"

SO how the hell do I get a package to remove and not install anything else... Just remove it!!!??
The same thing happens in synaptic too so that's no solution. And I don't see anything in help like a switch.
--
Linux Mint 21.1 Cinnamon 5.6.8
Al

On 7/22/23 8:47 AM, Big Al wrote:
> I use meld to diff two css files that are quite long, looking for
> changes.
> I got the author to fix a bug in the line number display.
> The fixed program is not in the repository of Mint 21.1 so I
> downloaded the tar.gz file from gitlab and in it there is the python
> script to run meld.  It works and the fix is there when I run it.  I
> made a /bin/meld file to launch it and all my scripts are totally
> unaware of the change.  So this is great.
>
> So here is the issue: .. using apt purge cli.
> I tried to remove meld.   But it installs kdiff3 in it's place
> So I remove kdiff3 but that wants to put meld back in.
> So I remove kdiff3 and meld (which isn't install) but that wants to
> put diffuse in its place.
> So I remove kdiff3 and meld and diffuse (the latter 2 not installed)
> but now that wants to put a huge chunk of junk in:
> "The following additional packages will be installed:
>   kompare kpart5-kompare ktexteditor-data ktexteditor-katepart
> libeditorconfig0 libkf5syntaxhighlighting-data
>   libkf5syntaxhighlighting5 libkf5texteditor-bin libkf5texteditor5
> libkomparediff2-5 libkompareinterface5
> The following packages will be REMOVED:
>   kdiff3* kdiff3-doc* meld*"
>
> SO how the hell do I get a package to remove and not install anything
> else...   Just remove it!!!??
> The same thing happens in synaptic too so that's no solution.  And I
> don't see anything in help like a switch.
see if fsck will help your system.

On 7/22/23 10:08, this is what Nic wrote:
> On 7/22/23 8:47 AM, Big Al wrote:
>> I use meld to diff two css files that are quite long, looking for changes.
>> I got the author to fix a bug in the line number display.
>> The fixed program is not in the repository of Mint 21.1 so I downloaded the tar.gz file from gitlab and in it there is
>> the python script to run meld.  It works and the fix is there when I run it.  I made a /bin/meld file to launch it and
>> all my scripts are totally unaware of the change.  So this is great.
>>
>> So here is the issue: .. using apt purge cli.
>> I tried to remove meld.   But it installs kdiff3 in it's place
>> So I remove kdiff3 but that wants to put meld back in.
>> So I remove kdiff3 and meld (which isn't install) but that wants to put diffuse in its place.
>> So I remove kdiff3 and meld and diffuse (the latter 2 not installed) but now that wants to put a huge chunk of junk in:
>> "The following additional packages will be installed:
>>   kompare kpart5-kompare ktexteditor-data ktexteditor-katepart libeditorconfig0 libkf5syntaxhighlighting-data
>>   libkf5syntaxhighlighting5 libkf5texteditor-bin libkf5texteditor5 libkomparediff2-5 libkompareinterface5
>> The following packages will be REMOVED:
>>   kdiff3* kdiff3-doc* meld*"
>>
>> SO how the hell do I get a package to remove and not install anything else...   Just remove it!!!??
>> The same thing happens in synaptic too so that's no solution.  And I don't see anything in help like a switch.
> see if fsck will help your system.
What is fsck going to do? I'm not having issues with the drive or data files, just APT.
--
Linux Mint 21.1 Cinnamon 5.6.8
Al

Big Al wrote:
> I downloaded the tar.gz file from gitlab and in it there is the python
> script to run meld.  It works and the fix is there when I run it.

Does that mean that you did it according to the readme?

https://gitlab.gnome.org/GNOME/meld/-/blob/main/README.md

> Meld uses meson build system. Use the following
> commands to build Meld from the source directory:
>
> $ meson _build
> $ cd _build
> $ ninja
> You can then install Meld system-wide by running:
>
> $ ninja install

--
Mike Easter

On 7/22/2023 11:18 AM, Mike Easter wrote:
> Big Al wrote:
>> I downloaded the tar.gz file from gitlab and in it there is the python script to run meld.  It works and the fix is there when I run it.
>
> Does that mean that you did it according to the readme?
>
> https://gitlab.gnome.org/GNOME/meld/-/blob/main/README.md
>
>> Meld uses meson build system. Use the following
>> commands to build Meld from the source directory:
>>
>> $ meson _build
>> $ cd _build
>> $ ninja
>> You can then install Meld system-wide by running:
>>
>> $ ninja install

This article is sadly lacking in proper formatting.

https://community.linuxmint.com/tutorial/view/1525

When you build a package manually, some of the auto-build
tools build in a directory called build in the package unpack
directory you worked in, in your downloads. However, if running
the private version, you'd have to edit your $PATH to "make it all nice".

Build tools or config files, will also have locations of installation.
Like "/usr/local/bin" in your path, likely comes before "/usr/bin",
so a locally prepared executable is picked up in preference to the
release one. If you do "make install" or some equivalent thing, then
such tools consult the configuration info as to where to install. If
you haven't edited the config, it *might* install to /usr/local/bin
for example.

build/bin Completely isolated and un-integrated runtime

/usr/local/bin How build tools make private versions of tools, which
fit into how the $PATH was designed. Make install might
poop in here, unless you edit some file to stop it.
sudo make -n install is a first-run check-and-see option
as it does not install anything.

/usr/bin Certainly the package manager goes here. I don't
know how gdebi works and whether the behaviors are any better
in some sense, than apt and a repository for management.
Some amount of research is required, before working at this level,
or installing .ppa setups to override or augment the official tree.

I'm a lazy guy, so build/bin and one-off $PATH adjustment while
I work with a tool, is "good enough" while I wait for some feature
to show up by other means. Like, I could build a Nightly Firefox and
run the portable setup out of the build directory in that tree. And that
does not screw up my regular profile (no version issues as the profile
folder is in the build tree, specifically for the purpose of private run).

My main problem with lazy guy private build management, is the impact
on backup time. If I need to clone my daily driver (P2V) and drag it into
a VM for some reason, having a Firefox source tree in there would be a no-no.
It takes too long to deal with huge lumps like that. I have tarred
up trees certainly, but then if I do that, I'm unlikely to unpack them
ever again :-) (Think "lazy-guy"). Sure, I could design separate partitions
for cruft, but then there might be some path issues while working that
way, or additional integration steps.

I do short term builds here, of the odd thing, but they're all over the
place. Then you can never remember where you did them, later. (Consequences
of being a lazy-guy.) And in some cases, a build is 2GB of downloads,
followed by the CUDA stuff not working, and the whole lot goes into the tip.
Each kind of build has different risk factors.

Paul

On 7/22/23 11:18, this is what Mike Easter wrote:
> Big Al wrote:
>> I downloaded the tar.gz file from gitlab and in it there is the python script to run meld.  It works and the fix is
>> there when I run it.
>
> Does that mean that you did it according to the readme?
>
> https://gitlab.gnome.org/GNOME/meld/-/blob/main/README.md
>
>> Meld uses meson build system. Use the following
>> commands to build Meld from the source directory:
>>
>> $ meson _build
>> $ cd _build
>> $ ninja
>> You can then install Meld system-wide by running:
>>
>> $ ninja install
>
>
>
I didn't compile anything. According to the readme, it says you can just run the bin/meld from the folder you
uncompress the tarball into. And it does work. So my only issue is to get rid of the old meld. I'm fine with moving
the meld folder in my Downloads to /opt and making links in /bin to make the new meld command to work.

It's just removing the old meld. Granted I could just blow away the bin/meld file which I would have to do anyway to
put my new one in place, but I wanted to just cosmetically get rid of the other meld support files for the old version.
--
Linux Mint 21.1 Cinnamon 5.6.8
Al

On 7/22/23 12:40, this is what Big Al wrote:
> On 7/22/23 11:18, this is what Mike Easter wrote:
>> Big Al wrote:
>>> I downloaded the tar.gz file from gitlab and in it there is the python script to run meld.  It works and the fix is
>>> there when I run it.
>>
>> Does that mean that you did it according to the readme?
>>
>> https://gitlab.gnome.org/GNOME/meld/-/blob/main/README.md
>>
>>> Meld uses meson build system. Use the following
>>> commands to build Meld from the source directory:
>>>
>>> $ meson _build
>>> $ cd _build
>>> $ ninja
>>> You can then install Meld system-wide by running:
>>>
>>> $ ninja install
>>
>>
>>
> I didn't compile anything.   According to the readme, it says you can just run the bin/meld from the folder you
> uncompress the tarball into.   And it does work.  So my only issue is to get rid of the old meld.  I'm fine with moving
> the meld folder in my Downloads to /opt and making links in /bin to make the new meld command to work.
>
> It's just removing the old meld.   Granted I could just blow away the bin/meld file which I would have to do anyway to
> put my new one in place, but I wanted to just cosmetically get rid of the other meld support files for the old version.

Using the 'apt-cache depends nemo-compare' command, this shows me that nemo's file compare add-on uses any of a number
of compare programs. I'm supposing that it needs just one.
nemo-compare
Depends: nemo
Depends: python3
Depends: python-nemo
|Depends: meld
|Depends: kdiff3
|Depends: kdiff3-qt
|Depends: diffuse
|Depends: kompare
|Depends: fldiff
|Depends: <tkdiff>
tkcvs
Depends: <bcompare>

So I won't get around this with apt.
I'm simply going to move the /bin/meld command to meld.old and then put my new one in place. Programs won't know and
to hell with apt's demands.

Thanks for letting me rant !
--
Linux Mint 21.1 Cinnamon 5.6.8
Al

Paul wrote:
> Mike Easter wrote:
>> Big Al wrote:
>>> I downloaded the tar.gz file from gitlab and in it there is the python script to run meld.  It works and the fix is there when I run it.
>>
>> Does that mean that you did it according to the readme?
>>
>> https://gitlab.gnome.org/GNOME/meld/-/blob/main/README.md
>>
>>> Meld uses meson build system. Use the following
>>> commands to build Meld from the source directory:
>>>
>>> $ meson _build
>>> $ cd _build
>>> $ ninja
>>> You can then install Meld system-wide by running:
>>>
>>> $ ninja install
>
> This article is sadly lacking in proper formatting.
>
> https://community.linuxmint.com/tutorial/view/1525
>
That Mint page is a very good page/tutorial. I'm going to read it some
more. I can 'handle' the poor formatting.

But it doesn't tell me anything about meson and ninja.

https://mesonbuild.com/Quick-guide.html

https://ninja-build.org/

> Each kind of build has different risk factors.

I don't like 'it' :-) ... where it means building.

--
Mike Easter

Big Al wrote:
> I use meld

I tho't I would try to learn something, as an 'exercise'.

Live LM 21.1 Cinn (Ventoy). Repo meld 3.20.4-2 (rel '21 Aug 13);
current stable meld 3.22.0 (rel '22 Sep 4) (I haven't checked the repo/s
for LM 21.2 yet).

Current flathub meld = 3.22.0

So, I installed 3.20 from the repo/s; it became accessible in the menu
(under Programming) and running provided a graphical interface. It can
also be run from the command line such as meld file1 file2 (or even 3)
or meld --help or --version (3.20.4)

Then, since LM is flathub capable as the default, I went to flathub,
dl/ed 3.22.0, then installed/ran org.gnome.meld.flatpakref which
provided a function to install 3.22.0 which required almost a gig of dl
and 3 G of so-called disk space (in the live) eating ram.

Fat installs are not a good thing for live experiments, but the device
had enough ram so far.

The up/ed meld was able to run as a graphical or CLI app and showed me
it was 3.22.0 instead of 3.20.4.

None of that helps the problem BA was having, but it showed me something
about flathub, which type of packaging I do NOT prefer compared to
conventional primarily from distro repo/s, next from hopefully reliable
..ppa repo/s, which are less 'bulky' installs.

My next experiment is to load a LM 21.2 by replacing 21.1 on the Ventoy
and see how things go w/ following meld's readme compile from source for
3.22.0. I will have to use up a fair amount of ram to prepare for the
compile meld describes.

--
Mike Easter

Mike Easter wrote:
>
> Live LM 21.1 Cinn (Ventoy). Repo meld 3.20.4-2 (rel '21 Aug 13);
> current stable meld 3.22.0 (rel '22 Sep 4) (I haven't checked the
> repo/s for LM 21.2 yet).
>
LM 21.2 still has 3.20.4-2
>
> My next experiment is to load a LM 21.2 by replacing 21.1 on the
> Ventoy and see how things go w/ following meld's readme compile from
> source for 3.22.0. I will have to use up a fair amount of ram to
> prepare for the compile meld describes.
>
After dl/ing the source and extracting, I had problems I couldn't solve.

I couldn't even perform this:

> You do not need to build Meld in order to run it. Meld can be run
> directly from this source directory by running $ bin/meld

I'm not interested enough to try to solve this, much less the meson and
ninja build.

--
Mike Easter

On 7/22/23 15:50, this is what Mike Easter wrote:
> Mike Easter wrote:
>>
>> Live LM 21.1 Cinn (Ventoy).  Repo meld 3.20.4-2 (rel '21 Aug 13); current stable meld 3.22.0 (rel '22 Sep 4) (I
>> haven't checked the
>> repo/s for LM 21.2 yet).
>>
> LM 21.2 still has 3.20.4-2
>>
>> My next experiment is to load a LM 21.2 by replacing 21.1 on the
>> Ventoy and see how things go w/ following meld's readme compile from
>> source for 3.22.0.  I will have to use up a fair amount of ram to
>> prepare for the compile meld describes.
>>
> After dl/ing the source and extracting, I had problems I couldn't solve.
>
> I couldn't even perform this:
>
>> You do not need to build Meld in order to run it. Meld can be run
>> directly from this source directory by running $ bin/meld
>
> I'm not interested enough to try to solve this, much less the meson and ninja build.
>
I usually have issues with most program compiles. There is always some special apps that have to be installed to get
the compiling to work. And I don't do enough of it to put the time in to setup my system.

I have one flatpack program, a card game, that has a serious defect in the old program.

And yes, mint 21.1 and 21.2 both have meld 3.20. and I wish to have 3.22. One would hope and I don't know why, that
when Mint pressed a new ISO for 21.2 they would up some of the programs to more recent copies. Or I would like to
think they would, but....

For anyone that wants it, here are the steps.
I got meld working very simply.
I installed meld 3.20 from repro.
I downloaded the 3.22 from gitlab and put it in /opt/meld
I installed with "sudo apt-get install libglib2.0-dev" a requirement for the meld 3.22 to run
I moved /usr/bin/meld to /usr/bin/meld.old
I linked /opt/meld/bin/meld to /usr/bin/meld

Now all is good and nobody knows they are launching a different python program (3.22 instead of 3.20). But I see the
right program and the new version has the visual fix I want.
I took 6 hours on/off to do it, but it was more of a challenge than anything else, I wasn't going to let a stinking item
like this get the better of me. :-)
--
Linux Mint 21.1 Cinnamon 5.6.8
Al

On 7/22/2023 3:50 PM, Mike Easter wrote:
> Mike Easter wrote:
>>
>> Live LM 21.1 Cinn (Ventoy).  Repo meld 3.20.4-2 (rel '21 Aug 13); current stable meld 3.22.0 (rel '22 Sep 4) (I haven't checked the
>> repo/s for LM 21.2 yet).
>>
> LM 21.2 still has 3.20.4-2
>>
>> My next experiment is to load a LM 21.2 by replacing 21.1 on the
>> Ventoy and see how things go w/ following meld's readme compile from
>> source for 3.22.0.  I will have to use up a fair amount of ram to
>> prepare for the compile meld describes.
>>
> After dl/ing the source and extracting, I had problems I couldn't solve.
>
> I couldn't even perform this:
>
>> You do not need to build Meld in order to run it. Meld can be run
>> directly from this source directory by running $ bin/meld
>
> I'm not interested enough to try to solve this, much less the meson and ninja build.

meson installs ninja-build, in the Mint repository.

sudo apt install meson

python is already installed

sudo apt install python3-all-dev

Need a cmake (two build systems, apparently)

sudo apt install cmake

Speculative (see if it will shut up about gtk+-3.0 not found)

sudo apt install gobject-introspection # claims to install libglib2

sudo apt install libglib2.0-dev

OK, maybe this one.

sudo apt install libgtk-3-dev # Bingo

This one is a straight dependency.

sudo apt install libgtksourceview-4-dev

Back to speculation mode.

sudo apt install python-gi-dev # Bingo

More speculation.

sudo apt install python3-cairo-dev # Bingo

Another direct dependency.

sudo apt install appstream-util
sudo apt install itstool

Out of ammo (no GTK4 in repo). Bake a cookie, say a prayer.

cd build
ninja

Install meld to get meld dependencies fulfilled.

sudo apt install meld # it is installing libglib-2 which I thought was there already

Running it as bin/meld does not work.

I did not use (yet another) build system as the Git page suggested.
I wanted to see some progress from that much work.

End.

Paul