16 Sep
2020
16 Sep
'20
7:22 p.m.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)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
16 Sep
16 Sep
7:36 p.m.
New subject: [users] [users] installing icecat from source packages - how2 draft
On Wednesday 16 September 2020 12:22:05 deloptes via tde-users wrote:
J Leslie Turriff via tde-users wrote:
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
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.
8:22 p.m.
New subject: [users] [users] installing icecat from source packages - how2 draft
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, September 16, 2020 12:36 PM, William Morder via tde-users
<ml-migration-agent(a)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(a)trinitydesktop.org
> To unsubscribe send an email to users-leave(a)trinitydesktop.org
> Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…
what I know today.
"opt" is used by third party applications. my "opt' contains:
master-pdf-editor-5/, openoffice4/ , trinity/. .
"/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
9:04 p.m.
New subject: [users] [users] installing icecat from source packages - how2 draft
On Wednesday 16 September 2020 13:22:43 greg via tde-users wrote:
/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.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, September 16, 2020 12:36 PM, William Morder via tde-users
<ml-migration-agent(a)trinitydesktop.org> wrote:
On Wednesday
16 September 2020 12:22:05 deloptes via tde-users wrote:
what I know today.
"opt" is used by third party applications. my "opt' contains:
J Leslie Turriff via tde-users wrote:
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(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydes
ktop.org 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. 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
17 Sep
17 Sep
6:11 p.m.
New subject: [users] [users] installing icecat from source packages - how2 draft
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, September 16, 2020 2:04 PM, William Morder via tde-users
<ml-migration-agent(a)trinitydesktop.org> wrote:
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.
https://openoffice.apache.org/source.html
greg
25 Oct
25 Oct
7:47 p.m.
New subject: installing icecat from source packages - how2 draft - update
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
17 Sep
17 Sep
6:14 a.m.
New subject: [users] [users] [users] installing icecat from source packages - how2 draft
On 2020-09-16 14:22:05 deloptes via tde-users wrote:
J Leslie Turriff via tde-users wrote:
Because
#1 Package bulding is not in my repertoire, and
#2 debian packages don't help much on an RPM-based system. :-)
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.
6:25 a.m.
New subject: [users] [users] [users] installing icecat from source packages - how2 draft
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(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)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
2:05 p.m.
New subject: [users] [users] [users] installing icecat from source packages - how2 draft
On Thursday 17 September 2020 01:25:04 am deloptes via tde-users wrote:
J Leslie Turriff via tde-users wrote:
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
#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)
3:03 p.m.
New subject: [users] [users] [users] installing icecat from source packages - how2 draft
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:
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
J Leslie Turriff via tde-users wrote:
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 #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)
3:10 p.m.
New subject: [users] [users] [users] installing icecat from source packages - how2 draft
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:
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.
J Leslie Turriff via tde-users wrote:
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 #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)
3:55 p.m.
New subject: RPM vs. apt, compiling vs. packaging
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:
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 01:25:04 am
deloptes via tde-users wrote:
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. J Leslie Turriff via tde-users wrote:
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 #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) 
3:31 p.m.
New subject: [users] [users] [users] installing icecat from source packages - how2 draft
Dne čt 17. září 2020 Michael via tde-users napsal(a):
On Thursday 17 September 2020 01:25:04 am deloptes 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". In fact, I did
not understand how anything "enterprise" can be based on such an unstable
state of basic package management tools.
Cheers
--
Slávek
J Leslie Turriff via tde-users wrote:
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
____________________________________________________ #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)
4:08 p.m.
New subject: RPM vs. apt, compiling vs. packaging
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
1272
days inactive
1311
days old
13 comments
6 participants
participants (6)
-
deloptes -
greg
-
J Leslie Turriff -
Michael -
Slávek Banko -
William Morder