Re: Enabling RPM based sysuser handling

[Florian Festi]

On 5/11/24 12:56, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, May 10, 2024 at 01:28:07PM +0200, Florian Festi wrote:
>> Anyone interested in picking this up? I remember quite a few people
>> being exited about this when it was announced with the rpm-4.19 Change.
> 
> I would be interested in making this happen.
> 
> You mentioned that the transition "requires some care". What are
> the problems?

There are Requires created for the users and groups. To make this work
the Provides need to be there first - obviously. So one will probably
need to set %_use_weak_usergroup_deps for a transition period. At least
until the first mass rebuild.

There are also a large number of packages that are using useradd:
grep useradd *.spec | cut -d: -f1 | sort -u | wc
281 2814090

We need to think what to do with them.

The sysusers macros are much less used actually:
grep sysusers_requires_compat *.spec | cut -d: -f1 | sort -u | wc
 53  53 725
grep sysusers_create_compat *.spec | cut -d: -f1 | sort -u | wc
101 1011476

>> This whole thing probably needs to be a Global Change involving a change
>> to the Packaging Guidelines [4] and may be an Mass Package Change
>> (although that might be avoided by changing the macros in
>> systemd-rpm-macros to NOPs).
> 
> The macros are written in a way that if the user/group exist,
> no operation is done. Thus, naively, I would think that if rpm
> starts to create users and groups on its own, then the existing
> scriptlets would become noops. That would mean that we could enable
> the feature in rpm without any mass package changes first.

That might work, but I have not looked deep enough into that to do that
blindly.

> If the rpm approach works, I think it'd make sense to
> a) change the macros to be noops,
> b) do a mass package change to strip the scriptlets from all packages.
>That's probably the right thing to do for the rawhide branch, but
>as usual, the question becomes how to handle packages that use a
>common branch for older releases. But the Mass Change process is
>intended to deal with such cases.

One way to deal with this is to keep the noop macros until all current
Fedora versions are using the new method.


It's probably not super complicated it just wasn't something we wanted
to do during the actual RPM update - which already was a lot of "fun"
without also enabling the new user handling.

Then there is ofc all the paper work needed.

Florian

PS: Note that the upcoming RPM 4.20 release is extending the support to
"m" lines in sysuser files (which adds users to existing groups)


> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Florian Festi]

On 5/11/24 01:04, Kevin Kofler via devel wrote:
> Florian Festi wrote:
>> We have an even easier solution for you: You can just run the script at
>> [3] with -n on your own spec files to get them changed to the %patch N
>> variant. If you do that right now they will not break nor will they be
>> touched during the mass change.
>>
>> As I said the %patch -PN syntax is the one with the best compatibility -
>>  reaching back into the dark ages. I am not advocating for people to use
>> it. Anyone is free and encouraged to move to something more modern -
>> before or after the change. We are using this variant so spec files
>> continue to work on older distributions and the chance of breakage is
>> minimized. This way packagers that don't care don't have to.
> 
> What I do not understand is why RPM is discontinuing the most commonly used 
> syntax and breaking hundreds of specfiles. This also leaves us with only the 
> choice between a backwards-incompatible syntax (added only in RPM 4.18) and 
> an ugly and redundantly verbose syntax (the -P syntax). And even the modern 
> syntax is 1 character (space) longer for every patch. The shortest syntax 
> was the one being dropped.

I am glad you asked.

The short answer is the %patchN instances are not a proper macros and we
no longer can have that.

The long story is that the spec parsing code is old, weird and is one of
the few places in RPM that have not seen major renovations in the last
two decades - until now. We have also put a lot more stress on that code
with all the language specific macros and lua scripts, extended
debuginfo support, dynamic spec parts, the new build scripts, ...
So a lot of the weirdness and corner cases that were "fine" for "normal"
specs are now showing up more and more.

Expanding the %patchN syntax required a whole separate parse and expand
run that was separate from the macro expansion. This led to subtle
semantic issues wrt expansion order. It also made %prep special and
%patchN only worked in there. %patch otoh (now) is a regular (though
internally implemented) macro that is expanded with other macros and
though can be used in other macros and expressions.

This is only one of many issue with the parsing (and building) code and
we are actively working on disentangling the mess. For most things
packager won't notice unless they do more complicated things where these
semantic details matter. But the %patchN syntax is something that is
just not worth preserving. It does not fit into the overall macro frame
work and should not have been added in the first place. I also have a
hard time seeing how adding a single space per %patch line is
overburdening packagers.

Florian
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Florian Festi]

On 5/10/24 14:10, Vít Ondruch wrote:
> I'd actually prefer the `%patch 1` syntax (which is also the first on
> the list [1]). Yes, I understand that `%patch -P1` is to stay on the
> safe side, but this is Fedora change, not RHEL or EPEL change.
> 
> But if you insist on `-P1`, then please skip all packages I am
> associated with. I'd prefer to have them broken and if needed, I fix
> them later myself.

We have an even easier solution for you: You can just run the script at
[3] with -n on your own spec files to get them changed to the %patch N
variant. If you do that right now they will not break nor will they be
touched during the mass change.

As I said the %patch -PN syntax is the one with the best compatibility -
 reaching back into the dark ages. I am not advocating for people to use
it. Anyone is free and encouraged to move to something more modern -
before or after the change. We are using this variant so spec files
continue to work on older distributions and the chance of breakage is
minimized. This way packagers that don't care don't have to.

Florian

> Dne 06. 05. 24 v 13:56 Florian Festi napsal(a):
>> Hi everyone,
>>
>> RPM has deprecated the %patchN syntax in favor of %patch -PN where N is
>> the patch number for a year now. See the RPM documentation for more
>> information [1]. In current RPM versions, this syntax only emits a
>> deprecation warning, but support for this syntax has been removed
>> completely in the upcoming RPM 4.20 release. As it will be added in
>> Fedora soon [2] it is time to switch over to the new syntax now.
>>
>> There are around 1800 packages that still use the old syntax. Later this
>> week/next week, we will run this script [3] over the affected packages
>> [4][5] to update them to the modern patch syntax. For example, the
>> script will change:
>>
>> %patch0 -p1 → %patch -P0 -p1
>> %patch0005 -p2 → %patch -P0005 -p2
>>
>> If anyone has any objections or would like to exclude a package, please
>> let me know.
>>
>> As this change does not affect the resulting binary packages an
>> immediate rebuild is not needed. The change will "only" ensure the
>> packages still build with the new version of RPM.
>>
>> This is the change with the highest compatibility (back to RPM 3.x).
>> There are more modern options (like %autosetup) that packagers are
>> encouraged to use but are out of scope here.
>>
>> Florian
>>
>> [1]
>> https://rpm-software-management.github.io/rpm/manual/spec.html#patch-1
>> [2] https://fedoraproject.org/wiki/Changes/RPM-4.20
>> [3] https://fedoraproject.org/wiki/File:User-Ffesti-new_patch_syntax.sh
>> [4] https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-packages.txt
>> [5]
>> https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-package-owners.txt
>> -- 
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
> 
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Enabling RPM based sysuser handling

[Florian Festi]

Hi everyone!

RPM 4.19 added automatic sysuser handling [1]. In Fedora 39 this feature
was not enabled right away [2] as it requires some care to properly
transition to it. Also going back to 4.18 was technically still the
fallback option during this change.

I just noticed in an issue in the RPM upstream repository [3] that the
sysuser feature is still not enabled. May be right now might be a good
time to get this going for Fedora 41. I am happy to help with the
technical details but would prefer if this effort was driven from within
Fedora.

Currently users are either done manually by calling useradd in
scriptlets or using the macros in systemd-rpm-macros which is a sub
package of the systemd package. RPM's mechanism is switched off by
rpm-4.18.92-disable-sysusers.patch in the rpm package.

This whole thing probably needs to be a Global Change involving a change
to the Packaging Guidelines [4] and may be an Mass Package Change
(although that might be avoided by changing the macros in
systemd-rpm-macros to NOPs).

Anyone interested in picking this up? I remember quite a few people
being exited about this when it was announced with the rpm-4.19 Change.

Florian

[1]
https://rpm-software-management.github.io/rpm/manual/users_and_groups.html
[2] https://fedoraproject.org/wiki/Changes/RPM-4.19
[3] https://github.com/rpm-software-management/rpm/issues/3073
[4] https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Florian Festi]

On 5/8/24 00:49, Omair Majid wrote:
> Hi,
> 
> Florian Festi  writes:
> 
>> If anyone has any objections or would like to exclude a package, please
>> let me know.
> 
> Could you please exclude the .NET packages (dotnet6.0, dotnet7.0,
> dotnet8.0)? dotnet8.0 shouldn't need a fix (and it doesn't appear in your
> list). dotnet7.0 is already EOL/orphaned/retired. dotnet6.0 will go
> through the same EOL/orphan/retiring process later this year. There's
> little point changing it now
Sure!

Florian
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Florian Festi]

Hi everyone,

RPM has deprecated the %patchN syntax in favor of %patch -PN where N is
the patch number for a year now. See the RPM documentation for more
information [1]. In current RPM versions, this syntax only emits a
deprecation warning, but support for this syntax has been removed
completely in the upcoming RPM 4.20 release. As it will be added in
Fedora soon [2] it is time to switch over to the new syntax now.

There are around 1800 packages that still use the old syntax. Later this
week/next week, we will run this script [3] over the affected packages
[4][5] to update them to the modern patch syntax. For example, the
script will change:

%patch0 -p1 → %patch -P0 -p1
%patch0005 -p2 → %patch -P0005 -p2

If anyone has any objections or would like to exclude a package, please
let me know.

As this change does not affect the resulting binary packages an
immediate rebuild is not needed. The change will "only" ensure the
packages still build with the new version of RPM.

This is the change with the highest compatibility (back to RPM 3.x).
There are more modern options (like %autosetup) that packagers are
encouraged to use but are out of scope here.

Florian

[1] https://rpm-software-management.github.io/rpm/manual/spec.html#patch-1
[2] https://fedoraproject.org/wiki/Changes/RPM-4.20
[3] https://fedoraproject.org/wiki/File:User-Ffesti-new_patch_syntax.sh
[4] https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-packages.txt
[5]
https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-package-owners.txt
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Towards enabling rpm sysusers integration

[Florian Festi]

On 6/29/23 09:55, Panu Matilainen wrote:
> The rpm integration doesn't technically require systemd-sysusers, we can
> write a script that calls useradd/groupadd instead. So for us it becomes
> a choice between writing that script or adding audit support to
> systemd-sysusers. Writing a script based on sysusers.generate-pre.sh may
> well be less work and would benefit the non-systemd audiences of rpm at
> the same time. We'll see.


OK, I cobbled something together:

