Hi,
Is anyone here running XFCE desktop on CentOS 8? If so, how did you install it?
I just tried to install it from EPEL and this is what I got:
# dnf group install Xfce Last metadata expiration check: 0:14:01 ago on Thu 11 Feb 2021 10:05:47 CET. No match for group package "NetworkManager-gnome" No match for group package "thunar-archive-plugin"
I'm unable to find packages for NetworkManager-gnome or thunar-archive-plugin anywhere in CentOS 8 or EPEL 8.
Did I miss something?
Thanks, Simon
Hi Simon,
I'm running XFCE under CentOS 8 as a VM under CentOS 7. I've just had a quick look and this is what I see (see attachment). You'll need to view it in a wide terminal.
HTH, Martin
On 11/02/2021 09:24, Simon Matter wrote:
Hi,
Is anyone here running XFCE desktop on CentOS 8? If so, how did you install it?
I just tried to install it from EPEL and this is what I got:
# dnf group install Xfce Last metadata expiration check: 0:14:01 ago on Thu 11 Feb 2021 10:05:47 CET. No match for group package "NetworkManager-gnome" No match for group package "thunar-archive-plugin"
I'm unable to find packages for NetworkManager-gnome or thunar-archive-plugin anywhere in CentOS 8 or EPEL 8.
Did I miss something?
Thanks, Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Thanks Martin, so the "Xfce" group definition in EPEL is obviously broken.
Looks like XFCE doesn't get much love in EL8. Do you or anyone else have suggestions for a lightweight desktop environment to use on EL8 apart from XFCE? One which is supported well by EPEL?
Thanks, Simon
Hi Simon,
I'm running XFCE under CentOS 8 as a VM under CentOS 7. I've just had a quick look and this is what I see (see attachment). You'll need to view it in a wide terminal.
HTH, Martin
On 11/02/2021 09:24, Simon Matter wrote:
Hi,
Is anyone here running XFCE desktop on CentOS 8? If so, how did you install it?
I just tried to install it from EPEL and this is what I got:
# dnf group install Xfce Last metadata expiration check: 0:14:01 ago on Thu 11 Feb 2021 10:05:47 CET. No match for group package "NetworkManager-gnome" No match for group package "thunar-archive-plugin"
I'm unable to find packages for NetworkManager-gnome or thunar-archive-plugin anywhere in CentOS 8 or EPEL 8.
Did I miss something?
Thanks, Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-- J Martin Rushton MBCS _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Sorry, I run gdm on Springdale 8 and Alma 8. I'm not doing much work on any RHEL 8 clone ATM, I prefer the longer support of C7! :-( Martin
On 11/02/2021 10:26, Simon Matter wrote:
Thanks Martin, so the "Xfce" group definition in EPEL is obviously broken.
Looks like XFCE doesn't get much love in EL8. Do you or anyone else have suggestions for a lightweight desktop environment to use on EL8 apart from XFCE? One which is supported well by EPEL?
Thanks, Simon
Hi Simon,
I'm running XFCE under CentOS 8 as a VM under CentOS 7. I've just had a quick look and this is what I see (see attachment). You'll need to view it in a wide terminal.
HTH, Martin
On 11/02/2021 09:24, Simon Matter wrote:
Hi,
Is anyone here running XFCE desktop on CentOS 8? If so, how did you install it?
I just tried to install it from EPEL and this is what I got:
# dnf group install Xfce Last metadata expiration check: 0:14:01 ago on Thu 11 Feb 2021 10:05:47 CET. No match for group package "NetworkManager-gnome" No match for group package "thunar-archive-plugin"
I'm unable to find packages for NetworkManager-gnome or thunar-archive-plugin anywhere in CentOS 8 or EPEL 8.
Did I miss something?
Thanks, Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-- J Martin Rushton MBCS _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
I'm also on C7 for the same reason but wanted to see how XFCE is supported on any EL8 clone for the future.
In the past I've even produced updated XFCE packages but I don't want to do this in future. Too many other things to do.
Simon
Sorry, I run gdm on Springdale 8 and Alma 8. I'm not doing much work on any RHEL 8 clone ATM, I prefer the longer support of C7! :-( Martin
On 11/02/2021 10:26, Simon Matter wrote:
Thanks Martin, so the "Xfce" group definition in EPEL is obviously broken.
Looks like XFCE doesn't get much love in EL8. Do you or anyone else have suggestions for a lightweight desktop environment to use on EL8 apart from XFCE? One which is supported well by EPEL?
Thanks, Simon
Hi Simon,
I'm running XFCE under CentOS 8 as a VM under CentOS 7. I've just had a quick look and this is what I see (see attachment). You'll need to view it in a wide terminal.
HTH, Martin
On 11/02/2021 09:24, Simon Matter wrote:
Hi,
Is anyone here running XFCE desktop on CentOS 8? If so, how did you install it?
I just tried to install it from EPEL and this is what I got:
# dnf group install Xfce Last metadata expiration check: 0:14:01 ago on Thu 11 Feb 2021 10:05:47 CET. No match for group package "NetworkManager-gnome" No match for group package "thunar-archive-plugin"
I'm unable to find packages for NetworkManager-gnome or thunar-archive-plugin anywhere in CentOS 8 or EPEL 8.
Did I miss something?
Thanks, Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-- J Martin Rushton MBCS _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-- J Martin Rushton MBCS
On 11/02/21 10:24 pm, Simon Matter wrote:
Hi,
Is anyone here running XFCE desktop on CentOS 8? If so, how did you install it?
I just tried to install it from EPEL and this is what I got:
# dnf group install Xfce Last metadata expiration check: 0:14:01 ago on Thu 11 Feb 2021 10:05:47 CET. No match for group package "NetworkManager-gnome" No match for group package "thunar-archive-plugin"
I run the command and it resolves the dependencies just fine, but does not want to install any of the above two packages.
I'm unable to find packages for NetworkManager-gnome or thunar-archive-plugin anywhere in CentOS 8 or EPEL 8.
Can you please show the full output of your command, please? Also the output of:
dnf repolist -v epel
Peter
Hi,
On 11/02/21 10:24 pm, Simon Matter wrote:
Hi,
Is anyone here running XFCE desktop on CentOS 8? If so, how did you install it?
I just tried to install it from EPEL and this is what I got:
# dnf group install Xfce Last metadata expiration check: 0:14:01 ago on Thu 11 Feb 2021 10:05:47 CET. No match for group package "NetworkManager-gnome" No match for group package "thunar-archive-plugin"
I run the command and it resolves the dependencies just fine, but does not want to install any of the above two packages.
I'm unable to find packages for NetworkManager-gnome or thunar-archive-plugin anywhere in CentOS 8 or EPEL 8.
Can you please show the full output of your command, please? Also the output of:
# dnf group install "Xfce" Last metadata expiration check: 0:05:02 ago on Thu 11 Feb 2021 11:45:57 CET. No match for group package "NetworkManager-gnome" No match for group package "thunar-archive-plugin" Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing group/module packages: Thunar x86_64 1.8.15-1.el8 epel 1.6 M mousepad x86_64 0.4.2-1.el8 epel 326 k thunar-volman x86_64 0.9.5-1.el8 epel 290 k tumbler x86_64 0.2.7-1.el8 epel 237 k xfce-polkit x86_64 0.3-3.el8 epel 25 k xfce4-appfinder x86_64 4.14.0-1.el8 epel 246 k xfce4-panel x86_64 4.14.4-1.el8 epel 1.0 M xfce4-power-manager x86_64 1.6.6-1.el8 epel 810 k xfce4-pulseaudio-plugin x86_64 0.4.3-1.el8 epel 123 k xfce4-screensaver x86_64 0.1.10-1.el8 epel 290 k xfce4-session x86_64 4.14.2-1.el8 epel 518 k xfce4-settings x86_64 4.14.3-1.el8 epel 877 k xfce4-terminal x86_64 0.8.10-1.el8 epel 670 k xfconf x86_64 4.14.3-1.el8 epel 261 k xfdesktop x86_64 4.14.1-3.el8 epel 1.2 M xfwm4 x86_64 4.14.2-1.el8 epel 581 k Installing dependencies: exo x86_64 0.12.10-1.el8 epel 701 k garcon x86_64 0.6.4-3.el8 epel 214 k libxfce4ui x86_64 4.14.1-3.el8 epel 274 k libxfce4util x86_64 4.14.0-1.el8 epel 180 k pavucontrol x86_64 3.0-11.el8 ol8_appstream 160 k Installing Groups: Xfce
Transaction Summary ================================================================================ Install 21 Packages
Total size: 10 M Installed size: 48 M Is this ok [y/N]:
dnf repolist -v epel
# dnf repolist -v epel Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, needs-restarting, playground, repoclosure, repodiff, repograph, repomanage, reposync DNF version: 4.2.23 cachedir: /var/cache/dnf Last metadata expiration check: 0:07:26 ago on Thu 11 Feb 2021 11:45:57 CET. Repo-id : epel Repo-name : Extra Packages for Enterprise Linux 8 - x86_64 Repo-status : enabled Repo-revision : 1613003176 Repo-updated : Thu 11 Feb 2021 01:26:47 CET Repo-pkgs : 6,999 Repo-available-pkgs: 6,994 Repo-size : 9.9 G Repo-baseurl : file:///mnt/nfs/Linux/Mirrors/epel/8/Everything/x86_64/ Repo-expire : 172,800 second(s) (last: Thu 11 Feb 2021 11:45:57 CET) Repo-filename : /etc/yum.repos.d/epel.repo Total packages: 6,999
As you can see I'm serving repos from my local mirrors. Are they not complete somehow?
Simon
On 11/02/21 11:54 pm, Simon Matter wrote:
# dnf group install "Xfce" Last metadata expiration check: 0:05:02 ago on Thu 11 Feb 2021 11:45:57 CET. No match for group package "NetworkManager-gnome" No match for group package "thunar-archive-plugin" Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing group/module packages:
...
Installing Groups: Xfce
Transaction Summary
Install 21 Packages
Total size: 10 M Installed size: 48 M Is this ok [y/N]:
Indeed I actually get the same output. Those are soft dependencies, you should be able to answer "Y" here and go ahead and install XFCE. Feel free to file a bug with EPEL about the missing deps.
Peter
On 11/02/21 10:24 pm, Simon Matter wrote:
Hi,
Is anyone here running XFCE desktop on CentOS 8? If so, how did you install it?
I just tried to install it from EPEL and this is what I got:
# dnf group install Xfce Last metadata expiration check: 0:14:01 ago on Thu 11 Feb 2021 10:05:47 CET. No match for group package "NetworkManager-gnome" No match for group package "thunar-archive-plugin"
I run the command and it resolves the dependencies just fine, but does not want to install any of the above two packages.
I'm unable to find packages for NetworkManager-gnome or thunar-archive-plugin anywhere in CentOS 8 or EPEL 8.
Can you please show the full output of your command, please? Also the output of:
dnf repolist -v epel
I also tried KDE and get this:
# dnf group install "KDE Plasma Workspaces" Last metadata expiration check: 2:43:17 ago on Thu 11 Feb 2021 14:06:32 CET. no group '3d-printing' from environment 'kde-desktop-environment' no group 'cloud-management' from environment 'kde-desktop-environment' no group 'firefox' from environment 'kde-desktop-environment' no group 'kde-telepathy' from environment 'kde-desktop-environment' No match for group package "dnfdragora" No match for group package "kmail" No match for group package "korganizer" No match for group package "kget" No match for group package "kaddressbook" No match for group package "plasma-discover" No match for group package "akregator" No match for group package "kontact" No match for group package "qt-at-spi" No match for group package "pinentry-qt" No match for group package "NetworkManager-config-connectivity-fedora" Error: Problem 1: conflicting requests - nothing provides xmessage needed by plasma-workspace-5.18.4.1-2.el8.x86_64 Problem 2: package sddm-breeze-5.18.4.1-2.el8.noarch requires plasma-workspace = 5.18.4.1-2.el8, but none of the providers can be installed - conflicting requests - nothing provides xmessage needed by plasma-workspace-5.18.4.1-2.el8.x86_64 Problem 3: package plasma-desktop-5.18.4.1-2.el8.1.x86_64 requires plasma-workspace >= 5.18, but none of the providers can be installed - conflicting requests - nothing provides xmessage needed by plasma-workspace-5.18.4.1-2.el8.x86_64 Problem 4: package kde-print-manager-19.12.3-2.el8.x86_64 requires plasma-workspace, but none of the providers can be installed - conflicting requests - nothing provides xmessage needed by plasma-workspace-5.18.4.1-2.el8.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Are my mirrors broken or incomplete? I just can't find out what happens.
Simon
On Thu, 11 Feb 2021 16:53:47 +0100 Simon Matter wrote:
Are my mirrors broken or incomplete?
I just tried dnf search kmail and it didn't find anything, so I guess that stuff is simply not there.
I personally use the Mate desktop from https://copr.fedorainfracloud.org/coprs/stenstorp/MATE/ on all of my computers and it works fine, if Mate is lightweight enough for your purposes.
On Thu, 11 Feb 2021 16:53:47 +0100 Simon Matter wrote:
Are my mirrors broken or incomplete?
I just tried dnf search kmail and it didn't find anything, so I guess that stuff is simply not there.
I personally use the Mate desktop from https://copr.fedorainfracloud.org/coprs/stenstorp/MATE/ on all of my computers and it works fine, if Mate is lightweight enough for your purposes.
Thanks, I'll have a look. Maybe I'll also find XFCE or LXQt in copr?
But, I'm a bit shocked to find EPEL 8 in such a bad shape of brokenness and incompleteness :(
Simon
Le 11/02/2021 à 17:08, Simon Matter a écrit :
But, I'm a bit shocked to find EPEL 8 in such a bad shape of brokenness and incompleteness
I've come to the same conclusion.
For the past couple years, my solution has been to use RHEL clones (CentOS and Oracle Linux) on servers only (multi-user.target).
I've moved all my graphical installations (workstation, laptops, desktop clients) to OpenSUSE Leap + KDE.
Cheers,
Niki
Le 11/02/2021 à 17:08, Simon Matter a écrit :
But, I'm a bit shocked to find EPEL 8 in such a bad shape of brokenness and incompleteness
I've come to the same conclusion.
For the past couple years, my solution has been to use RHEL clones (CentOS and Oracle Linux) on servers only (multi-user.target).
I've moved all my graphical installations (workstation, laptops, desktop clients) to OpenSUSE Leap + KDE.
In our situation it's not so easy to say server or client. We're running remote desktops over nx-libs, so, a server is also a client at the same time.
I always new EPEL is not perfect but it was usable to some degree and that's why Red Hat told their customers about it and how to use it. But the current state of EPEL is sad.
Simon
On Thu, 11 Feb 2021 at 12:31, Simon Matter simon.matter@invoca.ch wrote:
Le 11/02/2021 à 17:08, Simon Matter a écrit :
But, I'm a bit shocked to find EPEL 8 in such a bad shape of brokenness and incompleteness
I've come to the same conclusion.
For the past couple years, my solution has been to use RHEL clones
(CentOS
and Oracle Linux) on servers only (multi-user.target).
I've moved all my graphical installations (workstation, laptops, desktop clients) to OpenSUSE Leap + KDE.
In our situation it's not so easy to say server or client. We're running remote desktops over nx-libs, so, a server is also a client at the same time.
I always new EPEL is not perfect but it was usable to some degree and that's why Red Hat told their customers about it and how to use it. But the current state of EPEL is sad.
EPEL is a volunteer driven repository and not many volunteers have been available for EL8. Many of the past volunteers have retired or been promoted out of positions they actually have time to do the work anymore. Asking for replacements is not easy because most people who are interested in EPEL just want the packages built. They have no want or clue to do the work themselves and want someone else to do the work for them. This leads to a lot of people expecting packages without anyone doing the work.
That rant aside, if people are interested in helping out, there is a weekly EPEL IRC SIG meeting (irc.freenode.net #fedora-meeting 22:00 UTC Friday). THere is the #epel mailing list and there are several people who are trying to get volunteers to work on packages and such.
On Thu, 11 Feb 2021 at 12:31, Simon Matter simon.matter@invoca.ch wrote:
Le 11/02/2021 à 17:08, Simon Matter a écrit :
But, I'm a bit shocked to find EPEL 8 in such a bad shape of
brokenness
and incompleteness
I've come to the same conclusion.
For the past couple years, my solution has been to use RHEL clones
(CentOS
and Oracle Linux) on servers only (multi-user.target).
I've moved all my graphical installations (workstation, laptops,
desktop
clients) to OpenSUSE Leap + KDE.
In our situation it's not so easy to say server or client. We're running remote desktops over nx-libs, so, a server is also a client at the same time.
I always new EPEL is not perfect but it was usable to some degree and that's why Red Hat told their customers about it and how to use it. But the current state of EPEL is sad.
EPEL is a volunteer driven repository and not many volunteers have been available for EL8. Many of the past volunteers have retired or been promoted out of positions they actually have time to do the work anymore. Asking for replacements is not easy because most people who are interested in EPEL just want the packages built. They have no want or clue to do the work themselves and want someone else to do the work for them. This leads to a lot of people expecting packages without anyone doing the work.
I know what you mean but my case is a bit different. For ~ two decades I'm using Red Hat based distributions and built a large number of packages. There are even packages in RHEL which they took over from me with my permission. I'm maintaining quite a number of packages which sometimes also exist in EPEL but I always keep them up to date and available with the same version on all Red Hat based distributions of the past, even after EOL. Many of the packages are available as SRPMs to those interested. Usually we didn't use any critical package from EPEL because of the state of support it has. But it was handy to consume some slowly changing things like XFCE from EPEL. To find out now that even such things are now in a bad state is a bit sad.
Simon
On Thu, 11 Feb 2021 at 13:39, Simon Matter simon.matter@invoca.ch wrote:
On Thu, 11 Feb 2021 at 12:31, Simon Matter simon.matter@invoca.ch
wrote:
Le 11/02/2021 à 17:08, Simon Matter a écrit :
But, I'm a bit shocked to find EPEL 8 in such a bad shape of
brokenness
and incompleteness
I've come to the same conclusion.
For the past couple years, my solution has been to use RHEL clones
(CentOS
and Oracle Linux) on servers only (multi-user.target).
I've moved all my graphical installations (workstation, laptops,
desktop
clients) to OpenSUSE Leap + KDE.
In our situation it's not so easy to say server or client. We're running remote desktops over nx-libs, so, a server is also a client at the same time.
I always new EPEL is not perfect but it was usable to some degree and that's why Red Hat told their customers about it and how to use it. But the current state of EPEL is sad.
EPEL is a volunteer driven repository and not many volunteers have been available for EL8. Many of the past volunteers have retired or been promoted out of positions they actually have time to do the work anymore. Asking for replacements is not easy because most people who are
interested
in EPEL just want the packages built. They have no want or clue to do the work themselves and want someone else to do the work for them. This leads to a lot of people expecting packages without anyone doing the work.
I know what you mean but my case is a bit different. For ~ two decades I'm using Red Hat based distributions and built a large number of packages. There are even packages in RHEL which they took over from me with my permission. I'm maintaining quite a number of packages which sometimes also exist in EPEL but I always keep them up to date and available with the same version on all Red Hat based distributions of the past, even after EOL. Many of the packages are available as SRPMs to those interested. Usually we didn't use any critical package from EPEL because of the state of support it has. But it was handy to consume some slowly changing things like XFCE from EPEL. To find out now that even such things are now in a bad state is a bit sad.
My apologies, you did not deserve the rant, but the word 'sad' seems to make me see red. I have been told things were 'sad' for EPEL from May of 2019 until now over and over again. Unlike you, most of the people are ones who never volunteered a package but thought it was a 'given' that EPEL would have all their packages for them. After more than a year of it.. it is a tick and I should count to 100 before replying versus 50.
In the end, it is a bad state of affairs, but I also think that it is how things are going. There are a LOT of people who seem to expect that this is all for them FREE and that they can make as many demands as they want. That tires out volunteers and eventually you end up with what happened to all the previous 3rd party repositories.. the volunteers stop showing up to help out. So without a reason for people to volunteer or someone paying the 4+ people needed to do the work day in and day out, the repositories end up in a bad state.
On Thu, 11 Feb 2021 at 13:39, Simon Matter simon.matter@invoca.ch wrote:
On Thu, 11 Feb 2021 at 12:31, Simon Matter simon.matter@invoca.ch
wrote:
Le 11/02/2021 à 17:08, Simon Matter a écrit :
But, I'm a bit shocked to find EPEL 8 in such a bad shape of
brokenness
and incompleteness
I've come to the same conclusion.
For the past couple years, my solution has been to use RHEL clones
(CentOS
and Oracle Linux) on servers only (multi-user.target).
I've moved all my graphical installations (workstation, laptops,
desktop
clients) to OpenSUSE Leap + KDE.
In our situation it's not so easy to say server or client. We're
running
remote desktops over nx-libs, so, a server is also a client at the
same
time.
I always new EPEL is not perfect but it was usable to some degree and that's why Red Hat told their customers about it and how to use it.
But
the current state of EPEL is sad.
EPEL is a volunteer driven repository and not many volunteers have
been
available for EL8. Many of the past volunteers have retired or been promoted out of positions they actually have time to do the work
anymore.
Asking for replacements is not easy because most people who are
interested
in EPEL just want the packages built. They have no want or clue to do
the
work themselves and want someone else to do the work for them. This
leads
to a lot of people expecting packages without anyone doing the work.
I know what you mean but my case is a bit different. For ~ two decades I'm using Red Hat based distributions and built a large number of packages. There are even packages in RHEL which they took over from me with my permission. I'm maintaining quite a number of packages which sometimes also exist in EPEL but I always keep them up to date and available with the same version on all Red Hat based distributions of the past, even after EOL. Many of the packages are available as SRPMs to those interested. Usually we didn't use any critical package from EPEL because of the state of support it has. But it was handy to consume some slowly changing things like XFCE from EPEL. To find out now that even such things are now in a bad state is a bit sad.
My apologies, you did not deserve the rant, but the word 'sad' seems to make me see red. I have been told things were 'sad' for EPEL from May of
I didn't know others also called the current state 'sad' but that's what came to my mind when thinking about it.
2019 until now over and over again. Unlike you, most of the people are ones who never volunteered a package but thought it was a 'given' that EPEL would have all their packages for them. After more than a year of it.. it is a tick and I should count to 100 before replying versus 50.
In the end, it is a bad state of affairs, but I also think that it is how things are going. There are a LOT of people who seem to expect that this is all for them FREE and that they can make as many demands as they want. That tires out volunteers and eventually you end up with what happened to all the previous 3rd party repositories.. the volunteers stop showing up to help out. So without a reason for people to volunteer or someone paying the 4+ people needed to do the work day in and day out, the repositories end up in a bad state.
I'm just wondering why Red Hat as a company doesn't care more about what their paying customers get when using packages not found in RHEL. I think it's the worst experience of all compared to their competitors like Debian, Ubuntu or OpenSUSE. I'm quite sure this will drive more people away from RHEL in future than they think today.
Simon
On Thu, Feb 11, 2021 at 05:18:19PM +0100, Nicolas Kovacs wrote:
Le 11/02/2021 à 17:08, Simon Matter a écrit :
But, I'm a bit shocked to find EPEL 8 in such a bad shape of brokenness and incompleteness
I've come to the same conclusion.
For the past couple years, my solution has been to use RHEL clones (CentOS and Oracle Linux) on servers only (multi-user.target).
I've moved all my graphical installations (workstation, laptops, desktop clients) to OpenSUSE Leap + KDE.
Its mostly fine if you use GNOME on RHEL/CentOS. They're packaged by Red Hat, they accept bug reports about issues and stuff like missing dependencies are worked out pretty quickly.
In my experience, Red Hat doesn't do a ton of Desktop testing, they lean on Fedora ironing out all the bugs and lifting the fixes from there.
Almost all of my bugs filed against desktop-related issues are either dropped as WONTFIX or are fixed when RHEL bumps their GNOME version to a newer release. For example: https://bugzilla.redhat.com/show_bug.cgi?id=1365967
It's too bad that RH doesn't really have much focus on Desktop/Workstation systems, because an enteprise workstation is actually a useful thing for people who need long term support (1-2 years at least) of a workstation. Ubuntu manages to do it, but unfortunately, most of our engineering software isn't supported on Ubuntu.
On 2/11/21 11:18 AM, Nicolas Kovacs wrote:
For the past couple years, my solution has been to use RHEL clones (CentOS and Oracle Linux) on servers only (multi-user.target). I've moved all my graphical installations (workstation, laptops, desktop clients) to OpenSUSE Leap + KDE.
For a really long time I was pretty successful in running EL on both the desktop and the server. It HAS been getting way harder to do this. The EPEL, ELrepo, and RPMfusion repositories do a fantastic job overall, but there were way too many things missing from EPEL8 especially where the desktop experience was becoming a pretty sizable drain on my time building the packages I needed from Fedora. KiCAD and Sigrok were the toughest.
I greatly prefer running the same OS version on my desktops and servers; makes management a lot easier. So this is part of why I am in the midst of evaluating a wholesale migration to Debian 10. On the server it works well, if somewhat different in setup; on the desktop it works so much better, with a huge and maintained repository, where I haven't had to dip into a PPA but once, and that was for a quick one-off package. It's in the virtualization arena where I am gobsmacked; I'm evaluating Proxmox, which is based on Debian 10, using the no-subscription repositories. Let me tell you, Proxmox has one more slick and highly integrated experience. Relative to running a KVM host with only the stock CentOS 8 cockpit and virt-manager, the Proxmox experience blew me away.
I didn't realize just how much time I was spending finding third-party packages for EL8 until I didn't have to.
Smooge, you know I feel your pain, but becoming a maintainer in EPEL has a pretty high bar (lots of new tools and methods to work with, amongst other things) -- as it SHOULD, given that it's intended as an addon to EL and needs to be very tightly controlled. It's just more difficult to get started these days relative to when anyone could build an rpm as long as they had a copy of Maximum RPM and knew how to drive 'rpm -ba' .... back when building as root in a non-reproducible buildroot wasn't a cardinal sin.....
Smooge, you know I feel your pain, but becoming a maintainer in EPEL has a pretty high bar (lots of new tools and methods to work with, amongst other things) -- as it SHOULD, given that it's intended as an addon to EL and needs to be very tightly controlled. It's just more difficult to get started these days relative to when anyone could build an rpm as long as they had a copy of Maximum RPM and knew how to drive 'rpm -ba' .... back when building as root in a non-reproducible buildroot wasn't a cardinal sin.....
I've just started reading https://fedoraproject.org/wiki/EPEL/FAQ and realized this became a problem which hurts EPEL much more than Fedora.
IMHO it simply got too difficult to maintain packages for quite a number of software tools. It explains why there are so many missing, outdated or dead packages in Fedora and more so in EPEL.
What worries me even more is that things have changed to be worse with every release than becoming better.
Regards, Simon
On Thu, 18 Feb 2021 at 04:47, Simon Matter simon.matter@invoca.ch wrote:
Smooge, you know I feel your pain, but becoming a maintainer in EPEL has a pretty high bar (lots of new tools and methods to work with, amongst other things) -- as it SHOULD, given that it's intended as an addon to EL and needs to be very tightly controlled. It's just more difficult to get started these days relative to when anyone could build an rpm as long as they had a copy of Maximum RPM and knew how to drive 'rpm -ba' .... back when building as root in a non-reproducible buildroot wasn't a cardinal sin.....
I've just started reading https://fedoraproject.org/wiki/EPEL/FAQ and realized this became a problem which hurts EPEL much more than Fedora.
IMHO it simply got too difficult to maintain packages for quite a number of software tools. It explains why there are so many missing, outdated or dead packages in Fedora and more so in EPEL.
What worries me even more is that things have changed to be worse with every release than becoming better.
To put it bluntly, is that there are multiple issues going on:
1. We have a large number of people who have gotten used to someone else doing the work for them and not having to care about the software themselves. In doing so they have this idea that building the software is exactly like it was when they got into computers. [* This isn't a new phenomena] 2. Software gets more complicated and more interdependent to do the many things software consumers expect it to accomplish. 3. Software changes more rapidly because more people are able to work on code and people have this odd thing of deciding that whoever wrote the code last was a complete idiot and this new method/language is much better. [The only time it is funny is the once a week where a git blame shows you that the last idiot was you.] 4. With millions of software consumers, there are millions of 'opinions' of what they need and Linux being a system which allows you to shoot your foot in a billion ways tries to accomplish all of them.
* When I was getting into software in the 1990's there were a lot of people who had been using Unix systems from the 1970's who found 'modern' software to be too complicated to build and coders were out of their minds for adding in such complexity when no one needed an editor more than ed. At the time I thought they were 'joking' but when I went to work at various places I found they were dead serious. The change is that where in the 1990's there were only hundreds of people like that, now there are maybe a low million.
Trying to build large amounts of divergent code and make it stay working is very hard. As much as modules are a bane of my existence, something like them is absolutely necessary for many complicated stacks from desktop software to web applications. Writing basic rpms is even more complicated than in 1999 because there are so many corner cases which have to be dealt with. Writing modules is adding more layers of indirection on top of that because it is trying to keep the Rube Goldberg machine of each individuals 'choices' going.
Frankly unless someone can figure out a way to make the packaging janitorial work sexy enough to have people interested in it.. or people who need this stuff actually pay people to do it.. this is all going to fall apart like all infrastructure which was 'someone else's problem'.
Regards, Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Thu, 18 Feb 2021 at 04:47, Simon Matter simon.matter@invoca.ch wrote:
Smooge, you know I feel your pain, but becoming a maintainer in EPEL
has
a pretty high bar (lots of new tools and methods to work with, amongst other things) -- as it SHOULD, given that it's intended as an addon to EL and needs to be very tightly controlled. It's just more difficult
to
get started these days relative to when anyone could build an rpm as long as they had a copy of Maximum RPM and knew how to drive 'rpm -ba' .... back when building as root in a non-reproducible buildroot wasn't
a
cardinal sin.....
I've just started reading https://fedoraproject.org/wiki/EPEL/FAQ and realized this became a problem which hurts EPEL much more than Fedora.
IMHO it simply got too difficult to maintain packages for quite a number of software tools. It explains why there are so many missing, outdated or dead packages in Fedora and more so in EPEL.
What worries me even more is that things have changed to be worse with every release than becoming better.
To put it bluntly, is that there are multiple issues going on:
- We have a large number of people who have gotten used to someone else
doing the work for them and not having to care about the software themselves. In doing so they have this idea that building the software is exactly like it was when they got into computers. [* This isn't a new phenomena] 2. Software gets more complicated and more interdependent to do the many things software consumers expect it to accomplish. 3. Software changes more rapidly because more people are able to work on code and people have this odd thing of deciding that whoever wrote the code last was a complete idiot and this new method/language is much better. [The only time it is funny is the once a week where a git blame shows you that the last idiot was you.] 4. With millions of software consumers, there are millions of 'opinions' of what they need and Linux being a system which allows you to shoot your foot in a billion ways tries to accomplish all of them.
- When I was getting into software in the 1990's there were a lot of
people who had been using Unix systems from the 1970's who found 'modern' software to be too complicated to build and coders were out of their minds for adding in such complexity when no one needed an editor more than ed. At the time I thought they were 'joking' but when I went to work at various places I found they were dead serious. The change is that where in the 1990's there were only hundreds of people like that, now there are maybe a low million.
Trying to build large amounts of divergent code and make it stay working is very hard. As much as modules are a bane of my existence, something like them is absolutely necessary for many complicated stacks from desktop software to web applications. Writing basic rpms is even more complicated than in 1999 because there are so many corner cases which have to be dealt with. Writing modules is adding more layers of indirection on top of that because it is trying to keep the Rube Goldberg machine of each individuals 'choices' going.
Frankly unless someone can figure out a way to make the packaging janitorial work sexy enough to have people interested in it.. or people who need this stuff actually pay people to do it.. this is all going to fall apart like all infrastructure which was 'someone else's problem'.
Well, unfortunately yes, EPEL is on a good way to go where DAG, ATrpms, NUX, freshrpms and all the others already are.
Ironically, CentOS was the reason for other clones like Scientific Linux to vanish, now CentOS Linux vanishes itself. The same goes with EPEL, it was one nail in the coffin of so many third party repositories, now it seems to go there as well.
What is even more sad is the fact that everybody is now waiting for Navy Linux, Rocky Linux and AlmaLinux to get their huge work done to produce three, technically mostly identical systems. They'll still all lack the same thing which is a good package repository for things not found in RHEL.
Doesn't it mean burning a huge amount of CPU cycles and storage for little additional gain in the end?
Sadly, that's not how open source works best.
On Thu, 18 Feb 2021 at 12:04, Simon Matter simon.matter@invoca.ch wrote:
On Thu, 18 Feb 2021 at 04:47, Simon Matter simon.matter@invoca.ch
wrote:
Smooge, you know I feel your pain, but becoming a maintainer in EPEL
has
a pretty high bar (lots of new tools and methods to work with, amongst other things) -- as it SHOULD, given that it's intended as an addon to EL and needs to be very tightly controlled. It's just more difficult
to
get started these days relative to when anyone could build an rpm as long as they had a copy of Maximum RPM and knew how to drive 'rpm -ba' .... back when building as root in a non-reproducible buildroot wasn't
a
cardinal sin.....
I've just started reading https://fedoraproject.org/wiki/EPEL/FAQ and realized this became a problem which hurts EPEL much more than Fedora.
IMHO it simply got too difficult to maintain packages for quite a number of software tools. It explains why there are so many missing, outdated or dead packages in Fedora and more so in EPEL.
What worries me even more is that things have changed to be worse with every release than becoming better.
To put it bluntly, is that there are multiple issues going on:
- We have a large number of people who have gotten used to someone else
doing the work for them and not having to care about the software themselves. In doing so they have this idea that building the software is exactly like it was when they got into computers. [* This isn't a new phenomena] 2. Software gets more complicated and more interdependent to do the many things software consumers expect it to accomplish. 3. Software changes more rapidly because more people are able to work on code and people have this odd thing of deciding that whoever wrote the code last was a complete idiot and this new method/language is much better. [The only time it is funny is the once a week where a git blame shows you that the last idiot was you.] 4. With millions of software consumers, there are millions of 'opinions' of what they need and Linux being a system which allows you to shoot your foot in a billion ways tries to accomplish all of them.
- When I was getting into software in the 1990's there were a lot of
people who had been using Unix systems from the 1970's who found 'modern' software to be too complicated to build and coders were out of their minds for adding in such complexity when no one needed an editor more than ed. At the time I thought they were 'joking' but when I went to work at various places I found they were dead serious. The change is that where in the 1990's there were only hundreds of people like that, now there are maybe a low million.
Trying to build large amounts of divergent code and make it stay working is very hard. As much as modules are a bane of my existence, something like them is absolutely necessary for many complicated stacks from desktop software to web applications. Writing basic rpms is even more complicated than in 1999 because there are so many corner cases which have to be
dealt
with. Writing modules is adding more layers of indirection on top of that because it is trying to keep the Rube Goldberg machine of each
individuals
'choices' going.
Frankly unless someone can figure out a way to make the packaging janitorial work sexy enough to have people interested in it.. or people who need this stuff actually pay people to do it.. this is all going to fall apart like all infrastructure which was 'someone else's problem'.
Well, unfortunately yes, EPEL is on a good way to go where DAG, ATrpms, NUX, freshrpms and all the others already are.
Many of those ran out of steam because software got more and more complicated, and consumers demanded MORE of it but put less into it. "There is no such thing as a free lunch" but it doesn't seem to stop people assuming there has to be.
Ironically, CentOS was the reason for other clones like Scientific Linux to vanish, now CentOS Linux vanishes itself. The same goes with EPEL, it
CentOS was not the primary reason Scientific Linux (and some other rebuilds) vanished, it was the convenient excuse. The staff who were working on Scientific Linux had continual budget cuts over a decade while also an increase in what people wanted from it. There were several 'your team has been told to retire' before they combined with CentOS. It is a problem that the other past clones ran into and I expect the future ones will also have to grapple. It takes a lot of resources to build an OS even if it is recompiling the source code others made available to you. Without a constant renewal and growth of those resources, the people volunteering (or even being paid) to do the work run out of steam and the projects eventually look to combine to get more people.
was one nail in the coffin of so many third party repositories, now it seems to go there as well.
What is even more sad is the fact that everybody is now waiting for Navy Linux, Rocky Linux and AlmaLinux to get their huge work done to produce three, technically mostly identical systems. They'll still all lack the same thing which is a good package repository for things not found in RHEL.
Doesn't it mean burning a huge amount of CPU cycles and storage for little additional gain in the end?
Sadly, that's not how open source works best.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 2/11/21 2:13 PM, Lamar Owen wrote:
On 2/11/21 11:18 AM, Nicolas Kovacs wrote:
For the past couple years, my solution has been to use RHEL clones (CentOS and Oracle Linux) on servers only (multi-user.target). I've moved all my graphical installations (workstation, laptops, desktop clients) to OpenSUSE Leap + KDE.
For a really long time I was pretty successful in running EL on both the desktop and the server. It HAS been getting way harder to do this. The EPEL, ELrepo, and RPMfusion repositories do a fantastic job overall, but there were way too many things missing from EPEL8 especially where the desktop experience was becoming a pretty sizable drain on my time building the packages I needed from Fedora. KiCAD and Sigrok were the toughest.
I greatly prefer running the same OS version on my desktops and servers; makes management a lot easier. So this is part of why I am in the midst of evaluating a wholesale migration to Debian 10. On the server it works well, if somewhat different in setup; on the desktop it works so much better, with a huge and maintained repository, where I haven't had to dip into a PPA but once, and that was for a quick one-off package. It's in the virtualization arena where I am gobsmacked; I'm evaluating Proxmox, which is based on Debian 10, using the no-subscription repositories. Let me tell you, Proxmox has one more slick and highly integrated experience. Relative to running a KVM host with only the stock CentOS 8 cockpit and virt-manager, the Proxmox experience blew me away.
I didn't realize just how much time I was spending finding third-party packages for EL8 until I didn't have to.
Smooge, you know I feel your pain, but becoming a maintainer in EPEL has a pretty high bar (lots of new tools and methods to work with, amongst other things) -- as it SHOULD, given that it's intended as an addon to EL and needs to be very tightly controlled. It's just more difficult to get started these days relative to when anyone could build an rpm as long as they had a copy of Maximum RPM and knew how to drive 'rpm -ba' .... back when building as root in a non-reproducible buildroot wasn't a cardinal sin.....
Not that it matters .. BUT .. EL8 is much harder to build for. There are modular components, not all the Devel files exist, etc.
It is much harder than EL7.
Smooge, you know I feel your pain, but becoming a maintainer in EPEL has a pretty high bar (lots of new tools and methods to work with, amongst other things) -- as it SHOULD, given that it's intended as an addon to EL and needs to be very tightly controlled. It's just more difficult to get started these days relative to when anyone could build an rpm as long as they had a copy of Maximum RPM and knew how to drive 'rpm -ba' .... back when building as root in a non-reproducible buildroot wasn't a cardinal sin.....
Not that it matters .. BUT .. EL8 is much harder to build for. There are modular components, not all the Devel files exist, etc.
It is much harder than EL7.
Thanks Johnny for reminding. I was wondering why the situation for EL8 is so much worse than for EL7 and that was true before CentOS Stream came up.
In the end I have never been happy with the new modules system and how it makes packaging much more difficult than it was and than it should be.
IMHO the hurdles to build high quality packages should be as simple as possible but the difficulties to do so went in the wrong direction. The result we see now. Today we have an unstable distribution (Fedora) with a quite good and comprehensive package set, and we have stable (EL) with an unstable and lacking package set.
Simon
On Thu, 25 Feb 2021 at 02:11, Simon Matter simon.matter@invoca.ch wrote:
Smooge, you know I feel your pain, but becoming a maintainer in EPEL has a pretty high bar (lots of new tools and methods to work with, amongst other things) -- as it SHOULD, given that it's intended as an addon to EL and needs to be very tightly controlled. It's just more difficult to get started these days relative to when anyone could build an rpm as long as they had a copy of Maximum RPM and knew how to drive 'rpm -ba' .... back when building as root in a non-reproducible buildroot wasn't a cardinal sin.....
Not that it matters .. BUT .. EL8 is much harder to build for. There are modular components, not all the Devel files exist, etc.
It is much harder than EL7.
Thanks Johnny for reminding. I was wondering why the situation for EL8 is so much worse than for EL7 and that was true before CentOS Stream came up.
In the end I have never been happy with the new modules system and how it makes packaging much more difficult than it was and than it should be.
IMHO the hurdles to build high quality packages should be as simple as possible but the difficulties to do so went in the wrong direction. The result we see now. Today we have an unstable distribution (Fedora) with a quite good and comprehensive package set, and we have stable (EL) with an unstable and lacking package set.
Even without modules (A person wrote a program which undid some of those problems for us in EPEL), EL8 is not easy to build. Packages and software themselves have gotten more interdependent and complex. This leads to a larger and larger chain of 'buildrequires' and 'requires' for each package. To get some of the XFCE packages into EPEL you need to bring into EPEL all kinds of quaternary packages so you can build the tertiary packages which are needed for the secondary packages which allow you to get something like xfce4-cpufreq-plugin-1.2.1-7.fc33.src.rpm built. Each of those packages needs a maintainer who wants to deal with them in EPEL which requires them to run an EL to test.
I tried an experiment during the RHEL-8 beta to see what it would take to get EPEL-8 1:1 with EPEL-7.. I gave up after adding nearly a thousand packages to the 'build chain' which were not in EPEL-7 nor even in the RHEL-8 beta or its 'buildroot'. These were mainly packages that are in Fedora already and would need to be maintained in EPEL and no one wants to do that.
This was supposed to be a problem modularity was to fix.. so you need 100 packages not in EPEL for your 1 application set, and you don't want to maintain those extra packages? Just put them inside your module build chain and deliver what you wanted. Of course that is still a monumental task and most packagers would say 'meh I got better things to do, like do a root canal without anesthesia.'
Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Thu, Feb 25, 2021 at 7:31 AM Stephen John Smoogen smooge@gmail.com wrote:
On Thu, 25 Feb 2021 at 02:11, Simon Matter simon.matter@invoca.ch wrote:
Smooge, you know I feel your pain, but becoming a maintainer in EPEL
has
a pretty high bar (lots of new tools and methods to work with, amongst other things) -- as it SHOULD, given that it's intended as an addon to EL and needs to be very tightly controlled. It's just more difficult
to
get started these days relative to when anyone could build an rpm as long as they had a copy of Maximum RPM and knew how to drive 'rpm -ba' .... back when building as root in a non-reproducible buildroot
wasn't a
cardinal sin.....
Not that it matters .. BUT .. EL8 is much harder to build for. There are modular components, not all the Devel files exist, etc.
It is much harder than EL7.
Thanks Johnny for reminding. I was wondering why the situation for EL8 is so much worse than for EL7 and that was true before CentOS Stream came
up.
In the end I have never been happy with the new modules system and how it makes packaging much more difficult than it was and than it should be.
IMHO the hurdles to build high quality packages should be as simple as possible but the difficulties to do so went in the wrong direction. The result we see now. Today we have an unstable distribution (Fedora) with a quite good and comprehensive package set, and we have stable (EL) with an unstable and lacking package set.
Even without modules (A person wrote a program which undid some of those problems for us in EPEL), EL8 is not easy to build. Packages and software themselves have gotten more interdependent and complex. This leads to a larger and larger chain of 'buildrequires' and 'requires' for each package. To get some of the XFCE packages into EPEL you need to bring into EPEL all kinds of quaternary packages so you can build the tertiary packages which are needed for the secondary packages which allow you to get something like xfce4-cpufreq-plugin-1.2.1-7.fc33.src.rpm built. Each of those packages needs a maintainer who wants to deal with them in EPEL which requires them to run an EL to test.
I tried an experiment during the RHEL-8 beta to see what it would take to get EPEL-8 1:1 with EPEL-7.. I gave up after adding nearly a thousand packages to the 'build chain' which were not in EPEL-7 nor even in the RHEL-8 beta or its 'buildroot'. These were mainly packages that are in Fedora already and would need to be maintained in EPEL and no one wants to do that.
This was supposed to be a problem modularity was to fix.. so you need 100 packages not in EPEL for your 1 application set, and you don't want to maintain those extra packages? Just put them inside your module build chain and deliver what you wanted. Of course that is still a monumental task and most packagers would say 'meh I got better things to do, like do a root canal without anesthesia.'
Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-- Stephen J Smoogen. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Does package building for debian and derivatives not run into this same issue of interdependency? Is it because they have more packages to begin with? Not judging, I'm curious.
Tony Schreiner
On Thu, Feb 25, 2021 at 7:31 AM Stephen John Smoogen smooge@gmail.com wrote:
On Thu, 25 Feb 2021 at 02:11, Simon Matter simon.matter@invoca.ch wrote:
Smooge, you know I feel your pain, but becoming a maintainer in
EPEL has
a pretty high bar (lots of new tools and methods to work with,
amongst
other things) -- as it SHOULD, given that it's intended as an addon
to
EL and needs to be very tightly controlled. It's just more
difficult to
get started these days relative to when anyone could build an rpm
as
long as they had a copy of Maximum RPM and knew how to drive 'rpm
-ba'
.... back when building as root in a non-reproducible buildroot
wasn't a
cardinal sin.....
Not that it matters .. BUT .. EL8 is much harder to build for.
There
are modular components, not all the Devel files exist, etc.
It is much harder than EL7.
Thanks Johnny for reminding. I was wondering why the situation for EL8
is
so much worse than for EL7 and that was true before CentOS Stream came
up.
In the end I have never been happy with the new modules system and how
it
makes packaging much more difficult than it was and than it should be.
IMHO the hurdles to build high quality packages should be as simple as possible but the difficulties to do so went in the wrong direction.
The
result we see now. Today we have an unstable distribution (Fedora)
with a
quite good and comprehensive package set, and we have stable (EL) with
an
unstable and lacking package set.
Even without modules (A person wrote a program which undid some of those problems for us in EPEL), EL8 is not easy to build. Packages and software themselves have gotten more interdependent and complex. This leads to a larger and larger chain of 'buildrequires' and 'requires' for each package. To get some of the XFCE packages into EPEL you need to bring into EPEL all kinds of quaternary packages so you can build the tertiary packages which are needed for the secondary packages which allow you to get something like xfce4-cpufreq-plugin-1.2.1-7.fc33.src.rpm built. Each of those packages needs a maintainer who wants to deal with them in EPEL which requires them to run an EL to test.
I tried an experiment during the RHEL-8 beta to see what it would take to get EPEL-8 1:1 with EPEL-7.. I gave up after adding nearly a thousand packages to the 'build chain' which were not in EPEL-7 nor even in the RHEL-8 beta or its 'buildroot'. These were mainly packages that are in Fedora already and would need to be maintained in EPEL and no one wants to do that.
This was supposed to be a problem modularity was to fix.. so you need 100 packages not in EPEL for your 1 application set, and you don't want to maintain those extra packages? Just put them inside your module build chain and deliver what you wanted. Of course that is still a monumental task and most packagers would say 'meh I got better things to do, like do a root canal without anesthesia.'
Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-- Stephen J Smoogen. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Does package building for debian and derivatives not run into this same issue of interdependency? Is it because they have more packages to begin with? Not judging, I'm curious.
Tony Schreiner
Both Debian and Fedora have a much larger package base and try to keep those alive step by step.
EL on the other side has a very limited, supported package set and therefore a lot of packages needed to build a lot of packages are just missing.
It's my impression that most development power goes into the limited base system and cloud, container and all the newer fancy stuff.
Simon
Il 2021-02-25 14:27 Simon Matter ha scritto:
EL on the other side has a very limited, supported package set and therefore a lot of packages needed to build a lot of packages are just missing.
Yeah, same impressions here. EPEL really is a key package repository for RHEL - and I always wondered why they did not invest into maintaining (and extending) this excellent repo.
I think RH now is extremely focused on cloud and SaaS platform, which leave us "normal" sysadmin in an uncomfortable situation...
Regards.
On 2/25/21 3:09 PM, Gionatan Danti wrote:
Il 2021-02-25 14:27 Simon Matter ha scritto:
EL on the other side has a very limited, supported package set and therefore a lot of packages needed to build a lot of packages are just missing.
Yeah, same impressions here. EPEL really is a key package repository for RHEL - and I always wondered why they did not invest into maintaining (and extending) this excellent repo.
How about this reason. Paid customers when have issue place support call, and their issue MUST be resolved promptly, it is part of contract with RedHat. To maintain as vast number of stuff as EPEL contains will require RedHat to charge customers proportionally higher, whereas these have only slim base of paid customers who use them.
Just a guess.
Whatever RedHat was doing [in the past] they knew how to do the business (until recently when they were bough out as a result of poor decisions - or maybe because they were doing business really well).
Valeri
I think RH now is extremely focused on cloud and SaaS platform, which leave us "normal" sysadmin in an uncomfortable situation...
Regards.
On Thu, 25 Feb 2021 at 16:10, Gionatan Danti g.danti@assyoma.it wrote:
Il 2021-02-25 14:27 Simon Matter ha scritto:
EL on the other side has a very limited, supported package set and therefore a lot of packages needed to build a lot of packages are just missing.
Yeah, same impressions here. EPEL really is a key package repository for RHEL - and I always wondered why they did not invest into maintaining (and extending) this excellent repo.
Mainly because customers don't want to pay for that work which is considerable. If Red Hat builds it, it is expected to have all kinds of 'promises' equivalent to its other products and that is expensive in terms of QA, engineering, documentation, various certifications, etc. Package growth goes up quickly so if people are complaining about the cost of a RHEL license for 4000 src rpms, then what would it be at 20,000 to 30,000. It is easier to allow the community to choose to do the work it wants and then 'consumers' of said repository get what they can.
I think RH now is extremely focused on cloud and SaaS platform, which leave us "normal" sysadmin in an uncomfortable situation...
I think the industry is entering another crux point where 'classical' system administration will be in the same class as mainframe/miniframe system administration were in the late 1980's and early 1990's with Unix systems and then Linux. Our wor will remain incredibly important to various industries but it will increasingly be a smaller amount of 'total deployments'. Which is why so many of our conversations echo so much of the USEnet in the early-1990s, where mainframes/miniframes admins wondered why companies were not focusing on their industries anymore.
Regards.
-- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8 _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Il 2021-02-25 22:35 Stephen John Smoogen ha scritto:
Mainly because customers don't want to pay for that work which is considerable. If Red Hat builds it, it is expected to have all kinds of 'promises' equivalent to its other products and that is expensive in terms of QA, engineering, documentation, various certifications, etc. Package growth goes up quickly so if people are complaining about the cost of a RHEL license for 4000 src rpms, then what would it be at 20,000 to 30,000. It is easier to allow the community to choose to do the work it wants and then 'consumers' of said repository get what they can.
[Including Valeri] I doubt it. Price is mainly defined by offer and demand (which is, in turn, driven by how much value the customer put behind the product). While production/support cost can put a lower bound on it, I don't think this is the case for Red Hat.
Anyway, Red Hat did not have to supporto EPEL packages the same as core one - even a best effort support would be enough in many cases. The point is that EPEL does not only contains nice-to-have packages, but sometimes provide really important packages.
As an (outdated) example, a decade ago Cyrus with mysql backend was only provided by EPEL. For a more up-to-date example, consider how difficult is to run a "plain" CentOS 7 system - it misses monit, mbuffer, smem, x2go, various Perl modules, etc.
You EPEL volunteers do an outstanding works - I would really than for all you did (free of charge) for the CentOS community. Red Hat should recognize and support your works.
I think the industry is entering another crux point where 'classical' system administration will be in the same class as mainframe/miniframe system administration were in the late 1980's and early 1990's with Unix systems and then Linux. Our wor will remain incredibly important to various industries but it will increasingly be a smaller amount of 'total deployments'. Which is why so many of our conversations echo so much of the USEnet in the early-1990s, where mainframes/miniframes admins wondered why companies were not focusing on their industries anymore.
Well, in a sense, the new cloud frenzy is something similar to a "remote mainframe" used with a new type of thin client (the browser). Yeah, I know this is a very stretched analogy...
I should say that I saw so many services deployed "to the cloud" that are plain broken/misbehaving that it sometime worries me. My (naive?) impression is that we are switching from "few specific services which correctly work unless something bad happen" to a "mess-which-more-or-happens-to-works but nobody know what to do if it does not" model.
I recently debugged an IPSec tunnel between an on-premise appliace and a Azure VPN services. The on premise appliance has extensive log and inspection tools, while on the Azure side we had litelly *nothing*. An Azure consultant was taken on board to help with specifig Powershell sniplet, to no avail. After 7+ days, a 3rd level Microsoft support engineer change a *private* setting on that VPN gateway service and the tunnel started working correctly.
On another case, a Win2008R2 machine stopped working in a AWS instance. No console, no logs. After 2+ weeks of paid "gold/premium" support from an Amazon enginer, my customer simply decided to detach the virtual disk and to attach it to another machine, reinstallaing the server.
Are we sure this is the way to go?
Don't get me wrong - "the cloud" is the natural places for things as web and mail server. A virtualized domain controller? Mmm... not so much.
But hey - I understand this is not going to change. The very same CentOS switch was done to please the cloud vendors, which will have a more "dynamic" base to rebuild. But I don't like how Red Hat does not simply produce a different product or profile for the cloud needs, rather than actively adding complexity at every layer.
Regards.
On Thu, 25 Feb 2021 at 17:26, Gionatan Danti g.danti@assyoma.it wrote:
Il 2021-02-25 22:35 Stephen John Smoogen ha scritto:
Mainly because customers don't want to pay for that work which is considerable. If Red Hat builds it, it is expected to have all kinds of 'promises' equivalent to its other products and that is expensive in terms of QA, engineering, documentation, various certifications, etc. Package growth goes up quickly so if people are complaining about the cost of a RHEL license for 4000 src rpms, then what would it be at 20,000 to 30,000. It is easier to allow the community to choose to do the work it wants and then 'consumers' of said repository get what they can.
[Including Valeri] I doubt it. Price is mainly defined by offer and demand (which is, in turn, driven by how much value the customer put behind the product). While production/support cost can put a lower bound on it, I don't think this is the case for Red Hat.
The fun part about this doubt is that anyone should be able to prove it right or wrong easily. All it takes is to set up a build system, recompile all the code from Fedora wanted in it, and then offer support contracts to cover work on it. If there is a market for it then they can set the price to cover all 20,000 packages and then find out what is expected by the customer for the prices charged.
On Thu, 25 Feb 2021 at 08:18, Tony Schreiner anthony.schreiner@bc.edu wrote:
On Thu, Feb 25, 2021 at 7:31 AM Stephen John Smoogen smooge@gmail.com wrote:
On Thu, 25 Feb 2021 at 02:11, Simon Matter simon.matter@invoca.ch
wrote:
Smooge, you know I feel your pain, but becoming a maintainer in EPEL
has
a pretty high bar (lots of new tools and methods to work with,
amongst
other things) -- as it SHOULD, given that it's intended as an addon
to
EL and needs to be very tightly controlled. It's just more
difficult
to
get started these days relative to when anyone could build an rpm as long as they had a copy of Maximum RPM and knew how to drive 'rpm
-ba'
.... back when building as root in a non-reproducible buildroot
wasn't a
cardinal sin.....
Not that it matters .. BUT .. EL8 is much harder to build for. There are modular components, not all the Devel files exist, etc.
It is much harder than EL7.
Thanks Johnny for reminding. I was wondering why the situation for EL8
is
so much worse than for EL7 and that was true before CentOS Stream came
up.
In the end I have never been happy with the new modules system and how
it
makes packaging much more difficult than it was and than it should be.
IMHO the hurdles to build high quality packages should be as simple as possible but the difficulties to do so went in the wrong direction. The result we see now. Today we have an unstable distribution (Fedora)
with a
quite good and comprehensive package set, and we have stable (EL) with
an
unstable and lacking package set.
Even without modules (A person wrote a program which undid some of those problems for us in EPEL), EL8 is not easy to build. Packages and software themselves have gotten more interdependent and complex. This leads to a larger and larger chain of 'buildrequires' and 'requires' for each
package.
To get some of the XFCE packages into EPEL you need to bring into EPEL
all
kinds of quaternary packages so you can build the tertiary packages which are needed for the secondary packages which allow you to get something
like
xfce4-cpufreq-plugin-1.2.1-7.fc33.src.rpm built. Each of those packages needs a maintainer who wants to deal with them in EPEL which requires
them
to run an EL to test.
I tried an experiment during the RHEL-8 beta to see what it would take to get EPEL-8 1:1 with EPEL-7.. I gave up after adding nearly a thousand packages to the 'build chain' which were not in EPEL-7 nor even in the RHEL-8 beta or its 'buildroot'. These were mainly packages that are in Fedora already and would need to be maintained in EPEL and no one wants
to
do that.
This was supposed to be a problem modularity was to fix.. so you need 100 packages not in EPEL for your 1 application set, and you don't want to maintain those extra packages? Just put them inside your module build
chain
and deliver what you wanted. Of course that is still a monumental task
and
most packagers would say 'meh I got better things to do, like do a root canal without anesthesia.'
Does package building for debian and derivatives not run into this same issue of interdependency? Is it because they have more packages to begin with? Not judging, I'm curious.
They run into the same interdependency.. but because they have organically grown their distro every day, those dependencies grew 1 at a time.
For EPEL and other EL repos you have to jump multiple Fedora releases to catch up. So in EL6 we were Fedora Linux 12. In EL7.0 we had to jump and rebuild from scratch a lot of Fedora Linux 18 and Fedora Linux 19 and then progressed up to about Fedora 24 as various parts got rebased and upgraded to 7.9. For EL8, we have to jump to Fedora Linux 28 and then each dot release rebase parts while keeping other parts back because rebasing is focused. [This means that if something needs glibc-2.32 you can't put it in EL8 without a lot of patching to make it work with whatever changed... but some other related components may be able to recompile fine.]
Thus you need people who enjoy that kind of work to do this because EPEL is nearly all volunteer work. I had to work after hours or take vacation time to work on getting EPEL-8 out so that I could get focused effort on it. Most people don't have that 'luxury' and so the number of volunteers is small but the expectation that it will be there is large.
Tony Schreiner _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 25/02/2021 13:37, Stephen John Smoogen wrote: <snip>
They run into the same interdependency.. but because they have organically grown their distro every day, those dependencies grew 1 at a time.
For EPEL and other EL repos you have to jump multiple Fedora releases to catch up. So in EL6 we were Fedora Linux 12. In EL7.0 we had to jump and rebuild from scratch a lot of Fedora Linux 18 and Fedora Linux 19 and then progressed up to about Fedora 24 as various parts got rebased and upgraded to 7.9. For EL8, we have to jump to Fedora Linux 28 and then each dot release rebase parts while keeping other parts back because rebasing is focused. [This means that if something needs glibc-2.32 you can't put it in EL8 without a lot of patching to make it work with whatever changed... but some other related components may be able to recompile fine.]
Thus you need people who enjoy that kind of work to do this because EPEL is nearly all volunteer work. I had to work after hours or take vacation time to work on getting EPEL-8 out so that I could get focused effort on it. Most people don't have that 'luxury' and so the number of volunteers is small but the expectation that it will be there is large.
Tony Schreiner _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
I was recently looking at Raymond's book "The Art of UNIX Programming" from 2003. He, along with contributors Thompson (inventor of UNIX), Kernigham (C and AWK), Korn and others of that callibre, espouse creating "little tools" that do one job reliably and well. The likes of Gnome or systemd certainly would never fit into this philosophy. I really think we have lost a lot of maintainability and ease of management over the last 20 years as applications are stretched to do ever more.
On 25/02/2021 13:37, Stephen John Smoogen wrote:
<snip> > They run into the same interdependency.. but because they have > organically > grown their distro every day, those dependencies grew 1 at a time. > > For EPEL and other EL repos you have to jump multiple Fedora releases to > catch up. So in EL6 we were Fedora Linux 12. In EL7.0 we had to jump and > rebuild from scratch a lot of Fedora Linux 18 and Fedora Linux 19 and > then > progressed up to about Fedora 24 as various parts got rebased and > upgraded > to 7.9. For EL8, we have to jump to Fedora Linux 28 and then each dot > release rebase parts while keeping other parts back because rebasing is > focused. [This means that if something needs glibc-2.32 you can't put it > in > EL8 without a lot of patching to make it work with whatever changed... > but > some other related components may be able to recompile fine.] > > Thus you need people who enjoy that kind of work to do this because EPEL > is > nearly all volunteer work. I had to work after hours or take vacation > time > to work on getting EPEL-8 out so that I could get focused effort on it. > Most people don't have that 'luxury' and so the number of volunteers is > small but the expectation that it will be there is large. > > > >> Tony Schreiner >> _______________________________________________ >> CentOS mailing list >> CentOS@centos.org >> https://lists.centos.org/mailman/listinfo/centos >> > > I was recently looking at Raymond's book "The Art of UNIX Programming" from 2003. He, along with contributors Thompson (inventor of UNIX), Kernigham (C and AWK), Korn and others of that callibre, espouse creating "little tools" that do one job reliably and well. The likes of Gnome or systemd certainly would never fit into this philosophy. I really think we have lost a lot of maintainability and ease of management over the last 20 years as applications are stretched to do ever more. -- J Martin Rushton MBCS
Or you can say it with Henry Spencers words:
Those who don't understand Unix are condemned to reinvent it, poorly.
On 2/25/21 8:28 AM, Simon Matter wrote:
On 25/02/2021 13:37, Stephen John Smoogen wrote:
<snip> > They run into the same interdependency.. but because they have > organically > grown their distro every day, those dependencies grew 1 at a time. > > For EPEL and other EL repos you have to jump multiple Fedora releases to > catch up. So in EL6 we were Fedora Linux 12. In EL7.0 we had to jump and > rebuild from scratch a lot of Fedora Linux 18 and Fedora Linux 19 and > then > progressed up to about Fedora 24 as various parts got rebased and > upgraded > to 7.9. For EL8, we have to jump to Fedora Linux 28 and then each dot > release rebase parts while keeping other parts back because rebasing is > focused. [This means that if something needs glibc-2.32 you can't put it > in > EL8 without a lot of patching to make it work with whatever changed... > but > some other related components may be able to recompile fine.] > > Thus you need people who enjoy that kind of work to do this because EPEL > is > nearly all volunteer work. I had to work after hours or take vacation > time > to work on getting EPEL-8 out so that I could get focused effort on it. > Most people don't have that 'luxury' and so the number of volunteers is > small but the expectation that it will be there is large. > > > >> Tony Schreiner >> _______________________________________________ >> CentOS mailing list >> CentOS@centos.org >> https://lists.centos.org/mailman/listinfo/centos >> > > I was recently looking at Raymond's book "The Art of UNIX Programming" from 2003. He, along with contributors Thompson (inventor of UNIX), Kernigham (C and AWK), Korn and others of that callibre, espouse creating "little tools" that do one job reliably and well. The likes of Gnome or systemd certainly would never fit into this philosophy. I really think we have lost a lot of maintainability and ease of management over the last 20 years as applications are stretched to do ever more. -- J Martin Rushton MBCS
Or you can say it with Henry Spencers words:
Those who don't understand Unix are condemned to reinvent it, poorly.
Alas, the whole thing stems from more global trend. The world became ruled pretty much on all levels by bureaucrats. They have no real knowledge or hands on experience in the field they rule. The paradigm for them is: they can find and hire (and replace on the whim) those who will do actual job. Without knowledge the only way they can select whom to hire is by looking at the number of certificates.Those are abundant mostly in relation to MS products.The judgement of how well systems are maintained is based on checked boxes in questionnaires such as "is antivirus installed?" (which is irrelevant to UNIX, Linux or MacOS systems)... And, of course, they are willing the "anti-virus style" scanner run [with root privileges] from their [much less secure] box on your UNIX machines. Whereas long ago it was established that anti-virus idea is logically flawed: you can not enumerate bad, you can enumerate good and prohibit everything else.
And the list goes on and on...
Which pretty much explains the deficiencies we observe today in the state of the art.
Just my $0.02
Valeri
On Thu, Feb 25, 2021 at 02:12:39PM +0000, J Martin Rushton via CentOS wrote:
I was recently looking at Raymond's book "The Art of UNIX Programming" from 2003. He, along with contributors Thompson (inventor of UNIX), Kernigham (C and AWK), Korn and others of that callibre, espouse creating "little tools" that do one job reliably and well. The likes of Gnome or systemd certainly would never fit into this philosophy. I really think we have lost a lot of maintainability and ease of management over the last 20 years as applications are stretched to do ever more.
If every tool we used were self-contained, build-it-all-from-scratch, our desktops would be a huge mess. Nothing would work with another tool, you'd have widely varying user interfaces, you'd never have something like X11 or Wayland.
Sure, that attitude is fine for command line tools, but a huge part of the open source world is taking advantage of toolkits provided to make life easier for the programmer. The world is a lot more complicated than in the K&R days. When I worked at Princeton, Kernighan was teaching courses using Python (and Go now, I think). (Really cool guy)
Heck, 'systemd' is a really complicated beast, but it doesn't have a huge number of interconnected dependencies. I think bringing it up isn't really appropriate for this thread, since it actually does a pretty good job of keeping the requirements down, so it can run in minimal instances.
On Thu, 25 Feb 2021 at 09:13, J Martin Rushton via CentOS centos@centos.org wrote:
On 25/02/2021 13:37, Stephen John Smoogen wrote:
I was recently looking at Raymond's book "The Art of UNIX Programming" from 2003. He, along with contributors Thompson (inventor of UNIX), Kernigham (C and AWK), Korn and others of that callibre, espouse creating "little tools" that do one job reliably and well. The likes of Gnome or systemd certainly would never fit into this philosophy. I really think we have lost a lot of maintainability and ease of management over the last 20 years as applications are stretched to do ever more.
Maybe but everytime someone says "I think these are too complex" they then turn around and say "but I really need this to do this one more thing." Also the complexity of tools is generational. The oldschool 1970's Unix people were screaming that the 1980's software was too complex because various flags had been added to central commands. The 1980's people complained that even early Linux was too complex because it had so much more software that depended on each other. And so forth.
In the X11 world, there were as many people saying FVWM was way too complex when twm was all you needed and it was making software too hard to build. BUT could you get twm to work on our new monitor which has a different view screen feature that made the fonts look like crap.
The counter argument I heard from a 1970's Unix era person was "Software gets more complicated over time as we find that more problems need to be solved. You either keep up with it, or get out of software." He was working in software until his death a short while ago in his 80's.
-- J Martin Rushton MBCS _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 25/02/2021 14:49, Stephen John Smoogen wrote:
On Thu, 25 Feb 2021 at 09:13, J Martin Rushton via CentOS <centos@centos.org mailto:centos@centos.org> wrote:
On 25/02/2021 13:37, Stephen John Smoogen wrote: I was recently looking at Raymond's book "The Art of UNIX Programming" from 2003. He, along with contributors Thompson (inventor of UNIX), Kernigham (C and AWK), Korn and others of that callibre, espouse creating "little tools" that do one job reliably and well. The likes of Gnome or systemd certainly would never fit into this philosophy. I really think we have lost a lot of maintainability and ease of management over the last 20 years as applications are stretched to do ever more.Maybe but everytime someone says "I think these are too complex" they then turn around and say "but I really need this to do this one more thing." Also the complexity of tools is generational. The oldschool 1970's Unix people were screaming that the 1980's software was too complex because various flags had been added to central commands. The 1980's people complained that even early Linux was too complex because it had so much more software that depended on each other. And so forth.
In the X11 world, there were as many people saying FVWM was way too complex when twm was all you needed and it was making software too hard to build. BUT could you get twm to work on our new monitor which has a different view screen feature that made the fonts look like crap.
The counter argument I heard from a 1970's Unix era person was "Software gets more complicated over time as we find that more problems need to be solved. You either keep up with it, or get out of software." He was working in software until his death a short while ago in his 80's.
-- J Martin Rushton MBCS _______________________________________________ CentOS mailing list CentOS@centos.org <mailto:CentOS@centos.org> https://lists.centos.org/mailman/listinfo/centos <https://lists.centos.org/mailman/listinfo/centos>-- Stephen J Smoogen.
The irony being that moving to UNIX I had it drummed into me that the one tool-one job ethos was a great advance upon the rigidly defined and integrated monolith of VMS. Oh, and that was in the 1990s.
On Thu, 25 Feb 2021 at 10:07, J Martin Rushton < martinrushton56@btinternet.com> wrote:
On 25/02/2021 14:49, Stephen John Smoogen wrote:
On Thu, 25 Feb 2021 at 09:13, J Martin Rushton via CentOS <centos@centos.org mailto:centos@centos.org> wrote:
On 25/02/2021 13:37, Stephen John Smoogen wrote: I was recently looking at Raymond's book "The Art of UNIXProgramming"
from 2003. He, along with contributors Thompson (inventor of UNIX), Kernigham (C and AWK), Korn and others of that callibre, espouse creating "little tools" that do one job reliably and well. The likes of Gnome or systemd certainly would never fit into this philosophy. I really think we have lost a lot of maintainability and ease of management over the last 20 years as applications are stretched to do ever more.Maybe but everytime someone says "I think these are too complex" they then turn around and say "but I really need this to do this one more thing." Also the complexity of tools is generational. The oldschool 1970's Unix people were screaming that the 1980's software was too complex because various flags had been added to central commands. The 1980's people complained that even early Linux was too complex because it had so much more software that depended on each other. And so forth.
In the X11 world, there were as many people saying FVWM was way too complex when twm was all you needed and it was making software too hard to build. BUT could you get twm to work on our new monitor which has a different view screen feature that made the fonts look like crap.
The counter argument I heard from a 1970's Unix era person was "Software gets more complicated over time as we find that more problems need to be solved. You either keep up with it, or get out of software." He was working in software until his death a short while ago in his 80's.
-- J Martin Rushton MBCS _______________________________________________ CentOS mailing list CentOS@centos.org <mailto:CentOS@centos.org> https://lists.centos.org/mailman/listinfo/centos <https://lists.centos.org/mailman/listinfo/centos>-- Stephen J Smoogen.
The irony being that moving to UNIX I had it drummed into me that the one tool-one job ethos was a great advance upon the rigidly defined and integrated monolith of VMS. Oh, and that was in the 1990s. -- J Martin Rushton MBCS
And everyone I worked with told me that Unix was a poor reinvention of TSX-11 where you could get real work done. But since VMS came out over a decade after Unix, I can't say Unix is an advance over VMS.
In any case this is devolving into the 4 Yorkshiremen skit so I am done here.
On 25/02/2021 16:54, Stephen John Smoogen wrote:
On Thu, 25 Feb 2021 at 10:07, J Martin Rushton <martinrushton56@btinternet.com mailto:martinrushton56@btinternet.com> wrote:
On 25/02/2021 14:49, Stephen John Smoogen wrote: > > > On Thu, 25 Feb 2021 at 09:13, J Martin Rushton via CentOS > <centos@centos.org <mailto:centos@centos.org> <mailto:centos@centos.org <mailto:centos@centos.org>>> wrote: > > > > On 25/02/2021 13:37, Stephen John Smoogen wrote: > > I was recently looking at Raymond's book "The Art of UNIX Programming" > from 2003. He, along with contributors Thompson (inventor of UNIX), > Kernigham (C and AWK), Korn and others of that callibre, espouse > creating "little tools" that do one job reliably and well. The > likes of > Gnome or systemd certainly would never fit into this philosophy. I > really think we have lost a lot of maintainability and ease of > management over the last 20 years as applications are stretched to do > ever more. > > > Maybe but everytime someone says "I think these are too complex" they > then turn around and say "but I really need this to do this one more > thing." Also the complexity of tools is generational. The oldschool > 1970's Unix people were screaming that the 1980's software was too > complex because various flags had been added to central commands. The > 1980's people complained that even early Linux was too complex because > it had so much more software that depended on each other. And so forth. > > In the X11 world, there were as many people saying FVWM was way too > complex when twm was all you needed and it was making software too hard > to build. BUT could you get twm to work on our new monitor which has a > different view screen feature that made the fonts look like crap. > > The counter argument I heard from a 1970's Unix era person was "Software > gets more complicated over time as we find that more problems need to be > solved. You either keep up with it, or get out of software." He was > working in software until his death a short while ago in his 80's. > > -- > J Martin Rushton MBCS > _______________________________________________ > CentOS mailing list > CentOS@centos.org <mailto:CentOS@centos.org> <mailto:CentOS@centos.org <mailto:CentOS@centos.org>> > https://lists.centos.org/mailman/listinfo/centos <https://lists.centos.org/mailman/listinfo/centos> > <https://lists.centos.org/mailman/listinfo/centos <https://lists.centos.org/mailman/listinfo/centos>> > > > > -- > Stephen J Smoogen. > The irony being that moving to UNIX I had it drummed into me that the one tool-one job ethos was a great advance upon the rigidly defined and integrated monolith of VMS. Oh, and that was in the 1990s. -- J Martin Rushton MBCSAnd everyone I worked with told me that Unix was a poor reinvention of TSX-11 where you could get real work done. But since VMS came out over a decade after Unix, I can't say Unix is an advance over VMS.
In any case this is devolving into the 4 Yorkshiremen skit so I am done here.
-- Stephen J Smoogen.
Oi! Lay off Yorkshiremen. It'll only be envy that you weren't born one. :-)
Am 25.02.21 um 15:12 schrieb J Martin Rushton via CentOS:
On 25/02/2021 13:37, Stephen John Smoogen wrote:
<snip> > They run into the same interdependency.. but because they have > organically > grown their distro every day, those dependencies grew 1 at a time. > > For EPEL and other EL repos you have to jump multiple Fedora releases to > catch up. So in EL6 we were Fedora Linux 12. In EL7.0 we had to jump and > rebuild from scratch a lot of Fedora Linux 18 and Fedora Linux 19 and > then > progressed up to about Fedora 24 as various parts got rebased and > upgraded > to 7.9. For EL8, we have to jump to Fedora Linux 28 and then each dot > release rebase parts while keeping other parts back because rebasing is > focused. [This means that if something needs glibc-2.32 you can't put > it in > EL8 without a lot of patching to make it work with whatever changed... > but > some other related components may be able to recompile fine.] > > Thus you need people who enjoy that kind of work to do this because > EPEL is > nearly all volunteer work. I had to work after hours or take vacation > time > to work on getting EPEL-8 out so that I could get focused effort on it. > Most people don't have that 'luxury' and so the number of volunteers is > small but the expectation that it will be there is large. > > > >> Tony Schreiner >> _______________________________________________ >> CentOS mailing list >> CentOS@centos.org >> https://lists.centos.org/mailman/listinfo/centos >> > > I was recently looking at Raymond's book "The Art of UNIX Programming" from 2003. He, along with contributors Thompson (inventor of UNIX), Kernigham (C and AWK), Korn and others of that callibre, espouse creating "little tools" that do one job reliably and well. The likes of Gnome or systemd certainly would never fit into this philosophy. I really think we have lost a lot of maintainability and ease of management over the last 20 years as applications are stretched to do ever more.
Well, do "ldd /bin/awk" and you see interconnected dependencies.
I see it the same way and if I want, I would see it the same way with a broader view. Do one job well - interaction with the user, Gnome. Do one job well - when a service is stopped, it is stopped (systemd).
So it depends of the scope of view. Sure, there are tools that try to do everything. One that came into my mind is YasT from SuSE. That one I would classify as not fitting into the common unix philosophy.
-- Leon
On 25/02/2021 18:18, Leon Fauster via CentOS wrote:
Am 25.02.21 um 15:12 schrieb J Martin Rushton via CentOS:
On 25/02/2021 13:37, Stephen John Smoogen wrote:
<snip>
I was recently looking at Raymond's book "The Art of UNIX Programming" from 2003. He, along with contributors Thompson (inventor of UNIX), Kernigham (C and AWK), Korn and others of that callibre, espouse creating "little tools" that do one job reliably and well. The likes of Gnome or systemd certainly would never fit into this philosophy. I really think we have lost a lot of maintainability and ease of management over the last 20 years as applications are stretched to do ever more.
Well, do "ldd /bin/awk" and you see interconnected dependencies.
I see it the same way and if I want, I would see it the same way with a broader view. Do one job well - interaction with the user, Gnome. Do one job well - when a service is stopped, it is stopped (systemd).
So it depends of the scope of view. Sure, there are tools that try to do everything. One that came into my mind is YasT from SuSE. That one I would classify as not fitting into the common unix philosophy.
-- Leon
_______________________________________
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
I don't want to get bogged down in arguments about which application has the most dependencies. It's really a matter of scale. Depending upon a few system libraries is reasonable, but when when the ramifications extend to dozens then perhaps a pause for thought might be suggested? Oh and BTW:
bash-4.2$ ldd /bin/awk linux-vdso.so.1 => (0x00007ffcc876a000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fcd25995000) libm.so.6 => /lib64/libm.so.6 (0x00007fcd25693000) libc.so.6 => /lib64/libc.so.6 (0x00007fcd252c5000) /lib64/ld-linux-x86-64.so.2 (0x00007fcd25b99000) bash-4.2$
-- which seems reasonable to me.
On 25/02/2021 18:18, Leon Fauster via CentOS wrote:
Am 25.02.21 um 15:12 schrieb J Martin Rushton via CentOS:
On 25/02/2021 13:37, Stephen John Smoogen wrote:
<snip>
I was recently looking at Raymond's book "The Art of UNIX Programming" from 2003. He, along with contributors Thompson (inventor of UNIX), Kernigham (C and AWK), Korn and others of that callibre, espouse creating "little tools" that do one job reliably and well. The likes of Gnome or systemd certainly would never fit into this philosophy. I really think we have lost a lot of maintainability and ease of management over the last 20 years as applications are stretched to do ever more.
Well, do "ldd /bin/awk" and you see interconnected dependencies.
I see it the same way and if I want, I would see it the same way with a broader view. Do one job well - interaction with the user, Gnome. Do one job well - when a service is stopped, it is stopped (systemd).
So it depends of the scope of view. Sure, there are tools that try to do everything. One that came into my mind is YasT from SuSE. That one I would classify as not fitting into the common unix philosophy.
-- Leon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
I don't want to get bogged down in arguments about which application has the most dependencies. It's really a matter of scale. Depending upon a few system libraries is reasonable, but when when the ramifications extend to dozens then perhaps a pause for thought might be suggested? Oh and BTW:
bash-4.2$ ldd /bin/awk linux-vdso.so.1 => (0x00007ffcc876a000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fcd25995000) libm.so.6 => /lib64/libm.so.6 (0x00007fcd25693000) libc.so.6 => /lib64/libc.so.6 (0x00007fcd252c5000) /lib64/ld-linux-x86-64.so.2 (0x00007fcd25b99000)
That's on which OS? Certainly not EL8, right?
On 25/02/2021 20:56, Simon Matter wrote:
On 25/02/2021 18:18, Leon Fauster via CentOS wrote:
Am 25.02.21 um 15:12 schrieb J Martin Rushton via CentOS:
On 25/02/2021 13:37, Stephen John Smoogen wrote:
<snip>
I was recently looking at Raymond's book "The Art of UNIX Programming" from 2003. He, along with contributors Thompson (inventor of UNIX), Kernigham (C and AWK), Korn and others of that callibre, espouse creating "little tools" that do one job reliably and well. The likes of Gnome or systemd certainly would never fit into this philosophy. I really think we have lost a lot of maintainability and ease of management over the last 20 years as applications are stretched to do ever more.
Well, do "ldd /bin/awk" and you see interconnected dependencies.
I see it the same way and if I want, I would see it the same way with a broader view. Do one job well - interaction with the user, Gnome. Do one job well - when a service is stopped, it is stopped (systemd).
So it depends of the scope of view. Sure, there are tools that try to do everything. One that came into my mind is YasT from SuSE. That one I would classify as not fitting into the common unix philosophy.
-- Leon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
I don't want to get bogged down in arguments about which application has the most dependencies. It's really a matter of scale. Depending upon a few system libraries is reasonable, but when when the ramifications extend to dozens then perhaps a pause for thought might be suggested? Oh and BTW:
bash-4.2$ ldd /bin/awk linux-vdso.so.1 => (0x00007ffcc876a000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fcd25995000) libm.so.6 => /lib64/libm.so.6 (0x00007fcd25693000) libc.so.6 => /lib64/libc.so.6 (0x00007fcd252c5000) /lib64/ld-linux-x86-64.so.2 (0x00007fcd25b99000)
That's on which OS? Certainly not EL8, right?
C7
On 2/24/21 3:49 PM, Johnny Hughes wrote:
Not that it matters .. BUT .. EL8 is much harder to build for. There are modular components, not all the Devel files exist, etc.
It is much harder than EL7.
And that difficulty shows; more stable perhaps, but many fewer packages. Is there a reference anywhere to how modularity is supposed to work?
On 2/25/21 4:44 PM, Lamar Owen wrote:
On 2/24/21 3:49 PM, Johnny Hughes wrote:
Not that it matters .. BUT .. EL8 is much harder to build for. There are modular components, not all the Devel files exist, etc.
It is much harder than EL7.
And that difficulty shows; more stable perhaps, but many fewer packages. Is there a reference anywhere to how modularity is supposed to work?
From a user perspective or a building perspective?
https://docs.fedoraproject.org/en-US/modularity/using-modules/
On 2/26/21 9:40 AM, Johnny Hughes wrote:
On 2/25/21 4:44 PM, Lamar Owen wrote:
On 2/24/21 3:49 PM, Johnny Hughes wrote:
Not that it matters .. BUT .. EL8 is much harder to build for. There are modular components, not all the Devel files exist, etc.
It is much harder than EL7.
And that difficulty shows; more stable perhaps, but many fewer packages. Is there a reference anywhere to how modularity is supposed to work?
From a user perspective or a building perspective?
https://docs.fedoraproject.org/en-US/modularity/using-modules/
I read this article all the time:
https://computingforgeeks.com/how-to-use-fedora-29-modular-repository/
Am 26.02.21 um 17:23 schrieb Lamar Owen:
On 2/26/21 10:40 AM, Johnny Hughes wrote:
From a user perspective or a building perspective?
Builder.
https://pagure.io/fm-orchestrator
-- Leon
On 2/26/21 11:38 AM, Leon Fauster via CentOS wrote:
What an obvious package name..... :-)
Thanks for the pointer!
On Fri, 26 Feb 2021 09:40:06 -0600 Johnny Hughes johnny@centos.org wrote:
https://docs.fedoraproject.org/en-US/modularity/using-modules/
I find the modularity end-user documentation to be woefully inadequate, especially for developers.
Here are several basic to advanced question that I can’t see answers for on that page. All of this is from the perspective of a user of Fedora or EL, installing and building software for my own use. That page seems aimed at those developing Fedora and using the Fedora build system.
What modules are available, what are they for, and what’s in them?
What streams are available, what are they for, and what’s in them? (https://docs.fedoraproject.org/en-US/modularity/using-modules-switching-stre... says “This page needs to be extended.”)
What profiles are available, what are they for, and what’s in them?
`yum module info` seems to be part of the answer, but it is not in that doc.
I have an RPM installed. Which module and stream is it from? Do other modules also provide it? The same version or different?
What is the modularity equivalent of `yum provides`?
How do I examine the dependecies between modules?
I am trying to build an RPM that BuildRequires something from a module. How do I get mock to do this? What if some of the BuildRequires are private or hidden?
I am trying to patch and rebuild an RPM from a module. How do I do this? How do I access the private BuildRequires?
I am trying to build an RPM that Requires something from a module. How do I make yum automatically install the correct dependency?
I want to provide modules in my private repository. How do I set this up for building and distribution?
How do I install perl-DBD-Pg for perl:5.30 and postgresql:12? If I try it on CentOS 8
yum module enable perl:5.30 postgresql:12 yum module install perl-DBD-Pg
I get some conflicts and the docs do not explain how to resolve them.
Jim
Am 27.02.21 um 16:28 schrieb James Szinger:
On Fri, 26 Feb 2021 09:40:06 -0600 Johnny Hughes johnny@centos.org wrote:
https://docs.fedoraproject.org/en-US/modularity/using-modules/
I find the modularity end-user documentation to be woefully inadequate, especially for developers.
Yep!
Here are several basic to advanced question that I can’t see answers for on that page. All of this is from the perspective of a user of Fedora or EL, installing and building software for my own use. That page seems aimed at those developing Fedora and using the Fedora build system.
What modules are available, what are they for, and what’s in them?
What streams are available, what are they for, and what’s in them? (https://docs.fedoraproject.org/en-US/modularity/using-modules-switching-stre... says “This page needs to be extended.”)
What profiles are available, what are they for, and what’s in them?
`yum module info` seems to be part of the answer, but it is not in that doc.
Just some hints:
Try to read the modulemd repodata. It gives some insights :
$ curl -q http://mirror.centos.org/centos/8/AppStream/x86_64/os/repodata/1e7ee9bec2bcd... | gunzip | less
I have an RPM installed. Which module and stream is it from? Do other modules also provide it? The same version or different?
What is the modularity equivalent of `yum provides`?
dnf module provides
How do I examine the dependecies between modules?
I am trying to build an RPM that BuildRequires something from a module. How do I get mock to do this? What if some of the BuildRequires are private or hidden?
config_opts['module_enable'] = ['python27:2.7']
I am trying to patch and rebuild an RPM from a module. How do I do this? How do I access the private BuildRequires?
Briefly: Modules are defined logically (modulemd). You need to build a repo with modules defined that provide the same stream. This repo overrides the default rpms then via higher NVRA (e.g. EPOCH).
-- Leon
-
Frank Cox -
Gionatan Danti -
J Martin Rushton -
James Szinger -
Johnny Hughes -
Jonathan Billings -
Lamar Owen -
Leon Fauster -
Nicolas Kovacs -
Peter -
Simon Matter -
Stephen John Smoogen -
Tony Schreiner -
Valeri Galtsev