On Wednesday 16 September 2020 13:22:43 greg via tde-users wrote:

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Wednesday, September 16, 2020 12:36 PM, William Morder via tde-users

ml-migration-agent@trinitydesktop.org wrote:

...

On Wednesday 16 September 2020 12:22:05 deloptes via tde-users wrote:

...

J Leslie Turriff via tde-users wrote:

...

Correct.  But for some reason I can't imagine, I linked the wrong thing.

:-)

I missed this thread, but why don't you build a simple debian package? If it were to be installed in custom directory, I found out that a kind of isolation is the best approach. I use /opt/custom and compile/install in /opt/custom/<application> Then I add to the global or users PATH /opt/custom/<application>/bin I also found out that creating /opt/custom/<application> and chown to a users and compiling/installing with that user prevents from broken installers. The method never failed, although in recent years I have reduced the applications there to absolute minimum in favor to debian packages.

I was thinking of doing this myself, but I obviously am not really a tech person, compared to most of the other folks on this mailing list.

Funny thing, though, people out in the "real world" (you know the place) often eem to imagine that I am a blackhat cracker who can bring down the government with a few command-line tricks. (I have no such illusions.)

Once I get the steps for installation from source packages in order, I wanted to create deb packages, at least for myself. It would be nice to get them hosted somewhere, as I dislike having to use source packages -- although I know some geeky friends who swear by this method over using deb, rpm, yum or other packages.

So, if I follow what you say, installing to /opt/custom/ instead of /usr/lib/ ?

Bill

tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydes ktop.org

what I know today.

"opt" is used by third party applications. my "opt' contains:

/usr/lib/ is where firefox gets installed. I installed there, because I used firefox as my model. However, since I already know that it can be installed in, and run from, the home folder (though it's not a good idea), then I don't see a problem with using /opt/custom/ as the location for the icecat folder.

master-pdf-editor-5/, openoffice4/ , trinity/. .

I'm wondering where you got openoffice4, as I've searched high and low for it; source packages only, but I suppose I could deal with it once more.

"/usr/local" is used by me to manage my system. there is

a "usr/local/src". "usr/local/bin", "/usr/local/bin" is already in PATH

Thanks for your comments.

Bill

This is *sort of* a continuation of that earlier thread, and also *sort of* something new.

For some reason, I couldn't get Icecat to install again, even though I am using the same steps as outlined earlier. So I went searching for answers, and discovered this link on github: https://github.com/tmiland/GNU-IceCat/releases

I downloaded and installed the package that fits my system. It seems to be a metapackage. Download, then run dpkg, and it will download and compile the source package. I watched while it was downloading, and all the components seem to be identical to the source package components -- except that the download does not quite complete, and I cannot find out where it was downloaded or installed. It is left in a not-fully-installed limbo, and neither dpkg-reconfigure nor apt-get -f install corrects the problem.

On a side note: the package is named gnu-icecat in this instance, rather than just icecat; but changing names does not help.

Just wondering if anybody out there is feeling adventurous or curious enough to investigate. If it can be made to work, then no need for the clumsy compile-from-source method. (Source packages are also provided.)

Note that no checksum or key is provided. It doesn't appear to contain any malicious code, but others may know better.

Bill

J Leslie Turriff via tde-users wrote:

#2      debian packages don't help much on an RPM-based system. :-)

then build RPM or isolate as suggested, so that you can manage the installed software easier later (for example if you have to update)

--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

On Thursday 17 September 2020 07:05:53 Michael via tde-users wrote:

On Thursday 17 September 2020 01:25:04 am deloptes via tde-users wrote:

...

J Leslie Turriff via tde-users wrote:

...

#2      debian packages don't help much on an RPM-based system. :-)

then build RPM or isolate as suggested, so that you can manage the installed software easier later (for example if you have to update)

I can't say why, but it was way easier in CentOS (RPM) than Ubuntu, Devuan, MX (apt) to compile from source and keep it updated that way. It wasn’t until I switched to non-systemd Debian derivatives that I ever saw a need to build a package.

2 cents, Michael

O, you systemd fanatics, always trying to convert us, by any means possible!

Actually, I don't quite understand: Why would non-systemd create a perceived need to build packages? Am I to undertand that by "non-systemd Debian derivatives" you mean the AntiX and maybe MX distros? Devuan is non-systemd, but you don't seem to include that among the derivatives.

Please clarify.

Bill

On Thursday 17 September 2020 10:10:57 am William Morder via tde-users wrote:

On Thursday 17 September 2020 07:05:53 Michael via tde-users wrote:

...

On Thursday 17 September 2020 01:25:04 am deloptes via tde-users wrote:

...

J Leslie Turriff via tde-users wrote:

...

#2      debian packages don't help much on an RPM-based system. :-)

then build RPM or isolate as suggested, so that you can manage the installed software easier later (for example if you have to update)

I can't say why, but it was way easier in CentOS (RPM) than Ubuntu, Devuan, MX (apt) to compile from source and keep it updated that way. It wasn’t until I switched to non-systemd Debian derivatives that I ever saw a need to build a package.

2 cents, Michael

O, you systemd fanatics, always trying to convert us, by any means possible!

Actually, I don't quite understand: Why would non-systemd create a perceived need to build packages? Am I to undertand that by "non-systemd Debian derivatives" you mean the AntiX and maybe MX distros? Devuan is non-systemd,* but you don't seem to include that among the derivatives.

Please clarify.

Bill

P.S.* Sorry, but I misread that line. I see that I took it that you were including Devuan in the crowd of "way easier to compile".

Still, I don't quite get why you say this.

Hi Bill,

It's just my perception based upon limited data, the specific distributions listed are just the ones I personally used. Non-systemd was just my turning point from going from RPM to apt, so systemd isn’t really a factor, it’s just a reference point. I used CentOS for years on my desktop as it’s what I use on production servers (still do, not that I like it, but there’s no real alternative for what I provide my clients).

In CentOS “compile and go” pretty much just “worked” and I never had to reinstall a system from scratch because of a bad compile. You do have to re-compile depending on kernel upgrades, but it wasn’t hard.

In apt, I’ve had to (twice now before I learned “don’t do that”) completely reinstall a system from scratch because of compiling instead of packaging. For what it’s worth, I think apt makes creating a package and local repository easier (that’s a bunch of speculation on my part since I never created an actual RPM).

I could completely SWAG that the difference is because of intended end users. Red Hat is enterprise business, e.g. it better work and it better not change. Debian is {huh, I don’t actually know, best guess is individual user???} skipping that, Debian has ~900K US cash in the bank so they aren’t really beholden to anyone, so why should they care if they piss off their user base? The irony being they now can’t hire developers (which I’ll attribute to systemd, hah!)

Sorry for the confusion, and I wasn’t trying to pick on any specific distribution.

Best, Michael

PS: If anyone really knows the answer to the new Subject, would you chime in? Bill made me curious what the reality is...

On Thursday 17 September 2020 10:31:15 am Slávek Banko via tde-users wrote:

Once upon a time I used RedHat Linux (please do not confuse it with the current RHEL). Starting with version 5.0 and ending with version 7.3. At the time I was used to building and maintaining my own RPM packages.

Although the creation of the source package was at first glance easier than for deb packages, building binary packages was always a big pain. Towards the end I was happy when I could use apt-get for RPM.

I've been using Debian since version 3.0 and when I learned how to build packages and use pbuilder, it was a huge relief and much easier work than ever before with RPM. Some time ago I switched from pbuilder to schroot + sbuild, but the principle remains the same and just as simple.

Conversely, when I needed to solve some problem with building an RPM package, I tried to find some tool comparable to pbuilder (I found a mock), but there was a lot of pain in the RPM package management tools. From my point of view, the state is so unfinished, one project replaces the other, so in the final they are all constantly "in development". I considered the "most perfect" when I found instructions for building "dnf" from the source code, which stated to use "dnf build dnf".

Thanks Slávek!

You answered my PS before I asked it :)

In fact, I did not understand how anything "enterprise" can be based on such an unstable state of basic package management tools.

This I can probably answer for you. My best guess from a business standpoint.

It’s intentional. Red Hat must have very well built internal tools and they are not going to share them. They are also almost guaranteed to be ‘black box’ to the regular Red Hat employee needing to create an RPM. E.g. they are most likely treated like Coca-Cola’s Coke formula, kept in a vault...

Anything found in the ‘wild’ is user built, and based upon what you’ve said basically quickly abandoned?

Best, Michael