https://github.com/rpm-software-management/rpm/pull/2573

It still waits for the new test suite back end to pass the testsuite but
that shouldn't prevent anyone from already having a look.

Does anyone have a suggestion  for another way for checking for the
existence of users groups and UIDs? While useradd and group add support
the --root parameter things like id don't.

Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Flock CFP: Language SIGs discussion

[Florian Festi]

This is great to see! The issue of lack of coordination and
collaboration between the language SIGs also came up in my workshop on
DevConf [1]. Having them share more code/macros and spec file idioms
would make packaging as a whole easier. Not re-inventing solutions for
the same or at least similar problems would also be a great step forward.

Unfortunately there won't be anyone from the RPM team at Flock. If there
is anything you need or we can do to make this easier please bring that
up to me. We can always add more repositories in the
https://github.com/rpm-software-management organization if you need a
place for upstream repositories - especially if you want a place that is
more neutral when it comes to cooperation with other RPM based
distributions. Which is another dimension on which sharing and
cooperation should be extended.

As it is relevant for this meeting may be someone that attended my
workshop can give a 3 or 5 minute summary of the new Dynamic Spec
feature. Slides are available [2]. Slide 8 to 10 or 11 should be
sufficient. Unfortunately there isn't a recording of the workshop. Feel
free to bug me if you have questions.

Florian


[1] https://devconfcz2023.sched.com/event/d1c12cf5f5e4dec9b089b21781c1d9fd
[2]
https://static.sched.com/hosted_files/devconfcz2023/c2/DynamicBuilds-DevConf.odp
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

[Florian Festi]

On 4/3/23 08:04, Florian Weimer wrote:
> * Florian Festi:
> 
>> On 3/31/23 15:40, Stephen Gallagher wrote:
>>> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton  wrote:
>>>>
>>>> https://fedoraproject.org/wiki/Changes/RPM-4.19
>>>
>>>> == Detailed Description ==
>>>> RPM 4.19 contains various improvements over previous versions. Many of
>>>> them are internal in nature such as moving from automake to cmake,
>>>> improvements to the test suite, stripping copies of system functions,
>>>> splitting translations into a separate project and more. There are
>>>> still several user facing changes:
>>>>
>>>> * New rpmsort(8) utility for sorting RPM versions
>>> Handy!
>>>
>>>> * x86-64 architecture levels (v2-v4) as architectures
>>> Could you explain more what this means, exactly?
>>
>> No! But here is the commit:
>>
>>  
>> https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847
>>
>> It looks like it adds x86_64_v2, x86_64_v3 and x86_64_v4. Something
>> about some x86_64 processors having additional capabilities.
> 
> Are these fully separate architectures, or can x86_64_v3 packages
> fulfill dependencies on x86_64 packages?
> 
> It's not clear to me yet how this new feature is supposed to be used.

These are not independent architectures but are compatible with all
lower ones. So it is similar to i386, i486, i586, i686 - just this time
in 64 bit. They are there to allow distributions to create optimized
packages that only run on processors with the additional features.

> (Detection for x86-64-v3 and x86-64-v4 is not correct because it does
> not examine XCR0.  I'm going to file an upstream bug for that.)
> 
> Thanks,
> Florian
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

[Florian Festi]

On 3/31/23 15:40, Stephen Gallagher wrote:
> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton  wrote:
>>
>> https://fedoraproject.org/wiki/Changes/RPM-4.19
> 
>> == Detailed Description ==
>> RPM 4.19 contains various improvements over previous versions. Many of
>> them are internal in nature such as moving from automake to cmake,
>> improvements to the test suite, stripping copies of system functions,
>> splitting translations into a separate project and more. There are
>> still several user facing changes:
>>
>> * New rpmsort(8) utility for sorting RPM versions
> Handy!
> 
>> * x86-64 architecture levels (v2-v4) as architectures
> Could you explain more what this means, exactly?

No! But here is the commit:

 
https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847

It looks like it adds x86_64_v2, x86_64_v3 and x86_64_v4. Something
about some x86_64 processors having additional capabilities.

>> * Support for %preuntrans and %postuntrans scriptlets
>> * Creating User and Groups from sysusers.d files including Provides
>> and Requires or Recommends
> I may have cried a little bit in joy here. This is huge!
> 
>> ([https://github.com/rpm-software-management/rpm/pull/2432 PR],
>> [https://github.com/rpm-software-management/rpm/discussions/2277
>> Discussion])

There now is proper documentation online. This just got merged, so it
wasn't available yet, when I submitted the change page.

https://rpm-software-management.github.io/rpm/manual/users_and_groups.html

Note that this will not be enabled fully at first. There needs to be
another Global Change to enable this fully. The actual update of RPM is
meant to be as little disruptive as possible. After the update the new
features can be enabled or put into Packaging Policy. But I guess most
here know that dance already.


>> * [https://rpm-software-management.github.io/rpm/manual/dynamic_specs.html
>> Dynamic Spec generation]
> 
> This could be a real winner for glibc, texlive and fedora-release.

Yes. But this was actually meant to be used for whole ecosystems like
Python to turn Manifest files into sub packages.

>> ** find_lang now being able to generate language sub packages
> 
> Could you provide more info on this? It's written almost like a
> side-note, but this could be a big deal.

Well this was done as a prove of concept for the Dynamic Spec feature.
See https://github.com/rpm-software-management/rpm/pull/2300 for the
change itself

For packagers all they need to know that there is a new
--generate-subpackages parameter for find-lang.sh that creates sub
packages according to the %_langpack_template macro.

This could probably use a bit more review from people more into i18n
than myself.


>> The 4.19 alpha release is expected in April and the final release is
>> expected in time for the Fedora 39 release cycle as usual.
> But I want it now... 
The time will come. The time will come.

Florian

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: %patchN deprecated?

[Florian Festi]

On 3/29/23 10:31, Michael J Gruber wrote:
> Has `%patchN` been deprecated in favour of `%patch N`?

Yes, see %patch section on
https://rpm-software-management.github.io/rpm/manual/spec.html

> I got a push by a proven packager to one of the packages which I maintain, 
> commit subject and changelog entry "Fix deprecated patch rpm macro". It 
> contains no explanation and no reference whatsoever. I didn't find any heads 
> up notice, nor info in the packaging guidelines, but I didn't try too hard - 
> because it's not my job.
> 
> I mean: One person is doing that push. Is it too much to ask to get at least 
> the slightest bit of reference or communication before or into a push which 
> probably affects hundreds of people? If not out of courtesy then out of mere 
> common sense of efficiency?
> 
> On the technical side, I'd be interested why this is better (fewer macros?) 
> and which releases can take it, and what are the recommendations for 
> `PatchN:`-lines (with or without N), and why (or whether) the recommendation 
> isn't to go for `%autosetup` or `%autopatch` - maybe all answered in the 
> missing reference.

Those macros are an ugly hack and RPM upstream rather had them go away.

The deprecation suggests a one to one replacement. Ofc using the use of
%autosetup or %autopatch is encouraged but that kinda out of scope of
the deprecation.

Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: valgrind on Fedora

[Florian Festi]

On 1/16/23 07:10, Gordon Messmer wrote:
> Does anyone have any hints for improving the information I get from
> valgrind?
Have you installed the debuginfo packages for the packages involved?
See man debuginfo-install

Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpmbuild is very slow with large files

[Florian Festi]

On 7/12/22 11:02, Marius Schwarz wrote:
> Am 12.07.22 um 10:55 schrieb Marius Schwarz:
>>
>> The rpmbuild process for this one rpm was single thread. With a
>> lsof-loop,  I could see "bytes" getting attached to the resulting file
>> with an awful slow progression rate. Which is very frustrating to see
>> on a 8 core system.
>>
>> The thing is, I do testbuilds of VOSK with language model and code
>> etc. on one of my servers. If this project ever reaches the Fedora
>> build farm,
>> we can expect a very long build time, if nothing is changed in
>> rpmbuild. Is there maybe a hidden parallel compression option somewhere?
>>
> 
> Looks like someone else had the same problem with rpmbuilds XZ single
> core compression:
> 
> https://insujang.github.io/2020-11-07/accelerating-ceph-rpm-packaging-using-multithreaded-compression/
> 
> |--define "_binary_payload w2T16.xzdio" |
> 
> |Question: Is the resulting compression format suitable for Fedora repo
> or a against a policy?|

Yeah, we did quite some work upstream to get builds run in parallel at
various stages and levels.

RPM does support multithreaded compression where the compression
libraries support that but it needs to be enabled. As the result are not
the same as single threaded compression this may have impact on the
viability of deltarpms. But IIRC at least zstd while having different
results would at least have reproducible results. But I am not the one
that actually checked and decided against threaded compression.

Florian

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)

[Florian Festi]

On 7/29/21 11:51 AM, Daniel P. Berrangé wrote:
> On Thu, Jul 29, 2021 at 09:37:53AM +, Zbigniew Jędrzejewski-Szmek wrote:
>> On Wed, Jul 28, 2021 at 07:04:03PM +0200, Miroslav Suchý wrote:
>> So... personally I think we should restart many more things than
>> we currently do. Even in systemd itself we fall short of this
>> goal: systemd-logind is not restarted because of bugs (gnome
>> session gets killed when logind is restarted, and it's really a
>> problem with how logind manages resources during restart [1]).
>> To be able to safely restart, the application has to provide the
>> appropriate functionality: it needs to either always keep all
>> state serialized, or serialize it on demand. Systemd provides a
>> "file descriptor store" [2] that can be used to keep files open
>> while the process is not running. There are obviously exceptions…
>> for example graphical applications. But for many system services and
>> background user services, my expecation is that they are invisibly
>> restarted in the background without any user interaction. Each program
>> that allows this moves us one step closer towards the goal of being
>> upgrades being a non-event.
> I'd question the criteria we use for deciding when to restart services.
> Typically we only restart a daemon if the daemon binary is upgraded.
> This ignores any libraries that the daemon links to, which are just
> as important to its functionality, reliability and security as the
> executable binary.  Only restarting daemons when the executable binary
> changes gives us a false sense of having solved the upgrades problems.
> To arbitrarily pick on 'colord', there are 35 libraries it links to
> that could be considered triggers for restart on upgrade. This is
> an especially important problem for any daemons that link to TLS or
> general crypto libraries, as it means we're not actually applying
> security updates in those libraries to any running daemons that use
> them, unless you always restart the entire host OS.

This is out of the scope of this Change but I am wondering whether this
should be something RPM supports somehow. Yes, there are triggers, that
would allow for scriptlets to run if another package gets updated. But
this is super cumbersome for this use case and requires the packager to
keep track of all the dependencies (recursively!).

My first thought was a new trigger scriptlet type that would run if any
dependencies get updated. But I guess this would trigger much too often.
Dependencies from scriptlets or meta dependencies can ofc be filtered
out but this will probably still leave too many dependencies.

May be we could have some REs to filter the dependencies to look at.
Just matching *.so* may do the trick but looks pretty fragile.

Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Strange rpmbuild begaveour

[Florian Festi]

On 7/5/20 2:21 PM, TI_Eugene wrote:
> Two builds for tests:
> 1. https://koji.fedoraproject.org/koji/taskinfo?taskID=46635276
> 2. https://koji.fedoraproject.org/koji/taskinfo?taskID=46635342
> 
> The deferrence between them - libraries permissions.
> 
> Problems are:
> 1. %{make_install} installs libraries with 0755 flags
> 2. After changing library files mode into 0644 rpmbuild not extracts
> debug info

Yes, the exec bits are used as indicators whether those files should be
processed or not. It takes the permission bits from the disk so you can
change them in the file list independently.

> Where I'm wrong?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


-- 
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill,
Thomas Savage
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Fedora-packaging] Let's standardize the way to disable tests during RPM build?

