 |
Any news on this? It seems like this package should be in PowerTools? It seems to have been built with the libssh2 package on koji https://koji.mbox.centos.org/koji/buildinfo?buildID=4650 |
|
|
Not only is libssh2-devel missing, but there is also no qemu-system-x86, which I tried to build. qemu-3.0.1 still has a libssh2-devel depends, but qemu-4.1.0 does not. Upstream qemu.git took it out, I believe the responsible developer is from Redhat. https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg02758.html I'm currently packaging upstream xen-4.12.1 and xen-4.13~rc1 for CentOS 8. This is where I ran into this bug report. |
|
|
This is blocking my Copr build of zabbix as well. |
|
|
https://lists.centos.org/pipermail/centos-devel/2019-October/018011.html |
|
|
So. . .how will that impact the availability of libssh2-devel? |
|
|
It should be pretty clear: Starting with RHEL 8.1 it won't be shipped by Red Hat. I guess the reason it's missing now is a screw-up related to this. |
|
|
Thanks. it wasn't clear. So do you think they'll fix it for 8.0, or do we have to wait until 8.1 and add it to EPEL? And people who need it just don't use EL-8 for an entire point release? |
|
|
I found the build for libssh2 so I know there is a devel package that could be published? is there any reason to not publish this to powertools for the point release as it is published in RHEL? otherwise is there any reason not to go ask for the epel package at this time? |
|
|
I don't know, guess you'll have to ask Red Hat's RCM team. |
 |
