6:31 a.m.
Hi,
Just found that on some minimal system it is not possible to remove some
rpm subpackages.
* Current state
# rpm -qa | grep rpm
rpm-libs-4.14.2.1-4.fc30.1.x86_64
rpm-4.14.2.1-4.fc30.1.x86_64
python3-rpm-4.14.2.1-4.fc30.1.x86_64
rpm-build-libs-4.14.2.1-4.fc30.1.x86_64
rpm-sign-libs-4.14.2.1-4.fc30.1.x86_64
python3-rpm is required by dnf so it is really hard to have manageable
system without that part (however in extreme cases it is still possible to
drop completely dnf).
Problem is that on minimal system rpm-sign-libs and rpm-build-libs
theoretically should be not needed, however because python module in
current form combines in single package all its three DSOs:
# rpm -ql python3-rpm | grep so$
/usr/lib64/python3.7/site-packages/rpm/_rpm.cpython-37m-x86_64-linux-gnu.so
/usr/lib64/python3.7/site-packages/rpm/_rpmb.cpython-37m-x86_64-linux-gnu.so
/usr/lib64/python3.7/site-packages/rpm/_rpms.cpython-37m-x86_64-linux-gnu.so
it causes that it is not possible to use only core rpm package management
on minimal system.
I think that it would be good to split python3-rpm into python3-rpm{,b,s}.
* Proposal
In current form keeping separated rpm-plugin-selinux is a bit pointless so
that part IMO should be joined with rpm-build.
As well probably rpm-plugin-ima could be merged with rpm-sign.
With that changes total number of generated packages will be the same and
will make IMO much more sense in case of non-devel/build systems and
systems which are used for signing packages.
Comments?
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
6:36 a.m.
On Thu, Mar 28, 2019 at 7:32 AM Tomasz Kłoczko <kloczko.tomasz(a)gmail.com> wrote:
Hi,
Just found that on some minimal system it is not possible to remove some rpm
subpackages.
* Current state
# rpm -qa | grep rpm
rpm-libs-4.14.2.1-4.fc30.1.x86_64
rpm-4.14.2.1-4.fc30.1.x86_64
python3-rpm-4.14.2.1-4.fc30.1.x86_64
rpm-build-libs-4.14.2.1-4.fc30.1.x86_64
rpm-sign-libs-4.14.2.1-4.fc30.1.x86_64
python3-rpm is required by dnf so it is really hard to have manageable system without
that part (however in extreme cases it is still possible to drop completely dnf).
Problem is that on minimal system rpm-sign-libs and rpm-build-libs theoretically should
be not needed, however because python module in current form combines in single package
all its three DSOs:
# rpm -ql python3-rpm | grep so$
/usr/lib64/python3.7/site-packages/rpm/_rpm.cpython-37m-x86_64-linux-gnu.so
/usr/lib64/python3.7/site-packages/rpm/_rpmb.cpython-37m-x86_64-linux-gnu.so
/usr/lib64/python3.7/site-packages/rpm/_rpms.cpython-37m-x86_64-linux-gnu.so
it causes that it is not possible to use only core rpm package management on minimal
system.
I think that it would be good to split python3-rpm into python3-rpm{,b,s}.
* Proposal
In current form keeping separated rpm-plugin-selinux is a bit pointless so that part IMO
should be joined with rpm-build.
As well probably rpm-plugin-ima could be merged with rpm-sign.
With that changes total number of generated packages will be the same and will make IMO
much more sense in case of non-devel/build systems and systems which are used for signing
packages.
Comments?
No. The rpm plugins are runtime activated things, that's why they are split out.
And why are you complaining about library packages?! It adds very
little in the way of space usage or such. It's also only "loopy" if
you are insane enough to split the updating of these packages into
separate transactions.
--
真実はいつも一つ！/ Always, there's only one truth!
5:25 p.m.
On Thu, 28 Mar 2019 at 11:47, Neal Gompa <ngompa13(a)gmail.com> wrote:
[..]
No. The rpm plugins are runtime activated things, that's why they
are
split out.
Exactly. Just checked and in python code those modules initialisation looks
like below:
--
# try to import build bits but dont require it
try:
from rpm._rpmb import *
except ImportError:
pass
# try to import signing bits but dont require it
try:
from rpm._rpms import *
except ImportError:
pass
--
So technically those rpmb and rpms pythoon DSOs can be separated.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
7:14 a.m.
On 3/28/19 1:31 PM, Tomasz Kłoczko wrote:
Hi,
Just found that on some minimal system it is not possible to remove some
rpm subpackages.
* Current state
# rpm -qa | grep rpm
rpm-libs-4.14.2.1-4.fc30.1.x86_64
rpm-4.14.2.1-4.fc30.1.x86_64
python3-rpm-4.14.2.1-4.fc30.1.x86_64
rpm-build-libs-4.14.2.1-4.fc30.1.x86_64
rpm-sign-libs-4.14.2.1-4.fc30.1.x86_64
python3-rpm is required by dnf so it is really hard to have manageable
system without that part (however in extreme cases it is still possible
to drop completely dnf).
Yes and the split in all its painfullness is exactly to support those
minimal environments where there's no python, no dnf etc.
Problem is that on minimal system rpm-sign-libs and rpm-build-libs
theoretically should be not needed, however because python module in
current form combines in single package all its three DSOs:
# rpm -ql python3-rpm | grep so$
/usr/lib64/python3.7/site-packages/rpm/_rpm.cpython-37m-x86_64-linux-gnu.so
<http://rpm.cpython-37m-x86_64-linux-gnu.so>
/usr/lib64/python3.7/site-packages/rpm/_rpmb.cpython-37m-x86_64-linux-gnu.so
<http://rpmb.cpython-37m-x86_64-linux-gnu.so>
/usr/lib64/python3.7/site-packages/rpm/_rpms.cpython-37m-x86_64-linux-gnu.so
<http://rpms.cpython-37m-x86_64-linux-gnu.so>
it causes that it is not possible to use only core rpm package
management on minimal system.
I think that it would be good to split python3-rpm into python3-rpm{,b,s}.
That's one possibility but hasn't been done because it makes it even
more painful, and actually the build part would be dragged in by the
builddep dnf plugin anyway.
- Panu -
7:39 a.m.
On Thu, 28 Mar 2019, Tomasz Kłoczko wrote:
Hi,
Just found that on some minimal system it is not possible to remove some rpm
subpackages.
* Current state
# rpm -qa | grep rpm
rpm-libs-4.14.2.1-4.fc30.1.x86_64
rpm-4.14.2.1-4.fc30.1.x86_64
python3-rpm-4.14.2.1-4.fc30.1.x86_64
rpm-build-libs-4.14.2.1-4.fc30.1.x86_64
rpm-sign-libs-4.14.2.1-4.fc30.1.x86_64
python3-rpm is required by dnf so it is really hard to have manageable
system without that part (however in extreme cases it is still possible to
drop completely dnf).
You could always use microdnf instead.
Michael Young
7:57 a.m.
On Thu, 28 Mar 2019 at 12:47, M A Young <m.a.young(a)durham.ac.uk> wrote:
[..]
> python3-rpm is required by dnf so it is really hard to have
manageable
> system without that part (however in extreme cases it is still possible
to
> drop completely dnf).
You could always use microdnf instead.
If it is really possible why it is not used that way by default?
dnf does not provide any signing functions and I was not even aware that
someone implemented in base dnf building functionalities (someone is using
that?)
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
11:28 a.m.
Dne 28. 03. 19 v 13:57 Tomasz Kłoczko napsal(a):
dnf does not provide any signing functions and I was not even aware
that someone implemented in base dnf building
functionalities (someone is using that?)
No, DNF likely does not user rpmb and rpms.
Both libraries has 21K + 15K. It is really worth the work? Note that the split will affect
~ 16 other packages in
Fedora. And likely some outside of Fedora. They need to be notified of the split,
reconsider their dependencies. For
saving 36K?
Miroslav
12:42 p.m.
On Thu, 28 Mar 2019 at 16:37, Miroslav Suchý <msuchy(a)redhat.com> wrote:
Dne 28. 03. 19 v 13:57 Tomasz Kłoczko napsal(a):
> dnf does not provide any signing functions and I was not even aware that
someone implemented in base dnf building
> functionalities (someone is using that?)
No, DNF likely does not user rpmb and rpms.
Both libraries has 21K + 15K. It is really worth the work? Note that the
split will affect ~ 16 other packages in
Fedora. And likely some outside of Fedora. They need to be notified of the
split, reconsider their dependencies. For
saving 36K?
Yes, I care about every possible (even smallest) cut on the elephant skin
which will die if thousand small cuts on his skin will be done :P
If that does't matter why the <censored> rpm package build produces
generates so many subpackages??
If on typical system most of those packages are not optional why make so
many subpackages? To make Packages table in rpm database longer only?
Not mentioning about fact that even usability of current grouping of the
rpm files has zero usability in case of multilib scenarios (which could be
some logical reason for thatcase but isn't)
Just for fun/Because we can(tm)?
If may I point on one cardinal argument which is .. KISS!!!
There is no any other single package which during build may require signing
library (only). Not keeping sign library in rpm-sign is purely artificial.
In other words probability that this package would be required in some
multilib scenarios is ZERO!
Other things related to the rpm.
Why in main rpm package is possible to find whole /usr/lib/rpm/platform?
That directory contains ONLY resources used during build!!! Why main rpm
package includes documentation about building packages? =:-#
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
3:48 p.m.
On Thu, Mar 28, 2019 at 1:43 PM Tomasz Kłoczko <kloczko.tomasz(a)gmail.com> wrote:
On Thu, 28 Mar 2019 at 16:37, Miroslav Suchý <msuchy(a)redhat.com> wrote:
>
> Dne 28. 03. 19 v 13:57 Tomasz Kłoczko napsal(a):
> > dnf does not provide any signing functions and I was not even aware that someone
implemented in base dnf building
> > functionalities (someone is using that?)
>
> No, DNF likely does not user rpmb and rpms.
> Both libraries has 21K + 15K. It is really worth the work? Note that the split will
affect ~ 16 other packages in
> Fedora. And likely some outside of Fedora. They need to be notified of the split,
reconsider their dependencies. For
> saving 36K?
Yes, I care about every possible (even smallest) cut on the elephant skin which will die
if thousand small cuts on his skin will be done :P
If that does't matter why the <censored> rpm package build produces generates
so many subpackages??
If on typical system most of those packages are not optional why make so many
subpackages? To make Packages table in rpm database longer only?
Not mentioning about fact that even usability of current grouping of the rpm files has
zero usability in case of multilib scenarios (which could be some logical reason for
thatcase but isn't)
Just for fun/Because we can(tm)?
If may I point on one cardinal argument which is .. KISS!!!
There is no any other single package which during build may require signing library
(only). Not keeping sign library in rpm-sign is purely artificial. In other words
probability that this package would be required in some multilib scenarios is ZERO!
Other things related to the rpm.
Why in main rpm package is possible to find whole /usr/lib/rpm/platform? That directory
contains ONLY resources used during build!!! Why main rpm package includes documentation
about building packages? =:-#
They can be used at runtime as well, especially if you use
runtime-evaluated macros in scriptlets.
--
真実はいつも一つ！/ Always, there's only one truth!
5:07 p.m.
On Thu, 28 Mar 2019 at 20:57, Neal Gompa <ngompa13(a)gmail.com> wrote:
[..]
> Other things related to the rpm.
> Why in main rpm package is possible to find whole /usr/lib/rpm/platform?
That directory contains ONLY resources used during build!!! Why main rpm
package includes documentation about building packages? =:-#
>
They can be used at runtime as well, especially if you use
runtime-evaluated macros in scriptlets.
Hopefully it is still only theory ..
1) Exactly those macros long time ago have been separated as build stage
dependent set. (Just in case if it is not obvious) in platform/ are all
archs files because that allows use rpm to do cross arch builds.
2) Theoretically someone may do any possible s*d thing in such scriptlets
and still it does not mean that those macros should be used :)
3) I don't know anything about such cases like you mention in any Fedora
spec files uses that (just done I've done few greps and still potential
list is empty) and it is already some non-empty set of such specs that
should be corrected ASAP because using something like this potentially
could be like opening Pandora box.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
1865
days inactive
1865
days old
9 comments
5 participants
participants (5)
-
M A Young -
Miroslav Suchý -
Neal Gompa -
Panu Matilainen -
Tomasz Kłoczko