[Florian Festi]

May be https://github.com/rpm-software-management/rpm/pull/1256 does the
trick. Comments welcome!

Florian

On 6/5/20 4:39 PM, Igor Raits wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Fri, 2020-06-05 at 16:10 +0200, Tomas Orsava wrote:
>> Hi,
>> I think it would be useful to have a standard way of disabling the 
>> running of tests during RPM build (in the %check section of a spec
>> file).
>>
>> I see a lot of packages already having %bcond's or other macro 
>> definitions to archieve this, but each package has their own way, 
>> there's no real standard. Thus you have to first look into the spec, 
>> locate the appropriate %bcond or macro name and only then you can 
>> disable the tests.
>>
>> I would like to propose two approaches:
>>
>> (a) Add a *SHOULD* rule to the guidelines that specifies what is the 
>> preferred way to conditionalize the tests.
>>
>> (b) Or, if that's too strong, mention in the guidelines the common 
>> methods that are being used (e.g. %bcond tests and %bcond check) so
>> that 
>> new packagers have something to use.
>>
>> What do you think?
> 
> I'd like to have this finally be implemented in
> https://github.com/rpm-software-management/rpm/issues/316. That way it
> would be simply rpmbuild --nocheck or define %_without_check 1 which
> would skip %check section entirely.
> 
> For now, all Rust crates just have `%bcond_without check` so using `--
> without check` works just fine there.
> 
> Since this would be more generic thing to the RPM ecosystem, adding
> rpm-ecosystem@ to the copy.
> 
>> Tomas
>> ___
>> packaging mailing list -- packag...@lists.fedoraproject.org
>> To unsubscribe send an email to  
>> packaging-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:  
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines:  
>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:  
>> https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org
> - -- 
> Igor Raits 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aWQwACgkQEV1auJxc
> Hh6dyBAAmbJSCU0wtuET7vuXVVIeg7BeosaQF25/VoMwTSYGH3h36S9Gci9BRBgs
> yuque1uGnBaUQ74fsxBIMgGzapd73TvEY1M8PNnzHF3Miz0i0FgVhwnw3S9jvrTT
> aGqln2rE3L5jH0alII6pNOIqA67yPlYfb5+JtRazeO0KTarZuGOdemJsp6ONEKQS
> 5doQid6yrQvaUj90Xl2VpRY6goXx5FOQLDPb9DlaWlQDvBcVBJz5oaJ/VyxqCnC2
> ObyLjMB9AXq+pBiot/50QDLTUCxKOkro1siBPxfswNCjpwRy6vDp6dyczHyQkhJ8
> zFAHJQPWAr870WU3FMO/FirTv9yAqY6Je8jB+3EdxjzNuyBMTOT6Iq6r8Su/yxeq
> FcvDvUhlJ0OtWM8PfiIkaKpiSB9rzpuuM5hagPYqznLbqu5AeuTqAKojSyLbkK7Z
> 7fS+qABernfYqAVOlq7DkTaETh/0sAuIxhtwWXbbhz7vFPpbnsPdnyfUUGzFoIdT
> LBFnMOBQF0q4woTAhQRHez+VEH4ndiqZQGdYL8AJ9FtKeMZwwWmvl/r3ki/Hr5Yf
> bqETizKe4XBu5DxPRNN3+0RSi+TIXX11VeHtxIWeuGGErgdqq4EZkBfnmZlTb3/N
> gA8/3DUl9B4XRzGjnzq0AahOfIW1wNObh4pzlmoGN2jrG5odKPM=
> =JCw+
> -END PGP SIGNATURE-
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 


-- 
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill,
Thomas Savage
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Automating R package dependencies

[Florian Festi]

It would be really great to have a proper upstream repository for these
scripts so they don't just live inside of distgit. They could have their
own repository in https://github.com/rpm-software-management or could be
placed in https://github.com/rpm-software-management/rpm-extras. What
ever you like more.

Please contract me off list for setting up the repository/permissions.

Florian


-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/14/2016 01:08 PM, Richard W.M. Jones wrote:
> Yup - I'm curious about this as well.  Using sqlite [for example]
> would solve the libguestfs issues I outlined in this thread, as well
> as using a format which is robust and proven rather than some
> half-baked homebrew thing.

Well, we actually deleted a sqlite backend a few years ago. But even
with a more relational DB layout performance is about 2 times worse than
the BDB.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/13/2016 04:04 PM, Daniel P. Berrange wrote:
> On Wed, Jan 13, 2016 at 01:30:59PM +, Richard Hughes wrote:
>> On 13 January 2016 at 13:13, Reindl Harald  wrote:
>>> so there is no justification to declare one need to install from scratch
>>> just because rpm which works for many years fine changes it's storage format
>>
>> I don't think anyone said there was a need to reinstall from scratch.
> 
> Well the feature writeup is rather fuzzy on this.  It says that in Fedora
> 24 rpm will be able to read both old and new format, but it also says
> that future RPM versions will drop support for the old format.

Yes, this is exactly what I meant to say.

> So unless
> there is a mandatory data format conversion during some Fedora upgrade,
> then at some point RPM will cease to be able to read existing installs
> with the old format which could imply a need to reinstall.

Yes, dropping the support for the old format will be a separate System
wide change for some future Fedora release. Looking at all those
questions about managing containers and VMs we might take a longer time
than our BDB folks may like.

> IMHO the feature proposal text needs to be more explicit about the upgrade
> path and exactly when any data conversion will take place, to avoid leaving
> existing installs with old format stuck with Fedora 25 rpm (or later) drops
> BDB support entirely.

Well, the update path that will always will be available is doing a
rpmdb --exportdb with the old rpm version and an rpmdb --importdb with
the new version. The format of the rpm header will stay compatible so
getting them out and then back into the DB solves the problem.

Florian


-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/16/2016 02:33 AM, Kevin Kofler wrote:
> Daniel P. Berrange wrote:
>> Well the feature writeup is rather fuzzy on this.  It says that in Fedora
>> 24 rpm will be able to read both old and new format, but it also says
>> that future RPM versions will drop support for the old format. So unless
>> there is a mandatory data format conversion during some Fedora upgrade,
>> then at some point RPM will cease to be able to read existing installs
>> with the old format which could imply a need to reinstall.
> 
> Will rpm --rebuilddb convert the database?

Yes.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/29/2016 05:02 PM, Richard W.M. Jones wrote:
> On Fri, Jan 29, 2016 at 04:53:08PM +0100, Florian Festi wrote:
>> On 01/13/2016 03:07 PM, Richard W.M. Jones wrote:
>>>
>>> Say, for example, that Fedora 24 moves to the new format.  Will Fedora 34
>>> be able to read Fedora 24 RPM databases?
>>
>> Fedora 25 will. Fedora 34 will probably not. If it turns out that
>> reading 10 releases old database is really, really important. We will
>> either keep the bdb support or offer some tools to basically do a rpmdb
>> --exportdb which can be used to create a modern rpm database. Who is
>> maintaining the BDB needed for this in 2021 is not a question I am going
>> to answer, though.
> 
> I don't think I was clear.  I understand that for licensing reasons
> BDB is being dropped.  My question relates entirely to this new
> format, and is nothing to do with BDB.
> 
> Will the new format be forwards and backwards compatible?

I really hope we do not have to change the format again in the
foreseeable future. At least I can imagine other things to do with my
life than changing the RPM DB format over and over.

> I'm still unclear why you don't just use sqlite 3.

Among other things it is about 2 times lower than the current BDB
implementation.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/29/2016 05:15 PM, Dennis Gilmore wrote:
> On Monday, January 11, 2016 03:46:27 PM Jan Kurik wrote:
>> = Proposed System Wide Change: Change Proposal Name NewRpmDBFormat =
>> https://fedoraproject.org/wiki/Changes/NewRpmDBFormat
>>
>> Change owner(s):
>> * Florian Festi < ffesti AT redhat DOT com >
>>
>>
>> Change format of the RPM Database from Berkeley DB to RPM's own format.
>>
>> == Detailed Description ==
>> The current implementation of the RPM Database is based on Berkeley
>> DB. There are doubts about the its future and level of maintenance. In
>> addition rpm's use of the database has multiple issues on its own. As
>> a result RPM upstream is working to replace the database format with a
>> new implementation.
> How will this work in situations like the builders. Rpm on f23 makes the f24 
> chroots. I am guessing that will be mostly ok, the db will just have the old 
> format. But what about when we move the builders to f24 and use f24 and rpm 
> with the new db format to make rhel 5, 6, 7 and Fedora, 22 and 23 buildroots. 
> Is there the potential that things will break horribly?

Yes, there is. So this needs to be managed properly. By setting the
format of those databases or by converting them to the old format. Even
if the builder were not to be able to create the old format you could
still use rpmdb --export from outside the buildroot to get the headers
out of the DB and then use rpmdb --importdb from within to rebuild the
old format.

In general the database format is not as important as one might think as
the header format is what carries the actual data.

Florian


-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/13/2016 03:07 PM, Richard W.M. Jones wrote:
> 
> Say, for example, that Fedora 24 moves to the new format.  Will Fedora 34
> be able to read Fedora 24 RPM databases?

Fedora 25 will. Fedora 34 will probably not. If it turns out that
reading 10 releases old database is really, really important. We will
either keep the bdb support or offer some tools to basically do a rpmdb
--exportdb which can be used to create a modern rpm database. Who is
maintaining the BDB needed for this in 2021 is not a question I am going
to answer, though.

> How about Fedora 24 being
> able to read Fedora 34 RPM databases?