"Unshipped -devel packages in CentOS Linux" https://lists.centos.org/pipermail/centos-devel/2019-November/018082.html |
|
|
This is _very_ annoying. For example: libuser is needed by passwd, usermode, util-linux-user. So libuser-devel is built (koji) and used when building the above packages. But if I try to use libuser-devel there is no way I can do that. Well, I can, if I re-compile libuser myself. But the list of packages needed to be built keep growing and growing. And -devel packages are not the only ones: Set GRUB_ENABLE_BLSCFG=false in /etc/default/grub, grub2-mkconfig --output=... and try to install a kernel. Nothing is added to /boot/grub2/grub.cfg. Why? Well, if we look in /usr/lib/kernel/install.d/20-grub.install we see that it needs /sbin/new-kernel-pkg. But grubby-deprecated (that provide new-kernel-pkg) is nowhere to be found (except in koji [https://koji.mbox.centos.org/koji/buildinfo?buildID=185]). And, you cannot manually download anything from koji anymore. Same to postfix (postfix-pcre). And many, many other packages. It would be nice to have a repository with the remaining packages build in koji, somewhere... Because I don't want to build and keep tracking for yet another package just to have a sub-package that is already built and not provided to us. In the end, if the list of the missing packages keep growing and we have to build everything by ourself, why use CentOS (RH) in the first place? |
|
|
This issue is a problem. I can't build Rugged Ruby Gem with ssh support. It breaks functionality of Redmine Git Hosting plugin. I'm sure Redmine is not the only Ruby app that suffers from lack of this development package. |
|
|
For me, this is an issue that prevents me from upgrading and puts me in the situation of considering whether to wait it out or choose a different distribution. The packages removed are both build dependencies of source RPMs and being able to compile software against the system libraries / packages. It creates a very hit an miss situation where anyone who compiles their own software, third party software or recompiles OS packages for the system is walking a potential minefield. A holistic fix would really be ideal rather than doing it piece by piece. I considered building some of the missing packages myself but it's far from ideal. Not only in it being a lot of duplicate work but also keeping up to date with upstream updates and also assets in devel packages sometimes result from the build process meaning for optimal compatibility you would want to build and provide all of the packages from the SPEC where not all built packages are shipped. Is there something specific that makes this difficult to address? Is it possible to in the build process compare built to shipped packages and put built but unshipped into another repo? Would it be possible to have a process that detects them, puts them in a private repo by default but then after being checked to see what they are and what they need into the unshipped repo? I've heard some confusion about shipping them as modules. Is there something special that makes this more than simply RPMs missing from repos? Would they not still contain the relevant metadata? Would it be a problem providing them if people start rolling their own already (I'm not sure if in their own repos)? I'm not sure anything other than a holistic fix would really solve the problem. At least one lazy way to get once sense of how much is missing could be to try to install all source rpms in dry run and capture error output about dependencies. It really could do with tooling though. I think that might get a bit extensive. It's possible to figure out missing dependencies integrity checking the tree by traversing it fully (though it might need a small super computer if the full dependency resolution is used). That won't however detect leaf devel packages with no build dependants. For that would the RPMs not have to be fetched and then their SPEC's processed at least partially to determine if any RPMs it built are not available in current repositories? It might be enough with a fast check to go by name only rather than version? Is there a script anywhere with a list or something that's responsible for these missing packages? What specifically is the thing that excludes them? I assume their removal was via non-inclusion rather than exclusion which may make it difficult and is why there's not a list already available? I found this probably lists most or a lot of things: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/considerations_in_adopting_rhel_8/index > A.4. Removed packages I'm not sure that it works however as a machine readable list or one that can be used without first studying. I think it mixes up valid removals from 7 to 8 to things that were really removed from 8 outright. IE, both 7 and 8 might have libuser, so both should have libuser-devel but 8 doesn't. If 8 removed libexample though because it we properly replaced or no longer supported, then that would be a true removal from 7 to 8. |
|
|
If it's that important to you I would suggest working on adding the package to EPEL 8. |
|
|
I set a goal of building recent xen, qemu-3.1,libvirt and supporting buid requires without using the rhel `virt module` from Appstream (198 packages with many *-devel, but not libssh2-devel). I stored the builds in 2 local repo, one for general use, the other with the `virt module` counterparts. Before starting any mock session I did: dnf module disable virt(-devel). I'm making progress, but without libguestfs. Attached is the latest install trace.
xen-412-full-stack-without-virt-module (24,683 bytes) |
|
|
Unfortunately adding all the missing packages isn't well done as a piecemeal process. It really needs to be fixed in all the build scripts for Centos itself and upstream. It's not only leaf nodes that are unshipped but also build dependencies. It means it's an incomplete open source operating system on at least two fronts with the missing packages. Many of the packages are missing build dependencies for packages in the OS that are shipped themselves, presumably they must therefore be built, they're just not being shipped. To fix it properly they'll want to be shipped from the normal centos full package build process especially as there's a concern with build matching. Many missing devel packages are the result of building their reciprocal binary packages and ideally should not be built or separately for full compatibility including version matching as well as the specifics of the build. The reason they're left out is that with RHEL, they're missing so that if you want to do something that needs them you have to pay for their support to do it for you. You can technically build the missing things yourself but it's a massive undertaking sometimes. The way the packages are shipped is like shipping a database then deliberately removing parts breaking integrity. The packages are a bit like a file system and if you did an integrity check it would fail from these removed packages. You can discover this because a relational integrity check is done when installing packages. If you try to install source RPMs with the integrity checking enabled it will often fail because of these removed parents. Some of these missing packages are part of core packages and some of them also have recursive integrity errors which means you can end up having to rebuild and maintain yourself not only one package but a large chain of dependencies. While the removal works with the way upstream does things, it's incompatible with centos where you don't have that paid support and are meant to be able to do things yourself. The removed packages are the ones you need to do a lot of things yourself and their removal now means if you want to do things yourself it goes from something that would have a small amount of work and maintenance involved to a major project. The system for building centos already does most of the work needed and once the rest is done it only needs to be done once to serve everyone so we just need to know where that is so we can work out how to assemble a list of these packages in the right format or provide some level of contribution toward fixing the issue. I'd not feel right getting a corresponding devel package for a system library from a third party source rather than having the one resulting from the original build of a package. Chances are in reality it might work but will eventually start to show cracks. |
|
|
Right, and EPEL isn't an option for the packages as the SRPM/main RPMs are in RHEL. It's not permitted and not possible with the current tooling, which is why it needs to be fixed at the RHEL and/or CentOS level. |
- Anonymous
