Re: Loopy rpm subpackages dependencies

[Tomasz Kłoczko]

On Thu, 28 Mar 2019 at 11:47, Neal Gompa  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Loopy rpm subpackages dependencies

[Tomasz Kłoczko]

On Thu, 28 Mar 2019 at 20:57, Neal Gompa  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Loopy rpm subpackages dependencies

[Neal Gompa]

On Thu, Mar 28, 2019 at 1:43 PM Tomasz Kłoczko  wrote:
>
> On Thu, 28 Mar 2019 at 16:37, Miroslav Suchý  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  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Loopy rpm subpackages dependencies

[Tomasz Kłoczko]

On Thu, 28 Mar 2019 at 16:37, Miroslav Suchý  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  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Loopy rpm subpackages dependencies

[Miroslav Suchý]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Loopy rpm subpackages dependencies

[Tomasz Kłoczko]

On Thu, 28 Mar 2019 at 12:47, M A Young  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Loopy rpm subpackages dependencies

[M A Young]

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___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Loopy rpm subpackages dependencies

[Panu Matilainen]

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 

/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}.


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 -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Loopy rpm subpackages dependencies

[Neal Gompa]

On Thu, Mar 28, 2019 at 7:32 AM 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).
>
> 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Loopy rpm subpackages dependencies

[Tomasz Kłoczko]

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 *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org