I hope we don't have to change the format more often than once a decade.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/11/2016 05:26 PM, Kalev Lember wrote:
> On 01/11/2016 03:46 PM, Jan Kurik wrote:
>> = Proposed System Wide Change: Change Proposal Name NewRpmDBFormat =
>> https://fedoraproject.org/wiki/Changes/NewRpmDBFormat
>>
>> Change owner(s):
>> * Florian Festi < ffesti AT redhat DOT com >
>>
>>
>> Change format of the RPM Database from Berkeley DB to RPM's own format.
>>
>> == Detailed Description ==
>> The current implementation of the RPM Database is based on Berkeley
>> DB. There are doubts about the its future and level of maintenance. In
>> addition rpm's use of the database has multiple issues on its own. As
>> a result RPM upstream is working to replace the database format with a
>> new implementation.
> 
> Is the new database going to be able to support yumdb use cases as well?
> Might be a good time to get rid of separate rpmdb and yumdb and merge
> them together.

No, this is a pretty straight forward replacement of the backend. While
the whole area has still a lot the be desired this change only replaces
the BDB. No other fancy changes.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/13/2016 02:36 PM, Reindl Harald wrote:
> 
> 
> Am 13.01.2016 um 14:30 schrieb Richard Hughes:
>> On 13 January 2016 at 13:13, Reindl Harald 
>> wrote:
>>> so there is no justification to declare one need to install from scratch
>>> just because rpm which works for many years fine changes it's storage
>>> format
>>
>> I don't think anyone said there was a need to reinstall from scratch
> 
> so how do you translate "clearly not forward compatible"?

"forward compatible" means the old version of a program being able to
read/process newer version data.

The current rpm versions will not be able to read the new database format.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/11/2016 03:57 PM, Dan Horák wrote:
> On Mon, 11 Jan 2016 15:46:27 +0100
> Jan Kurik <jku...@redhat.com> wrote:
> 
>> = Proposed System Wide Change: Change Proposal Name NewRpmDBFormat =
>> https://fedoraproject.org/wiki/Changes/NewRpmDBFormat
>>
>> Change owner(s):
>> * Florian Festi < ffesti AT redhat DOT com >
>>
>>
>> Change format of the RPM Database from Berkeley DB to RPM's own
>> format.
>>
>> == Detailed Description ==
>> The current implementation of the RPM Database is based on Berkeley
>> DB. There are doubts about the its future and level of maintenance. In
>> addition rpm's use of the database has multiple issues on its own. As
>> a result RPM upstream is working to replace the database format with a
>> new implementation.
> 
> does it mean rpm is changing from Berkeley DB library to another
> library or to a completely new implementation of a database engine?

We change to our own format. One of the problem is the bit special
requirements of rpm where you want to have non privileged readers that
must not have any write access - which is required for most databases
for locking.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/11/2016 09:06 PM, Richard W.M. Jones wrote:
> On Mon, Jan 11, 2016 at 03:46:27PM +0100, Jan Kurik wrote:
>> = Proposed System Wide Change: Change Proposal Name NewRpmDBFormat =
>> https://fedoraproject.org/wiki/Changes/NewRpmDBFormat
> 
> Details of the format?
> 
> What forward and backward compatibility guarantees are there?

RPM will keep support for BDB for now. But to get rid of the dependency
it will be dropped at some point in the future. So it will stay backward
compatible.

The file format is clearly not forward compatible (although you will be
for now be able to still use the old format).

> libguestfs reads the rpmdb of guests (of any version, new or old) in
> order to get the list of packages installed in a guest.  Remember that
> the host and guest may be very different versions, eg. a RHEL 9 host
> accessing a Fedora 24 guest.  Or vice versa.

> Currently we use the (BDB-specific obviously) db_dump tool for this
> purpose.  Other distros such as Debian as much simpler in this regard
> since they expose the package data as plain text files.
> 
> https://github.com/libguestfs/libguestfs/blob/master/src/inspect-apps.c

I would advice to change these over to using librpm or one of the rpm
cli tools. If there are any tools missing, please let me know and we
will try to come up with them.

If possible the rpm installation of the system examined should be used.
If this cannot be done you might need a new version of rpm on the host
system.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/11/2016 05:08 PM, Colin Walters wrote:
> 
> 
> On Mon, Jan 11, 2016, at 09:46 AM, Jan Kurik wrote:
>> = Proposed System Wide Change: Change Proposal Name NewRpmDBFormat =
>> https://fedoraproject.org/wiki/Changes/NewRpmDBFormat
> 
> It'd be interesting to know the technical details, worth reposting once 
> there's
> a design document or prototype PR.

The format is already in the rpm upstream master branch. Give us a bit
on the documentation.

> I added rpm-ostree to the list, and one thing I'd like to note regarding that:
> We always generate a new DB rather than mutate-in-place, because
> rpm-ostree always generates atomic updates.  This means that
> mutation speed is not very relevant to us, but query speed still
> is.

We did some benchmarks. So far performance seems OK or better.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: building conflicting packages from a single spec

[Florian Festi]

On 11/18/2015 04:26 AM, Pádraig Brady wrote:
> Is $subject possible?
> 
> For example generating subpackages like:
>   %{name}-small-but-slow-binaries
>   %{name}-fast-but-big-binaries
> 
> I can %prep and %install into separate areas,
> though was then wondering how to adjust
> the buildroot for subpackages?
> 
> Are any other techniques possible?
> I suppose I could manually set conflicts,
> and then move binaries post install,
> though what happens if mv is one of the
> binaries for example?
> 
> cheers,
> Pádraig.
> 

I added RemovePathPostfixes in 4.13. But is still kinda lacks proper
documentation. See
http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=415aa42566052db9b7677163cea0366e55f72dcf

It is also more useful for things like different config files than
different builds...

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Ownership of /usr/lib/rpm/fileattrs

[Florian Festi]

On 10/16/2015 11:06 PM, Orion Poplawski wrote:
> Various packages now install files into /usr/lib/rpm/fileattrs for use when
> building rpms.  Currently that directory is owned by:
> 
> rpm-build-4.13.0-0.rc1.4.fc23.x86_64
> javapackages-tools-4.6.0-6.fc23.noarch
> 
> Of the various packages on my machine that install files there:
> 
> gstreamer1-1.6.0-2.fc23.x86_64
> javapackages-tools-4.6.0-6.fc23.noarch
> kde-settings-23-7.fc23.noarch
> nodejs-0.10.36-4.fc23.x86_64
> perl-generators-1.06-1.fc23.noarch
> python3-cups-1.9.72-2.fc23.x86_64
> redhat-rpm-config-36-1.fc23.noarch
> rpm-build-4.13.0-0.rc1.4.fc23.x86_64
> rpm-mpi-hooks-3-2.fc23.noarch
> 
> only rpm-mpi-hooks requires rpm-build for directory ownership, while
> javapackages-tools takes the route of owning the directory.  However, I'd
> rather rpm-mpi-hooks not require rpm-build as it's not really necessary other
> than for this directory.  The simple thing I think would be for rpm to own the
> directory.  Does that seem reasonable?
> 

I agree. While Petr is right from an purist POV practicality is what
counts here. Forcing all those packages to either require rpmbuild or
splitting out an devel-rpm sub package is not a good option. Having the
directory within rpm makes things work without any Requires:

I moved the directory over in rawhide (rpm-4.13.0-0.rc1.8.fc24). It is
probably a bit late for F23. Shall I clone the bug for
javapackages-tools, rpm-mpi-hooks, supermin-devel to get them adjusted
or can you take care of them on your own?

Florian


-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Update to rpm-4.13.0 in F23

[Florian Festi]

It is in testing now as
https://bodhi.fedoraproject.org/updates/FEDORA-2015-15193. Sorry for
being that late but there have been several issues holding it back.

Special thanks to Kalev and everyone who took take of Bodhi to get this out.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Update to rpm-4.13.0 in F23

[Florian Festi]

Hi!

I plan to update rpm in F23. The alpha has been in rawhide for some
weeks [1] with the latest release candidate being there since 2nd of
September[2]. Main reason is to help adopting new features (e.g. [3]) in
the F24 and F25 time frame as this gets the new version to be builders
one release earlier.

So far we found two changes that affect a small number of existing packages:

1) A bug fix now trips up packages installing files into the docdir
without listing them in the %files section. Previous rpm versions
erroneously just added those files if %doc was used. This can be fixed
easily by adding those files to the %files section.

2) The rpm trigger implementation only allows one trigger for each
triggering package per package. This limitation still persists but we
now refuse to build packages having two or more such triggers. This is
very rare and can be solve by merging the triggers into one.

If something else turns up we can still revert the particular change in F23.

Objections?

Florian

[1] https://lists.fedoraproject.org/pipermail/devel/2015-July/212672.html
[2]
https://lists.fedoraproject.org/pipermail/devel/2015-September/214075.html
http://rpm.org/wiki/Releases/4.13.0
[3] https://fedorahosted.org/fpc/ticket/566

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

rpm-4.13.0-rc1 in rawhide

[Florian Festi]

I just pushed the first release candidate for RPM rpm-4.13.0 into
rawhide. It now comes with the final syntax for rich dependencies. Also
we merged support for file signatures in the security.ima xattr and some
smaller fixes.

See http://lists.rpm.org/pipermail/rpm-announce/2015-September/51.html

for the announcement and changes since the alpha and

http://rpm.org/wiki/Releases/4.13.0

for the overall changes.

As with the alpha release the focus for rawhide right now is not on the
shiny new RPM features but on the little changes and bug fixes and their
impact on existing packages.

Florian


-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Glibc locale subpackaging

[Florian Festi]

On 06/22/2015 12:16 PM, Jan Kurik wrote:
 = Proposed System Wide Change: Glibc locale subpackaging  =

We have to revisit this topic as soon as rich dependencies are in place.
Rich dependencies offer a way to handle locales on a system wide level.
One possible implementation would be having

langsupport-XX meta packages that enable support for a given language.

Locales could be in packages like glibc-lang-de, foo-lang-de, ...
The main package could then have
Requires: (foo-lang-de if langsupport-de)
if we want to enforce the locale package to be installed.

Otherwise it might be more elegant to have the language package (e.g.
glibc-lang-de) have:

Supplements: (glibc and langsupport-de)

As we can assume that glibc is always installed this could already be
done with:

Supplements: langsupport-de

The benefit of this approach is that installing a new langsupport-XX
package will bring in the locale packages for all packages making use of
this mechanism.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Glibc locale subpackaging

[Florian Festi]

On 08/27/2015 05:33 PM, Mathieu Bridon wrote:
 On Thu, 2015-08-27 at 16:10 +0200, Florian Festi wrote:
 On 06/22/2015 12:16 PM, Jan Kurik wrote:
 = Proposed System Wide Change: Glibc locale subpackaging  =

 We have to revisit this topic as soon as rich dependencies are in 
 place. Rich dependencies offer a way to handle locales on a system 
 wide level. One possible implementation would be having

 langsupport-XX meta packages that enable support for a given
 language.

 Locales could be in packages like glibc-lang-de, foo-lang-de, ...
 The main package could then have
 Requires: (foo-lang-de if langsupport-de)
 if we want to enforce the locale package to be installed.

 Otherwise it might be more elegant to have the language package (e.g.
 glibc-lang-de) have:

 Supplements: (glibc and langsupport-de)

 As we can assume that glibc is always installed this could already be
 done with:

 Supplements: langsupport-de

 The benefit of this approach is that installing a new langsupport-XX
 package will bring in the locale packages for all packages making use 
 of this mechanism.
 
 Could that even be done automatically by rpmbuild?
 
 Just like rpmbuild automatically generates a -debuginfo with the right
 files in it, could it generated the -lang-xx packages with the .mo
 files inside, and add the Supplements dependency you suggest?
 
 Because doing it manually for all the languages supported by an
 application (which might vary from release to release) would be pretty
 awful. :-/

In theory, yes. In the end we'd need something like find-lang.sh that
actually spits out the packages to be included in the main spec file.
debug-info packages are done that way. But it is not pretty.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Florian Festi]

On 07/28/2015 09:43 AM, Lubos Kardos wrote:
 Support in rpm is not enough but libsolv supports rich deps since the version
 0.6.9 too thus rich deps work also in hawkey and dnf if the version 0.6.9 or
 a newer version of libsolv is installed.

Right now only AND and OR is supported by libsolv. Implementation of IF
ELSE is still pending.

Also we still need to settle to a final syntax for the operators [1].
Unfortunately there is no consensus among the other packaging formats
what to use. Right now rpm accepts 3 different styles:
 * AND OR IF ELSE
 *  | ? :
 *  || ? :
But the final release will only support on of them. As soon as the alpha
stops eating babies that's a discussion we need to have.

So for now they are more a tech preview in Fedora but we want to get
them operational til the release. This still means that they are not
supposed to be used in F23 as they may only completely work very late.
Also there is still a lot of paper work to do for the packaging policy.

I expect that both Boolean Deps and File Triggers won't be introduced in
one go but there will be multiple Fedora Features introducing them one
use case at a time. E.g. one feature per file trigger replacing one kind
of scriptlets. Boolean dependencies being used for language packs being
one Feature/Package Policy section and other use cases being others.

This may start in the F24 time frame - especially for some urgent corner
cases - but my guess is that this will rather take multiple releases.

Florian

[1] http://rpm.org/wiki/PackagerDocs/BooleanDependencies

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Florian Festi]

On 07/28/2015 02:49 PM, Vít Ondruch wrote:
 Just out of curiosity, do you have already any candidates for File
 Triggers? I suppose /sbin/ldconfig is one of them. Do you plan to have
 some F24 feature to get rid of these?

Well, we do not yet have concrete plans with which scriptlets to start.
 https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Snippets is
full of possible candidates. I still have to figure out how much I want
to push this as the rpm upstream developer or how far I can leave this
to the Fedora community and just provide technical support. I guess I
will at least start with one and then see if people pick that up.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Florian Festi]

On 07/26/2015 08:18 PM, Kevin Fenzi wrote:
 On Sat, 25 Jul 2015 13:31:45 +0200
 Remi Collet fed...@famillecollet.com wrote:
 
 Le 25/07/2015 13:20, Florian Festi a écrit :
 On 07/25/2015 11:18 AM, Remi Collet wrote:

 Thanks for catching that!

 Do you want me to file a bug ?

 Yes, please!

 FYI https://bugzilla.redhat.com/show_bug.cgi?id=1246743
 
 Just FYI, this landing on friday afternoon/evening resulted in no
 rawhide composes this weekend. :( 
 
 Next time can you give more notice, and/or rebuild at least
 createrepo_c, fedup-dracut, and drpm? Those are the minimum needed to
 make the mock root that rawhide composes use. 

Sorry, I am still new to this releasing rpm business. I had hoped that
only pushing stuff in rawhide and not in F23 would stay off most peoples
toes. I'll try to be more careful next time.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Florian Festi]

On 07/25/2015 11:18 AM, Remi Collet wrote:
 %doc imagick-3.1.2/{CREDITS,TODO,INSTALL}

To give a bit more context:

Globs with braces have not been supported in rpm's %files section ever.

But https://bugzilla.redhat.com/show_bug.cgi?id=728959 caused all kind
of docs file being added to the package and files not being properly
checked. As a result such constructs as
imagick-3.1.2/{CREDITS,TODO,INSTALL} - which are not at all supported -
did not result in an error.

As we fixed that bug rpm spits out an error - quite correctly. But
actually there is no good reason to not support braces in the globs,
especially as it is just one flag to set internally. So we added the
support and the package should now build.

But still packages with broken doc entries may refuse to build. Please
fix them if you encounter such errors. This is one of the many cases
were making rpm do the right thing and do the proper checks breaks
broken packages.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Florian Festi]

On 07/27/2015 04:55 PM, Lubos Kardos wrote:
 The current behavior is right. Your install script insert files into buildroot
 and these files are not listed in %files section.
 
 Correctly you should replace this:
 
 %files
 %doc AUTHORS COPYING NEWS README
 ...
 
 with this:
 
 %files
 %{_pkgdocdir}/AUTHORS
 %{_pkgdocdir}/COPYNIG
 %{_pkgdocdir}/NEWS
 %{_pkgdocdir}/README
 %{_pkgdocdir}/ChangeLog
 %{_pkgdocdir}/TODO
 ...
 
 Tag %doc followed by relative path of a file is used when you want rpm to copy
 files from BUILD to BUILDROOT document directory but in your case this is done
 by your install script.
 
 Lubos


 there is another change involving %doc. A piece of libdvdread.spec: 
 %files
 %defattr(-,root,root,-)
 %doc AUTHORS COPYING NEWS README
 %{_libdir}/libdvdread.so.*

 %files devel
 %defattr(-,root,root,-)
 %doc ChangeLog TODO
 ...

RPM actually copies those to
/builddir/build/BUILDROOT/php-pecl-imagick-3.1.2-3.fc24.i386/usr/share/doc/php-pecl-imagick-devel/
and includes them into the devel package.

It now refuses to use the copies in
/builddir/build/BUILDROOT/php-pecl-imagick-3.1.2-3.fc24.i386/usr/share/doc/php-pecl-imagick
which have previously been added to the main package erroneously.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Florian Festi]

On 07/25/2015 11:18 AM, Remi Collet wrote:
 Le 24/07/2015 15:49, Florian Festi a écrit :
 The freshly released rpm-4.12.90 aka rpm-4.13.0-alpha is going to hit
 rawhide soon. The two major new features are:

  * Boolean (aka rich) dependencies to support more complicated relation
 between packages
  * File Triggers - run scripts if files get installed in given paths -
 possibly to replace most of the regular - per package - scriptlets at
 some point in the future.

 But for now and for Fedora this update is more about testing and
 stabilizing the many smaller changes as far as they have not been ported
 back already.

 See the draft release notes for details: http://rpm.org/wiki/Releases/4.13.0
 
 It seems we have a regression (thanks Koschei)
 
 See https://kojipkgs.fedoraproject.org/work/tasks/4402/10474402/build.log
 
 In spec (which is quite common, I think)
 
 %doc imagick-3.1.2/{CREDITS,TODO,INSTALL}
 
 During %doc
 
 + cp -pr imagick-3.1.2/CREDITS imagick-3.1.2/TODO imagick-3.1.2/INSTALL
 /builddir/build/BUILDROOT/php-pecl-imagick-3.1.2-3.fc24.i386/usr/share/doc/php-pecl-imagick
 + exit 0
 RPM build errors:
 error: File not found:
 /builddir/build/BUILDROOT/php-pecl-imagick-3.1.2-3.fc24.i386/usr/share/doc/php-pecl-imagick/{CREDITS,TODO,INSTALL}
 File not found:
 /builddir/build/BUILDROOT/php-pecl-imagick-3.1.2-3.fc24.i386/usr/share/doc/php-pecl-imagick/{CREDITS,TODO,INSTALL}

Thanks for catching that!

 Do you want me to file a bug ?

Yes, please!

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[HEADS UP] rpm-4.12.90 in rawhide

[Florian Festi]

The freshly released rpm-4.12.90 aka rpm-4.13.0-alpha is going to hit
rawhide soon. The two major new features are:

 * Boolean (aka rich) dependencies to support more complicated relation
between packages
 * File Triggers - run scripts if files get installed in given paths -
possibly to replace most of the regular - per package - scriptlets at
some point in the future.

But for now and for Fedora this update is more about testing and
stabilizing the many smaller changes as far as they have not been ported
back already.

See the draft release notes for details: http://rpm.org/wiki/Releases/4.13.0

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

New Rpm-ecosystem Mailing List

[Florian Festi]

Hi!

tl;td: Join at http://lists.rpm.org/mailman/listinfo/rpm-ecosystem if
your interested in any part of the rpm ecosystem.


While there are quite some mailing lists already that deal with the
different tools around and including rpm we realized that there is no
good place to discuss issues that involve multiple parts of (our own)
package handling stack even less so to stay in contact with other rpm
based solutions. To solve this we create a new mailing list:

rpm-ecosys...@lists.rpm.org

Normal user questions and development talk is supposed to stay on the
per project mailing lists. The new list is for questions like:

 * How do other implementations handle specific problems?
 * Is this new feature interesting for downstream distributions?
 * How do the different packaging guidelines treat a special topic?
 * Anyone there to support our demand for this new rpm feature?

And it is for topics like:

 * Packaging guide lines
 * RPM features
 * Build systems and compose tools
 * Dependency solvers, installers and updaters
 * RPM based image creation / non rpm based updates for rpm
   based distributions

In short: It is meant to bind the rpm universe together.

Join at http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Please forward this mail to anyone that might be interested - especially
to rpm related sub projects and groups.

Thanks!

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: minimal requirements for subpackage named common

[Florian Festi]

On 04/28/2015 03:15 PM, Jan Chaloupka wrote:
 Hi,
 
 I have a package (kubernetes) which I would like to decompose into 2
 subpackages A and B. Problem is A and B share some files and directories
 so installing both of them on the same machine results in file
 conflicts.

Another way of avoiding this problem is to make sure these files are
100% identical. This includes modification time, user, permissions and
of course content.

But as you are using the same files from the identical build I kinda
wonder where such differences could come from...

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rpm 4.12 and weak dependencies

[Florian Festi]

On 10/09/2014 05:29 PM, Jerry James wrote:

Added most of your improvements to the page.

Thanks!

Florian


PS: The rpm.org wiki is locked down because of spam. But people
inerested in improving the contents and documentation can just create an
account and ask for edit privileges on the mailing lists or #rpm.org
@freenode.

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Florian Festi]

On 10/06/2014 05:16 PM, Gerald B. Cox wrote:
 The fact that some users have more bandwidth means exactly
 what?  Most people also have faster processors and disks now.  It is
 more efficient from a networking perspective to minimize unnecessary
 traffic and use local processing.  That was behind the rationale when
 delta was introduced and made the default.  It was valid then, and it is
 valid now.

This argument is not valid. While most parts of a computer got faster
things are not growing at the same rate. So what might have made sense a
few years ago might be completely useless now.

One thing that makes deltarpm less useful nowadays are seek times in
hard disks (although they are going away). They are still the same as in
the nineties  while the number of files have been growing.

At the same time network bandwidth has been growing at a faster rate as
everything else.

So if you want to make an argument for deltarpm, please do so but do not
try to convince us to buy into an outdated rational.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Florian Festi]

On 10/06/2014 06:53 PM, Jonathan Dieter wrote:
 Get to coding. ;)
 
 As mentioned elsewhere, the problem *is* signatures.  yum (quite
 rightly) refuses to install an rpm whose signature doesn't match the one
 in the primary repodata.  And I believe that the signature in the RPM is
 also over the whole compressed rpm.  To make this work, we'd need to add
 an uncompressed signature for every package to the primary repodata as
 well as probably the rpms themselves.

 We have already written the code to have yum run applydeltarpm in
 parallel according to the number of processors on a system, but it
 remains a single-threaded application that spends most of its time
 recompressing the data.

The way of getting around all this unnecessary computation is
establishing trust via the deltarpm itself and giving up the idea of
reconstructing the originally rpm as a prove of everything worked out
just fine.

To save even more time the delta would need to be applied directly on
disk without creating an package at all. This would require a deeper
integration with rpm and requires some tricky algorithms to make sure
everything is ok in advance and won't blow up during the rpm
transaction. So if anyone needs a hobby...

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Heads-up on rpm 4.12 coming to rawhide soon

[Florian Festi]

On 07/02/2014 03:05 PM, Igor Gnatenko wrote:
 Where I can read more about weak dependencies?

Have a look at my announcement I made in February:

https://lists.fedoraproject.org/pipermail/devel/2014-February/195743.html

Be aware that rpm-4.12 only implements the weak dependencies. Having
support in RPM is also only the first step for getting it into Fedora.
Support is needed throughout the packaging stack. As soon as all pieces
are in place and are well tested the FPC needs to come up with a policy
on how they should be used.

Florian


 --
 -Igor Gnatenko
 
 On Jun 27, 2014 7:38 PM, Panu Matilainen pmati...@laiskiainen.org
 mailto:pmati...@laiskiainen.org wrote:
 
 
 Hi all,
 
 Rpm 4.12 alpha just got released:
 http://lists.rpm.org/__pipermail/rpm-announce/2014-__June/45.html 
 http://lists.rpm.org/pipermail/rpm-announce/2014-June/45.html
 
 The plan is to update rawhide to this shiny new version first thing
 on Monday morning and babysit as needed (ie the usual drill), but if
 you're feeling bored over the weekend or its as rainy wherever you
 live as it is in here now, and you're feeling a little bit brave,
 give it a spin in the meanwhile:
 
 https://copr.fedoraproject.__org/coprs/pmatilai/rpm-__snapshot/
 https://copr.fedoraproject.org/coprs/pmatilai/rpm-snapshot/
 
 The copr packages are for rawhide only and should be very close to
 what goes into rawhide on Monday. If you're dying to test but not
 willing to rawhide all the way, they can be used on F20 too if you
 1) install perl-generators from rawhide
 2) remove rpm-python3 package before updating
 
 As the announcement says, there are some rough edges still (as in,
 there's a reason its alpha). I run it on my systems and it's not
 expected to eat anybody (or their systems) alive, but do pay
 attention...
 
 Bug reports and other feedback welcome.
 
 - Panu -
 -- 
 devel mailing list
 devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org
 https://admin.fedoraproject.__org/mailman/listinfo/devel
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-__of-conduct
 http://fedoraproject.org/code-of-conduct
 
 
 


-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: trimming down Fedora installed size

[Florian Festi]

On 04/10/2014 09:53 PM, James Antill wrote:
  20 | 38,561 |  38 G  | 19M

So there are 20MB of meta data that need to be downloaded once. This can
hardly be a problem - even if the size tripled.

 same thing for updates gives:
 18 | 18,606 |  20 G  | 12M

Ok, let this be another 20MB for the updates during the life time of an
Fedora release. This would also not be an issue if we had not to
download this file over and over again and then inflate it to ten times
it's size.

The main issue here is not the amount of data but the way yum handles it
and the refusal of yum upstream to even consider an efficient meta data
handling by insisting on the reconstruction of transport representation
on the client side.

In the end we need a saner MD handling no matter if we go for finer
grained packages or not. I hope DNF will be able to provide this at some
point when they are done with the more basic things.

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: trimming down Fedora installed size

[Florian Festi]

On 04/09/2014 01:50 PM, Stephen Gallagher wrote:
 On 04/09/2014 07:23 AM, Jóhann B. Guðmundsson wrote:
 
 On 04/09/2014 07:33 AM, Marius A wrote:

 Are there any other disk space saving tips?
 
 Users should not have to result doing disk saving tips.
 
 I would say in the long run we should be working towards creating
 separated locale,doc,man packages
 
 Hmm, I wonder if RPM 4.12 would allow us to do this with weak
 dependencies?
 
 Perhaps something like having a metapackage on the system for docs and
 one for each language. Then we could break up the doc and language
 packages into sub-packages that are installed conditionally on the
 presence of that metapackage on the system.
 
 Of course, I think there would still be work needed in RPM to support
 adding a language later, but maybe we could solve that with special
 tooling or a yum plugin.

Yes, this is one of the reasons we go for more expressive relations in
RPM. You already very closely describe what I have in mind.

There are basically two possible ways of making the distribution more
flexible in the future:

1) Normal weak dependencies. In a normal install all the docs (and all
other bells and whistles) get installed by default. You can
remove/deselect packages which are pulled in by weak dependencies. You
can even switch off all weak dependencies to only get the core packages.

2) Rich dependencies. Doc and language packages can be build as
bridging packages that are only installed if two other packages are
present. This can be done by adding e.g.

Recommends: foo-langpack-hu if langsupport-hu

to package foo or

Supplements: foo and langsupport-hu

to the foo-langpack-hu package. Similar things can be done for docs or
any other set of packages that should be controlled by a single switch
package.

The nice thing about this is that no additional tooling is needed.
Installing foo will automatically install the lang packs for all
installed languages and installing a new langsupport package will
install the langpacks for all installed packages.

The plan is to get all pieces for 1) into F21. So it could already be
used for F22. I will try to get 2) ready in this time frame, too, but
the bets are still open.

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: trimming down Fedora installed size

[Florian Festi]

On 04/09/2014 04:53 PM, Matthias Clasen wrote:
 From the desktop/workstation perspective, here are a few things I would
 like to see if we decide to work on this:
 
 Support for a new locale is more or less like a 'system extension' for
 the OS. It would be good to define clear rules for what it means to
 provide a subpackage that becomes part of this system extension.

Yes, but my guess this is not very complicated. Natural languages are
pretty straight forward. All other 'system extension' will basically
come with their own description. We just have to make sure that the
description as shown to the user is not completely ignored by the
packages using it.

 In an ideal world, this could even be automatic and pattern-based (e.g.
 if you install anything into /usr/lib64/gstreamer-1.0, you are providing
 a 'codec' extension, and all the files below that directory belong to
 it).

*cough* *cough*

 To present this in the UI, we need to know the available 'extension
 points' (either a fixed list, or a way to enumerate them), as well as
 the installed and available extensions for each, including suitable
 metadata (name+short description at least).

We need the rethink the whole packaging UI anyway. Comps still has all
its known problems. SoftwareCenter has its own, very special view on the
packages, and no one has a clue how to make use of the weak weak
dependencies (which are not completely unlike optional packages in comps).

So making the number of installed and available packages more manageable
is one of the next big things that need to be done after the basic
infrastructure is in place.

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: trimming down Fedora installed size

[Florian Festi]

On 04/09/2014 05:23 PM, Stephen Gallagher wrote:
 This construct would be extremely valuable to the SSSD as well:
 
 %package -n client
 Recommends: sssd-client.i686 if glibc.i686

That's not exactly by accident...

 It's pretty easy to install a language at package-install time, but in
 order to add the language subpackages for all installed packages on
 the system if the new langsupport package comes in will mean
 re-processing all of the dependencies on the installed packages.
 Probably very slow, but certainly valuable.

Well, there is a reason why Fedora is moving to a new dependency solver.
I am pretty optimistic about performance.

 The plan is to get all pieces for 1) into F21. So it could already
 be used for F22. I will try to get 2) ready in this time frame,
 too, but the bets are still open.
 
 This would be fantastic, now we just need the FPC to agree. Might be
 worth filing an FPC bug or two now for them to debate before pushing
 too hard here.

For now there is just https://fedoraproject.org/wiki/Changes/RPM-4.12

I will talk to the FPC as soon as the parts are all in place. Be aware
that it is not enough to just implement the stuff. It needs to be tested
and to make its way to the builders. Even with a hurry things need quite
some time in RPM land.

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: trimming down Fedora installed size

[Florian Festi]

On 04/09/2014 08:42 PM, Bill Nottingham wrote:
 Given the number of packages that ship localization, this seems like it
 would have a pretty dramatic effect on metadata size. Is this a concern?

Meta data is a concern. But the major part of the meta data is file data
and change logs. Everything else is less than 10%. So doubling or even
tripling this part won't hurt.

The actual issue we have with meta data is that is is downloaded over
and over again (for updates). Should we ever get this fixed the growth
of meta data is no longer an issue.

Florian

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: python packages versus pydoc -k

[Florian Festi]

On 03/14/2014 08:05 AM, Bohuslav Kabrda wrote:
 - Original Message -
 Sorry, I should have tried pdb first, because this one has nothing to do
 with rpm-python.  I can see modname='PyQt4.uic.pyuic', and prior to the
 exception site is a line 'loader = importer.find_module(modname)', which
 is where the None came from.  I can confirm this one in a clean mock
 root with just PyQt4 added (and its dependencies).

 This one might be a bug in the way pydoc -k iterates, because I can't
 even target that name directly:

 $ pydoc PyQt4.uic.pyuic
 no Python documentation found for 'PyQt4.uic.pyuic'

 $ python -c 'import PyQt4.uic.pyuic'
 Traceback (most recent call last):
   File string, line 1, in module
 ImportError: No module named pyuic

 
 It seems that PyQt4/uic/pyuic.py is a symlink to /usr/bin/pyuic4, which is in 
 PyQt4-devel. This means that the file is not importable when PyQt4-devel is 
 not installed.
 IMO this is both:
 1) packaging problem, since the symlink shouldn't be there if the file it 
 points to isn't installed.
 2) pydoc problem, because it should try/except broken and unimportable files
 
 I opened a rhbz#1076346 for 1)
 And I'll try to figure out a good patch for upstream and send it there to fix 
 2)

Thanks for taking care of this, guys!

Florian

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: python packages versus pydoc -k

[Florian Festi]

On 03/12/2014 08:18 PM, Josh Stone wrote:
 For instance, right now I get:
 
 $ pydoc -k xyzzy
 lib2to3.fixes.fix_repr - Fixer that transforms `xyzzy` into repr(xyzzy).
 Traceback (most recent call last):
   File /usr/bin/pydoc, line 5, in module
 pydoc.cli()
   File /usr/lib64/python2.7/pydoc.py, line 2292, in cli
 apropos(val)
   File /usr/lib64/python2.7/pydoc.py, line 1992, in apropos
 ModuleScanner().run(callback, key, onerror=onerror)
   File /usr/lib64/python2.7/pydoc.py, line 1973, in run
 module = loader.load_module(modname)
 AttributeError: 'NoneType' object has no attribute 'load_module'
 
 It's hard to track that down, but with strace -e open it looks like
 somewhere in site-packages/rpm/.  I couldn't figure out exactly which
 subpackage is triggering this.

I really would like to get this fixed if it really is a problem in
rpm-python. But someone needs to come up with some better error messages
or other way of finding out what the actual problem is. After a quick
view in the pydoc doc I am no longer sure that this is an rpm problem,
though. This could also be a bug in pydoc or pkgutil or some other
python module being processed.

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM

[Florian Festi]

On 02/20/2014 11:50 PM, Adam Williamson wrote:
 On Thu, 2014-02-20 at 14:44 +, Colin Walters wrote:
 On Thu, Feb 20, 2014 at 7:27 AM, Florian Festi ffe...@redhat.com 
 wrote:

 We are currently working on adding weak and rich dependencies to
 upstream RPM. There are basically two parts:

 Is someone signed up to do the necessary frontend work for this on the 
 dnf/yum side?  If we're allowing choice of A | B like this, there 
 needs to be a frontend that actually allows choosing, like aptitude.
 
 Fedora isn't signed up to *use* it yet. We can still make the choice
 whether we want to or not, I believe.

Yup. And more important how to use them. While the two levels of
weakness is the most obvious feature it is IMHO not the most important
one. We are basically introducing the weaker level only for two reasons:
That's what all other implementations do and it matches the structure of
comps and thus may allow doing something group like in native rpm terms
in the future.

I have not yet seen an convincing use of those levels of weakness. If
Fedora is willing to put some serious effort into this it might being
used to have different package sets for the different Fedora.next
products by setting different defaults. But whether that's feasible is
still an open question IMHO.

The more interesting features are:

No longer rely on other packages. With foo or bar you can choose
between packages that do not have a common provide. With the reverse
relations you can attach your package to another one without changing
it. Being able to create 3rd party packages was one of the design goals
of RPM and not being able to do such things from your own package breaks
that. While this is not that important for the closed world view of a
distribution it will become more important with COPR.

Another important thing is being able to deal with more complicated
situations. One kind are multilib problems like #442047 and #663269. I
am pretty sure there are others, too.

More interesting from a user perspective are bridging packages like
language packs (see my previous mail) or optional plugins. Right now we
need hand coded solutions like yum-langpack for something that should
just be done by the packaging system.

Florian

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM

[Florian Festi]

 Original Message 
Subject: [Rpm-maint] Heads up: Weak and rich dependencies in RPM
Date: Thu, 20 Feb 2014 13:12:43 +0100
From: Florian Festi ffe...@redhat.com
To: rpm-ma...@lists.rpm.org, rpm-l...@lists.rpm.org

Hi!

We are currently working on adding weak and rich dependencies to
upstream RPM. There are basically two parts:

#1 Adding weak dependencies as already used by SuSE and others:
Recommends:, Suggests:, Supplements: and Enhances:. We agreed with
Michael Schröder to not use SuSE's current implementation but to add new
tags for a cleaner interface and an easy update path for already
existing packages. This is planned to be part of the next RPM version.

As old tools will just ignore the new tags this isn't a big
compatibility issue. Support in rpmbuild can probably back ported easily.

#2 Allow Boolean expressions of (Name Flag Version) terms in Requires:,
Conflicts: and the new weak dependencies (rich dependencies). This will
add a new expressive strength to RPM's dependency model and allow fixing
a couple of packaging problems we don't have a solution for
right now and also get rid of some special case solutions like hand
coded language pack support. As we are still figuring out some of the
implementation details and implications this feature may or may not make
it in the next release.

Packages using such Boolean expressions will not work with old versions
of rpm and other related tools and it is still unclear to what extend
this feature can be back ported.



What implication does this have on your distribution?


Stuff affecting other distributions left out

Getting the support into createrepo and libsolv is taken care of. This
should cover Fedora and OpenSUSE and may be others.



I wrote a document describing more technical details. Find it attached
to this mail.

Florian






rich_relations.odt
Description: application/vnd.oasis.opendocument.text
___
Rpm-maint mailing list
rpm-ma...@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM

[Florian Festi]

On 02/20/2014 03:44 PM, Colin Walters wrote:
 On Thu, Feb 20, 2014 at 7:27 AM, Florian Festi ffe...@redhat.com wrote:
 We are currently working on adding weak and rich dependencies to
 upstream RPM. There are basically two parts: 
 
 Is someone signed up to do the necessary frontend work for this on the
 dnf/yum side?  If we're allowing choice of A | B like this, there
 needs to be a frontend that actually allows choosing, like aptitude.

Yes and no. Right now there is no plan to allow the user to do the
choosing. This ambiguity already exists in the current relations and we
will continue to handle it automatically.

 I guess one could go with the shortest package name wins approach or
 whatever the current heuristic is for now...

The heuristics will improved though. Libsolv already uses weak
dependencies to choose the more desired package. I hope we can add
support for preferring the more left packages over later packages in
such or-clauses. That way
Requires: sendmail or postfix
would prefer sendmail while
Requires: MTA
chooses one of them the by some unrelated criteria.

 This is also relevant with things like kickstart files, where there is
 no interactivity allowed.
 
 (For what it's worth I think making packaging even more complex and less
 predictable in order to increase flexibility is precisely the opposite
 direction of what we should be doing...but that's OK because I am coming
 at this from the other direction.  We'll meet in the middle somehow ;) )

Actually I am on your side of the argument. This effort is supposed to
give better control over how packages behave and relate to each other
*to the packager*.

While A or B is an often demanded feature the main reason for this are
relations that span a longer distance. E.g. Foo-langpack-es could
Supplement: Foo and langsupport-es
Or to implement the same behaviour with a forward dependency
package Foo could
Requires: Foo-langpack-es if langsupport-es

Both variants pull in a intermediate package (Foo-langpack-es) if two
packages are present (Foo and langsupport-es).

Florian

PS: I actually do think that we need to give the user more control over
the packages, too. The current tools are completely inadequate to manage
the number of packages we have in the distribution or even just on a
system. But this is a story for another time.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Trimming (or obsoleting) %changelog?

[Florian Festi]

On 04/17/2013 07:03 PM, drago01 wrote:
 Why does it have to be date based?
 Why not having a count based cutoff?
 Like last N entries.

There used to be a count based trimming in rpm  4.0. I guess the
rational behind a date based approach is that this way entries do not
disappear unexpectedly. As I understand it the feature is meant to be
used on a per package basis. This way you can just add new entries
without bothering about the change log trimming and from time to time
(e.g. once a year) adjust the date to something more appropriate.

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Florian Festi]

On 04/17/2013 10:25 AM, Dan Fruehauf wrote:
 That's around 50K, and compressed (RPMs are compressed):
 $ rpm -q --changelog binutils | gzip | wc -c
 15552
 
 15K is nothing. Really. I like to see the whole history of a package,
 it's nice and fun.

That's not correct. The change log is stored within the rpm header which
is not compressed. While there have been efforts to compress the header
those changes have not (yet) made it upstream as it would make rpm
packages completely incompatible with older rpm versions.

For limiting the change log entries in the binary packages
%_changelog_trimtime can be used that take a unix time stamp as an
integer value. This way the whole history is still available in the spec
file.

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Florian Festi]

On 04/17/2013 12:18 PM, Mathieu Bridon wrote:
 On Wed, 2013-04-17 at 12:10 +0900, Florian Festi wrote:
 For limiting the change log entries in the binary packages
 %_changelog_trimtime can be used that take a unix time stamp as an
 integer value. This way the whole history is still available in the spec
 file.
 
 Could redhat-rpm-config set that automatically, for example to the
 release date of Fedora N-1?

From a technical POV: Yes, very easily.

Figuring out if this really is a good idea and convincing all necessary
Fedora committees is left as an exercise for the reader.

Florian

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: package, package2, package3 naming-with-version exploit

[Florian Festi]

On 04/04/2013 01:55 PM, Vít Ondruch wrote:
 I am not asking RPM developers to change policy, I am asking RPM
 developers to lay out foundation. It does not make sense to change
 policy, if there are no tools to fulfill it.

Well, Fedora demanding a set of tools will much more likely result in
some action. Also a policy about multi version packages can be put in
place independent of a technical implementation.

 Well, if somebody wants to maintain some package, it probably doesn't
 matter which version. If somebody is qualified enough to maintain
 version X-1, (s)he is probably qualified enough to maintain version X.

This is not about qualification but about will to do the work. If the
owner of the package is unwilling to maintain another version and
unwilling to let you playing his sandbox just having a new tree is a
good solution.

 Ok, so what is the purpose of version field than? Lets drop it, if
 nobody cares. You could remove a few lines in Fedora, depsolver could be
 dumber.

Well, I tried to explain that in my first mail. Read it again.

 Yes, I am exaggerating here, but does it make sense to have package
 python3-3.3? Why we don't have python3-1.0? Where is the version 1.0 of
 python 3? Why we duplicating the version? Non of these question makes
 you think that we are doing something wrong?

No, I just don't care. You can use what ever you want as name or
version. Rpm just cares if the name of two packages are the same and if
one version is considered bigger, smaller or equal according to a quite
obscure set of rules.

Feel free to have python3-1.2-0 providing Python = 3.1.2


 Yes, this is install only packages variation and this is the most
 basic scenario I'd love to see in Fedora.

Well, as I and Seth already told you the tools kinda do support this
scenario. As this is not actually used, I'd guess that there are still
some bugs or missing features to actually make this work. If you want to
do something constructive just try this out and file precise bugs to
make installonlypkgs work for your use case. As always supplying patches
might speed things up.

 Extension of this is that you should be able to update installed package
 of specific version, if its new release is available. That would allow
 to fix security issues in older packages.

I doubt that this will make it into yum. May be you can convince the dnf
developer as the dnf depsolver is better suited to deal with the
scenarios that arise from such a feature.

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: package, package2, package3 naming-with-version exploit

[Florian Festi]

On 04/04/2013 03:42 PM, Vít Ondruch wrote:
 Although they might support, and Kernel would be first user, even for
 Kernel, there is used hack instead of systematic solution as far as I
 know. As long as Kernel will be treated specially in this regard, there
 is not much to do on my side.

As long as you are not willing to look into the details much deeper your
cause is doomed.

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: package, package2, package3 naming-with-version exploit

[Florian Festi]

On 03/29/2013 10:33 AM, Bohuslav Kabrda wrote:
 To me, these are very different aspects - should RPM/YUM be able to support 
 multiple parallel versions without the naming hacks? Yes. Should Fedora as a 
 distro support numbers of multiple versions of packages? In my opinion, we 
 should try to keep counts of supported packages minimal, as we do now. But 
 that doesn't really depend on _how_ we package the stuff.
 This is about providing the tooling to people who actually want to maintain 
 these more versions in their private repositories or whatever.

Sorry, but this is not how we as an upstream project think. We calculate
the benefits against the costs. The costs of breaking/changing such a
fundamental rules as name.arch defines an update path is extremely
high. If there are only a few packages that require that feature and
they only benefit marginally there is absolutely no way to outweight
these costs.

If there were thousands multiversion of packages that were suffering
from these limitations and such a change would make all that pain go
away (I won't) the decision would likely be the opposite. Such situation
would also make it much easier for the users to understand the situation
as they would deal with multiversion packages on a daily basis.

But despite people wining loudly there are only a few dozen packages
barely justifying the discussion.

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: package, package2, package3 naming-with-version exploit

[Florian Festi]

On 03/28/2013 05:45 PM, Vít Ondruch wrote:
 Sorry to say that, but neither my sarcasm nor your comment brings
 anything new. If this problem was put first time on the table in 2002,
 then there already passed 10 years of excuses.

Well, this does not even roughly reflect the history of rpm. You are
also pointing at the wrong people as no one of the current team has been
working on rpm 2002. There have been dark ages in between when rpm
development had basically stopped. It took one year just to integrate
the bug fixes piled up during this time when development was picked up
again with the 4.4.2.x series.

Since then lots of work had to be invested just to catch up with the
grown demands of modern distributions and computers. And this is still
not achieved yet.

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: package, package2, package3 naming-with-version exploit

[Florian Festi]

On 04/03/2013 12:58 PM, Vít Ondruch wrote:
 The only thing you get wrong is that you take a look at Fedora packages
 and do some statistics. You don't see the packages which could be in
 Fedora if RPM/YUM would do better job.
 
 Just as an example, I guess everybody would welcome Redmine [1] in
 Fedora (you can substitute GitLab [2] or Aeolus [3] for Redmine if you
 like). It was not possible to do so for several releases of Fedora,
 since Redmine was using Ruby on Rails 2.3 where in Fedora, there was
 Ruby on Rails 3.x. If we would like to move to Ruby on Rails 4 in Fedora
 as soon as they'll be releases, we will have actually two options (1)
 forget about the upgrade of Ruby on Rails in Fedora and wait for
 upstream or possible become upstream, to help with migration of the
 project (2) break Redmine and every application which is using Ruby on
 Rails in Fedora. Neither of these options are good options. So the
 easiest solution is to not have Redmine in Fedora at all.
 
 So now, please, could you count also the cost of missed opportunities?

I have some difficulties believing that the only reason for this is that
the name rubygem-rails was already taken. May be you can elaborate a
bit more why getting Rails 2.3 into Fedora would have been fundamentally
easier if the name was still available?

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: package, package2, package3 naming-with-version exploit

[Florian Festi]

On 04/03/2013 05:02 PM, Vít Ondruch wrote:
 Dne 3.4.2013 15:59, Miloslav Trmač napsal(a):
 On Wed, Apr 3, 2013 at 3:22 PM, Vít Ondruch vondr...@redhat.com
 That looks quite simple, but you doesn't count that what is called
 Ruby on Rails is collection of 40 packages (the number vary from
 version to version, but tends to increase), which would need to be
 re-reviewed, although they were just perfect moment ago.

Sorry, but the rpm developers are the wrong people to talk to when it
comes to Fedora packaging policies.



 Ok, so lets say we introduce the rails23 compatibility packages
 (which is IMO the better option, since the nonversioned package
 should always point to newest and greatest release), we do the
 reviews and we possibly double the amount of packages. We even fix
 all the application dependencies from rubygem-rails to
 rubygem-rails23.
No, you should just add an virtual provide for rubygem-rails = 2.3.x You
might still need to fix your applications as they most likely won't run
with Rails 3 but not requiring rubygem-rails  3 but that's another problem.


 Yes, they would be in one git repo with single maintainer (or group of
 maintainers). Although it does not ensure much, there is higher chance
 that the package will be consistent, i.e. that security fix will be
 applied in all branches. You can use all nice git features to easy your
 work.

I had rather expected that not having the two versions in the same tree
is an advantage as it allows different people to step in without messing
with the main package.


You somehow assume that just because we add some magic in rpm things in
Fedora change dramatically. I see no reason why creating a new version
should be any easier than creating a new package. With some work (and
surely less than needed for your proposal) on the build system forking
off a package with a new name could be as simple as any other solution.

The same is true for the git trees. Implementing a way of moving some
patches between different trees and packages is much easier than making
multiple versions out of one tree work. This can probably even be done
locally without asking anyone within Fedora.

 Yes, you might change the policy that re-reviews are not
 necessary, but anyway, you'll end up with mess of packages such as
 rails23, rails30, rails31, rails32, rails40 and you lost the
 meaning of version. Actually then somebody comes and he things
 that he doesn't need just Rails 3.0, but he needs specifically
 Rails 3.0.5, so he well do another new package rails305. You
 cannot stop this explosion of various versioned modules.

I got that you really, really, really don't like the package names. But
the number of packages is actually exactly the same as with your own
proposal. Yes, it is ugly to have all those different packages - but
this is what you are asking for. The fact that they all share the same
name do not reduce their numbers.

 It would help, since I could focus on packaging new rails version
 instead of fixing compatibility issues of current applications in Fedora
 with the framework they use. That would be application upstream
 responsibility. Once upstream would be ready to move forward they could.
 Now either upstream is ahead of Fedora or Fedora is ahead of upstream of
 the application. We are rarely lucky that we would be in sync.


Yes, I got the reason why multiple version of a package are needed. But
that does not require them having the same name.


 There is even little motivation to do some continuous updates of Rails
 in Rawhide, since where is the point? It would just become moving
 target. While if I could keep behind each version packaged, it would
 make sense and find its users definitively.

There is a slight difference here to what was originally proposed. I had
assumed the people involved got this subtle difference but I am not
sure. So I repeat it here:

There are two (from my POV) very different way how this could work:

1. As described in the thread. There are separate branches that only
have one newest and supported package. This can be done with either
separate package names or some added magic that basically make the
packages behave as if they had different names. This magic requires
altering the packages. So you cannot just use the old packages. You
either rename them or add the magic to tell them their new update behaviour.

2. You just keep all versions of the packages of one single line of
updates and teach the depsolver (yum, dnf, rpm cli or whatever) to deal
with that in a way you like. People opting for an old package do not
receive updates (or are responsible themselves to choose a newer package
either by hand or by telling the depsolver which ones to consider.) This
way the package maintainer is not responsible to update any but the
newest version and does not even have to know about you using old
versions. If you have a repository that keeps the packages this should

Re: [renrot] Comment out Requires(hint)

[Florian Festi]

On 06/20/2011 04:41 PM, Andy Shevchenko wrote:
 Does it mean we are still don't have suggestions?
No, we don't.
 Anyway, it seems more proper to get it fixed is to put normal
 Request tag instead of Request(smth). Isn't it?
Depends on what you want. You can convert it into a regular requires to 
keep the previous behavior but if the package is not really required and 
you can also just drop it.

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PackageKit in Fedora 15 (beta)

[Florian Festi]

On 04/26/2011 05:21 PM, Matej Cepl wrote:
 Dne 26.4.2011 15:31, Kevin Kofler napsal(a):
 AIUI, Suggests/Recommends was almost accepted in rpm.org (BTW, rpm5.org has
 had it for ages), but the yum developers blocked it. :-/
Well, having Suggests/Recommends in RPM only does buy you anything as 
RPM will just ignore them. Yum (or any other depsolver) has the job of 
selecting the right set of packages.
 I have to defend Seth here ... in the last flamewar on this theme he
 admitted that introducing Suggests/Recommends would be question of half
 an hour (maybe he didn't mean it literally) and he would be willing to
 do it in the moment FESCO (or Board, or whoever is appropriate to make
 the decision) would tell him so
I think if anybody can come up with a exact description how they should 
look like and how they should work and can create some evidence that 
this is want we need and want implementing them is not the problem[*]. 
Until now no one has come up with a proposal and enough confidence.

As soon as one looks at the details it becomes less obvious what we 
really want. Even whether the Suggests/Recommends should live in the 
packages or in comps or else where or both or both or in all three is 
still under debate. Do we need reverse relations? Do we really want to 
have exactly two levels of strength? Do we need conditionals (install 
an package only if two or more other packages are installed) as we had 
(have) in comps? Or should be trash the whole concept of comps and comps 
groups and start all over? When and how should they be evaluated? Do we 
need to save the users decision not to want the suggested package? What 
happens if the Suggests changes during an update?

If there really is some interest in getting any kind of weak 
requirements into yum and rpm answering the questions above is a first 
step (The list is not complete.) But from my perspective (as an RPM 
developer) Fedora has shown little interest in developing an own 
opinion about how the future of packaging and package handling should 
look like. So I am not too optimistic that we'll have Suggests or 
Recommends any time soon.

Florian

[*] Depending on the exact features implementing still can be tricky and 
require a lot of work. I doubt that it will be even remotely close to 
half an hour but nothing that cannot be handled.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel