1:26 a.m.
It's that time of year again... as our RPM change proposals passed with
flying colors in yesterdays meeting, I'll hope to land RPM 4.16 alpha in
rawhide later today or tomorrow by latest.
There aren't any big incompatibility bumps here, but to pave way for the
fancy new expression stuff, some dusty corners needed, well, dusting.
One of the discoveries was that rpm has accidentally long allowed
unquoted text to be used as a string in expressions. That is no longer
supported, you need to quote any strings in expressions.
Based on rpm-specs-latest.tar.xz from this morning, there are thirtysome
packages relying on this behavior, which will need fixing to be
buildable with 4.16. You'll get an error message pointing to the right
direction, eg:
error: bare words are no longer supported, please use "...": python3 ==
python3
error: ^
error: airnef.spec:83: bad %if condition: python3 == python3
This is caused by the following line in that spec:
%if %python == python3
Just add double quotes to both sides and it'll work. This is backwards
compatible so you're not breaking anything by doing so, like mentioned
above this only ever worked by accident to begin with.
Other than that, there are a couple of things that might be of
particular interest to Fedora packagers: new expression features [1] (in
spec %if and macros) including but not limited to ternary operator (eg
%[1==0?"yes":"no"]) and parametric macro generators [2] for lightning
fast dependency generation. Oh, and dependency generators can now
optionally use MIME type instead of "file" magic string for file
classification.
Last but certainly not least, please do test the database stuff! We will
not be changing the default until several weeks from now (for
stabilization and coordination with infrastructure/rel-eng efforts), but
you can and should test locally:
# echo '%_db_backend sqlite' > /etc/rpm/macros.db
# rpmdb --rebuilddb
After that you'll be using sqlite rpmdb, and you shouldn't really notice
anything at all. Except that it's typically a little faster, and should
survive abuse in ways that BDB never did.
And as usual, please report anything odd.
[1] https://rpm.org/wiki/Releases/4.16.0 has some examples, more to follow
[2]
https://rpm.org/user_doc/dependency_generators#parametric-macro-generator...
- Panu -
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)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-announce@lists.fedora...
1:42 a.m.
New subject: Fwd: Heads-up: RPM 4.16 alpha coming to rawhide
Forwarding to devel@ while the message is sitting in devel-announce@
moderation queue - the idea of the heads-up is to make people aware
before, not after the fact afterall...
- Panu -
-------- Forwarded Message --------
Subject: Heads-up: RPM 4.16 alpha coming to rawhide
Date: Tue, 31 Mar 2020 09:26:36 +0300
From: Panu Matilainen <pmatilai(a)redhat.com>
To: devel-announce(a)lists.fedoraproject.org
It's that time of year again... as our RPM change proposals passed with
flying colors in yesterdays meeting, I'll hope to land RPM 4.16 alpha in
rawhide later today or tomorrow by latest.
There aren't any big incompatibility bumps here, but to pave way for the
fancy new expression stuff, some dusty corners needed, well, dusting.
One of the discoveries was that rpm has accidentally long allowed
unquoted text to be used as a string in expressions. That is no longer
supported, you need to quote any strings in expressions.
Based on rpm-specs-latest.tar.xz from this morning, there are thirtysome
packages relying on this behavior, which will need fixing to be
buildable with 4.16. You'll get an error message pointing to the right
direction, eg:
error: bare words are no longer supported, please use "...": python3 ==
python3
error: ^
error: airnef.spec:83: bad %if condition: python3 == python3
This is caused by the following line in that spec:
%if %python == python3
Just add double quotes to both sides and it'll work. This is backwards
compatible so you're not breaking anything by doing so, like mentioned
above this only ever worked by accident to begin with.
Other than that, there are a couple of things that might be of
particular interest to Fedora packagers: new expression features [1] (in
spec %if and macros) including but not limited to ternary operator (eg
%[1==0?"yes":"no"]) and parametric macro generators [2] for lightning
fast dependency generation. Oh, and dependency generators can now
optionally use MIME type instead of "file" magic string for file
classification.
Last but certainly not least, please do test the database stuff! We will
not be changing the default until several weeks from now (for
stabilization and coordination with infrastructure/rel-eng efforts), but
you can and should test locally:
# echo '%_db_backend sqlite' > /etc/rpm/macros.db
# rpmdb --rebuilddb
After that you'll be using sqlite rpmdb, and you shouldn't really notice
anything at all. Except that it's typically a little faster, and should
survive abuse in ways that BDB never did.
And as usual, please report anything odd.
[1] https://rpm.org/wiki/Releases/4.16.0 has some examples, more to follow
[2]
https://rpm.org/user_doc/dependency_generators#parametric-macro-generator...
- Panu -
12:24 p.m.
On Tue, Mar 31, 2020 at 6:43 AM Panu Matilainen <pmatilai(a)redhat.com> wrote:
Based on rpm-specs-latest.tar.xz from this morning, there are
thirtysome
packages relying on this behavior, which will need fixing to be
buildable with 4.16.
Is there a list of those thirty something packages
somewhere so that those particular packagers
can potentially get a heads up?
6:36 a.m.
On 3/31/20 8:24 PM, Gary Buhrmaster wrote:
On Tue, Mar 31, 2020 at 6:43 AM Panu Matilainen
<pmatilai(a)redhat.com> wrote:
> Based on rpm-specs-latest.tar.xz from this morning, there are thirtysome
> packages relying on this behavior, which will need fixing to be
> buildable with 4.16.
Is there a list of those thirty something packages
somewhere so that those particular packagers
can potentially get a heads up?
Here you go (was easier to extract from the output than I initially
thought):
airnef.spec:83: bad %if condition: python3 == python3
arbor.spec:34: bad %if condition: fb5d4ea736282dce14c3284bc5db748b082db957
cgit.spec:26: bad %if condition: 0 >= 7 && ! ( x86_64 == ppc64le ||
x86_64 == x86_64 )
copr-rpmbuild.spec:47: bad %if condition: python3 == "python2"
CQRlib.spec:33: bad %if condition: lib64 == lib64
CTL.spec:90: bad %if condition: lib64 == "lib64"
CVector.spec:39: bad %if condition: lib64 == lib64
dayplanner.spec:82: bad %if condition: include_holidayparser
desktop-backgrounds.spec:21: bad %if condition: png != png
doxygen.spec:53: bad %if condition: ON == "ON"
gdl.spec:193: bad %if condition: lib64 != "lib"
ghdl.spec:494: bad %if condition: lib64 != lib
git.spec:207: bad %if condition: 031 || 0 == 6 || ( 0 >= 7 && ( x86_64
== ppc64le || x86_64 == x86_64 ) )
gsignond.spec:115: bad %if condition: session != p2p
gwenview.spec:35: bad %if condition: !(0 == 8 && ( x86_64 == "aarch64"
|| x86_64 == "s390x" ))
hdf.spec:207: bad %if condition: lib64 == lib64
kdegraphics-thumbnailers.spec:4: bad %if condition: !(0 == 8 && (
x86_64 == "aarch64" || x86_64 == "s390x" ))
kf5-akonadi-contacts.spec:49: bad %if condition: !(0 == 8 && ( x86_64
== "aarch64" || x86_64 == "s390x" ))
lmdb.spec:83: bad %if condition: 0 == 6 && x86_64 == "ppc64"
magic.spec:81: bad %if condition: x64 == x64
mariadb.spec:42: bad %if condition: x86_64 == x86_64 && 031
MUSIC.spec:251: bad %if condition: lib64 == "lib64"
NetworkManager.spec:24: bad %if condition: "x" != x
newlisp.spec:38: bad %if condition: lib64 == lib64
nwchem.spec:409: bad %if condition: LINUX64 == LINUX
OpenEXR_Viewers.spec:82: bad %if condition: lib64 == lib64
python-pivy.spec:66: bad %if condition: lib64 == "lib64"
python-ryu.spec:98: bad %if condition: python3 == python3
qt3.spec:404: bad %if condition: lib64 == lib64
rubygem-scruffy.spec:7: bad %if condition: (prerelease)
sagator.spec:33: bad %if condition: redhat == "suse"
scribus.spec:111: bad %if condition: lib64 == lib64
SkyX.spec:67: bad %if condition: lib64 == "lib64"
zabbix.spec:61: bad %if condition: zabbix != zabbix
- Panu -
6:52 a.m.
Am Mittwoch, den 01.04.2020, 14:36 +0300 schrieb Panu Matilainen:
On 3/31/20 8:24 PM, Gary Buhrmaster wrote:
> On Tue, Mar 31, 2020 at 6:43 AM Panu Matilainen <pmatilai(a)redhat.com
> > wrote:
>
> > Based on rpm-specs-latest.tar.xz from this morning, there are
> > thirtysome
> > packages relying on this behavior, which will need fixing to be
> > buildable with 4.16.
>
> Is there a list of those thirty something packages
> somewhere so that those particular packagers
> can potentially get a heads up?
Here you go (was easier to extract from the output than I initially
thought):
airnef.spec:83: bad %if condition: python3 == python3
arbor.spec:34: bad %if
condition: fb5d4ea736282dce14c3284bc5db748b082db957
cgit.spec:26: bad %if condition: 0 >= 7 && ! ( x86_64 == ppc64le ||
x86_64 == x86_64 )
copr-rpmbuild.spec:47: bad %if condition: python3 == "python2"
CQRlib.spec:33: bad %if condition: lib64 == lib64
CTL.spec:90: bad %if condition: lib64 == "lib64"
CVector.spec:39: bad %if condition: lib64 == lib64
dayplanner.spec:82: bad %if condition: include_holidayparser
desktop-backgrounds.spec:21: bad %if condition: png != png
doxygen.spec:53: bad %if condition: ON == "ON"
gdl.spec:193: bad %if condition: lib64 != "lib"
ghdl.spec:494: bad %if condition: lib64 != lib
git.spec:207: bad %if condition: 031 || 0 == 6 || ( 0 >= 7 && (
x86_64
== ppc64le || x86_64 == x86_64 ) )
gsignond.spec:115: bad %if condition: session != p2p
gwenview.spec:35: bad %if condition: !(0 == 8 && ( x86_64 ==
"aarch64"
> > x86_64 == "s390x" ))
hdf.spec:207: bad %if condition: lib64 == lib64
kdegraphics-thumbnailers.spec:4: bad %if condition: !(0 == 8 && (
x86_64 == "aarch64" || x86_64 == "s390x" ))
kf5-akonadi-contacts.spec:49: bad %if condition: !(0 == 8 && (
x86_64
== "aarch64" || x86_64 == "s390x" ))
lmdb.spec:83: bad %if condition: 0 == 6 && x86_64 == "ppc64"
magic.spec:81: bad %if condition: x64 == x64
mariadb.spec:42: bad %if condition: x86_64 == x86_64 && 031
MUSIC.spec:251: bad %if condition: lib64 == "lib64"
NetworkManager.spec:24: bad %if condition: "x" != x
newlisp.spec:38: bad %if condition: lib64 == lib64
nwchem.spec:409: bad %if condition: LINUX64 == LINUX
OpenEXR_Viewers.spec:82: bad %if condition: lib64 == lib64
python-pivy.spec:66: bad %if condition: lib64 == "lib64"
python-ryu.spec:98: bad %if condition: python3 == python3
qt3.spec:404: bad %if condition: lib64 == lib64
rubygem-scruffy.spec:7: bad %if condition: (prerelease)
sagator.spec:33: bad %if condition: redhat == "suse"
scribus.spec:111: bad %if condition: lib64 == lib64
SkyX.spec:67: bad %if condition: lib64 == "lib64"
zabbix.spec:61: bad %if condition: zabbix != zabbix
I've fixed all the packages on the list.
Cheers
Björn
7:45 a.m.
Dne 02. 04. 20 v 13:52 Björn 'besser82' Esser napsal(a):
rubygem-scruffy.spec:7: bad %if condition: (prerelease)
Is this construct really forbidden?
https://src.fedoraproject.org/rpms/rubygem-scruffy/c/ecdb3b762fef08eae805...
Anyway, the whole conditional should have been dropped all together ....
Vít
8:43 a.m.
On 4/2/20 3:45 PM, Vít Ondruch wrote:
Dne 02. 04. 20 v 13:52 Björn 'besser82' Esser napsal(a):
> rubygem-scruffy.spec:7: bad %if condition: (prerelease)
Is this construct really forbidden?
https://src.fedoraproject.org/rpms/rubygem-scruffy/c/ecdb3b762fef08eae805...
It's not really a question whether its forbidden or not, its simply
broken and will have never done what it was intended to do. The syntax
for that has always been:
%if %{defined foo}
...
%endif
- Panu -
11:45 a.m.
New subject: Fwd: Heads-up: RPM 4.16 alpha coming to rawhide
On Tuesday, March 31, 2020 8:42:37 AM CEST Panu Matilainen wrote:
Last but certainly not least, please do test the database stuff! We
will
not be changing the default until several weeks from now (for
stabilization and coordination with infrastructure/rel-eng efforts), but
you can and should test locally:
# echo '%_db_backend sqlite' > /etc/rpm/macros.db
# rpmdb --rebuilddb
I'm trying to test this with mock (2.2 from updates-testing). Note that
mock puts macros below $HOME/.rpmmacros (if that matters):
$ cat test.cfg
include('fedora-rawhide-x86_64.cfg')
config_opts['root'] = 'fedora-SQLiteRawhide-x86_64'
config_opts['macros']['%_db_backend'] = 'sqlite'
$ mock -r ./test.cfg --rebuild
~/rh/packages/postgresql/fedora/postgresql-12.2-2.fc33.src.rpm
...
And it seems to work, as I see files like:
$ ls -1 /var/lib/mock/fedora-SQLiteRawhide-x86_64*/root/var/lib/rpm/*sqlite*
/var/lib/mock/fedora-SQLiteRawhide-x86_64/root/var/lib/rpm/rpmdb.sqlite
/var/lib/mock/fedora-SQLiteRawhide-x86_64/root/var/lib/rpm/rpmdb.sqlite-shm
/var/lib/mock/fedora-SQLiteRawhide-x86_64/root/var/lib/rpm/rpmdb.sqlite-wal
Can we consider this to be working (from mock POV)?
Don't you have the RPM package built somewhere that has the SQLite DB
backend enabled by default so I could test?
Pavel
8:24 a.m.
New subject: Fwd: Heads-up: RPM 4.16 alpha coming to rawhide
On 4/2/20 7:45 PM, Pavel Raiskup wrote:
On Tuesday, March 31, 2020 8:42:37 AM CEST Panu Matilainen wrote:
> Last but certainly not least, please do test the database stuff! We will
> not be changing the default until several weeks from now (for
> stabilization and coordination with infrastructure/rel-eng efforts), but
> you can and should test locally:
>
> # echo '%_db_backend sqlite' > /etc/rpm/macros.db
> # rpmdb --rebuilddb
I'm trying to test this with mock (2.2 from updates-testing). Note that
mock puts macros below $HOME/.rpmmacros (if that matters):
$ cat test.cfg
include('fedora-rawhide-x86_64.cfg')
config_opts['root'] = 'fedora-SQLiteRawhide-x86_64'
config_opts['macros']['%_db_backend'] = 'sqlite'
$ mock -r ./test.cfg --rebuild
~/rh/packages/postgresql/fedora/postgresql-12.2-2.fc33.src.rpm
...
And it seems to work, as I see files like:
$ ls -1 /var/lib/mock/fedora-SQLiteRawhide-x86_64*/root/var/lib/rpm/*sqlite*
/var/lib/mock/fedora-SQLiteRawhide-x86_64/root/var/lib/rpm/rpmdb.sqlite
/var/lib/mock/fedora-SQLiteRawhide-x86_64/root/var/lib/rpm/rpmdb.sqlite-shm
/var/lib/mock/fedora-SQLiteRawhide-x86_64/root/var/lib/rpm/rpmdb.sqlite-wal
Can we consider this to be working (from mock POV)?
I suppose so. What host are you running from?
Don't you have the RPM package built somewhere that has the SQLite DB
backend enabled by default so I could test?
Not at the moment, not sure where to place such a thing. A copr maybe if
there's interest...
- Panu -
Pavel
7:34 a.m.
On Tue, Mar 31, 2020 at 8:10 AM Panu Matilainen <pmatilai(a)redhat.com> wrote:
It's that time of year again... as our RPM change proposals passed with
flying colors in yesterdays meeting, I'll hope to land RPM 4.16 alpha in
rawhide later today or tomorrow by latest.
Since Panu left it out of his announcement, I'd also like to mention
that RPM 4.16 adds the following new feature:
"Add support for meta dependencies (eg Requires(meta): somepkg) that
do not affect install/erase ordering (RhBug:1648721)"
These dependencies are intended for use with metapackages and help
with avoiding dependency loops. Essentially, a `Requires(meta):`
dependency is telling RPM: at the end of any transaction where this
package is installed, this dependency must also be installed, but I
don't need the dependency ordered earlier.
This is going to come in handy for the Fedora Release packages (like
fedora-release-server) which will be able to define a minimal "API" to
be recognized as that Edition (or Spin). This didn't work before this
feature was added, because fedora-release must be ordered early in the
transaction to set up things like /etc/os-release, so we couldn't set
dependencies.
2:11 a.m.
On 3/31/20 3:34 PM, Stephen Gallagher wrote:
On Tue, Mar 31, 2020 at 8:10 AM Panu Matilainen
<pmatilai(a)redhat.com> wrote:
>
> It's that time of year again... as our RPM change proposals passed with
> flying colors in yesterdays meeting, I'll hope to land RPM 4.16 alpha in
> rawhide later today or tomorrow by latest.
>
Since Panu left it out of his announcement, I'd also like to mention
that RPM 4.16 adds the following new feature:
"Add support for meta dependencies (eg Requires(meta): somepkg) that
do not affect install/erase ordering (RhBug:1648721)"
These dependencies are intended for use with metapackages and help
with avoiding dependency loops. Essentially, a `Requires(meta):`
dependency is telling RPM: at the end of any transaction where this
package is installed, this dependency must also be installed, but I
don't need the dependency ordered earlier.
This is going to come in handy for the Fedora Release packages (like
fedora-release-server) which will be able to define a minimal "API" to
be recognized as that Edition (or Spin). This didn't work before this
feature was added, because fedora-release must be ordered early in the
transaction to set up things like /etc/os-release, so we couldn't set
dependencies.
Oh, thanks for the reminder about this Stephen.
Besides meta-packages, another potential use-case for meta (whether
Requires or weak dependencies) is those just-in-case dependencies across
sub-packages to ensure nobody runs weird combinations even though
sonames might permit it. Often they are in the same direction as the
soname dependency so it doesn't create any additional ordering issues
but sometimes they're in the opposite direction, creating a wholly
unnecessary dependency loop. Rpm itself is an example of this (but we
can't really use "meta" anytime soon as rpm needs to be bootstrappable
from older versions)
- Panu -
8:24 a.m.
On Wed, Apr 1, 2020 at 3:11 AM Panu Matilainen <pmatilai(a)redhat.com> wrote:
On 3/31/20 3:34 PM, Stephen Gallagher wrote:
> On Tue, Mar 31, 2020 at 8:10 AM Panu Matilainen <pmatilai(a)redhat.com> wrote:
>>
>> It's that time of year again... as our RPM change proposals passed with
>> flying colors in yesterdays meeting, I'll hope to land RPM 4.16 alpha in
>> rawhide later today or tomorrow by latest.
>>
>
> Since Panu left it out of his announcement, I'd also like to mention
> that RPM 4.16 adds the following new feature:
>
> "Add support for meta dependencies (eg Requires(meta): somepkg) that
> do not affect install/erase ordering (RhBug:1648721)"
>
> These dependencies are intended for use with metapackages and help
> with avoiding dependency loops. Essentially, a `Requires(meta):`
> dependency is telling RPM: at the end of any transaction where this
> package is installed, this dependency must also be installed, but I
> don't need the dependency ordered earlier.
>
> This is going to come in handy for the Fedora Release packages (like
> fedora-release-server) which will be able to define a minimal "API" to
> be recognized as that Edition (or Spin). This didn't work before this
> feature was added, because fedora-release must be ordered early in the
> transaction to set up things like /etc/os-release, so we couldn't set
> dependencies.
Oh, thanks for the reminder about this Stephen.
Besides meta-packages, another potential use-case for meta (whether
Requires or weak dependencies) is those just-in-case dependencies across
sub-packages to ensure nobody runs weird combinations even though
sonames might permit it. Often they are in the same direction as the
soname dependency so it doesn't create any additional ordering issues
but sometimes they're in the opposite direction, creating a wholly
unnecessary dependency loop. Rpm itself is an example of this (but we
can't really use "meta" anytime soon as rpm needs to be bootstrappable
from older versions)
Do you mean things like:
Requires: libfoo >= 3.4.2-3
could become
Requires(meta): libfoo >= 3.4.2-3
What about things like ensuring that subpackages are running the same
version as the main package so they get updated together?
8:33 a.m.
On 4/1/20 4:24 PM, Stephen Gallagher wrote:
On Wed, Apr 1, 2020 at 3:11 AM Panu Matilainen
<pmatilai(a)redhat.com> wrote:
>
> On 3/31/20 3:34 PM, Stephen Gallagher wrote:
>> On Tue, Mar 31, 2020 at 8:10 AM Panu Matilainen <pmatilai(a)redhat.com>
wrote:
>>>
>>> It's that time of year again... as our RPM change proposals passed with
>>> flying colors in yesterdays meeting, I'll hope to land RPM 4.16 alpha in
>>> rawhide later today or tomorrow by latest.
>>>
>>
>> Since Panu left it out of his announcement, I'd also like to mention
>> that RPM 4.16 adds the following new feature:
>>
>> "Add support for meta dependencies (eg Requires(meta): somepkg) that
>> do not affect install/erase ordering (RhBug:1648721)"
>>
>> These dependencies are intended for use with metapackages and help
>> with avoiding dependency loops. Essentially, a `Requires(meta):`
>> dependency is telling RPM: at the end of any transaction where this
>> package is installed, this dependency must also be installed, but I
>> don't need the dependency ordered earlier.
>>
>> This is going to come in handy for the Fedora Release packages (like
>> fedora-release-server) which will be able to define a minimal "API" to
>> be recognized as that Edition (or Spin). This didn't work before this
>> feature was added, because fedora-release must be ordered early in the
>> transaction to set up things like /etc/os-release, so we couldn't set
>> dependencies.
>
> Oh, thanks for the reminder about this Stephen.
>
> Besides meta-packages, another potential use-case for meta (whether
> Requires or weak dependencies) is those just-in-case dependencies across
> sub-packages to ensure nobody runs weird combinations even though
> sonames might permit it. Often they are in the same direction as the
> soname dependency so it doesn't create any additional ordering issues
> but sometimes they're in the opposite direction, creating a wholly
> unnecessary dependency loop. Rpm itself is an example of this (but we
> can't really use "meta" anytime soon as rpm needs to be bootstrappable
> from older versions)
Do you mean things like:
Requires: libfoo >= 3.4.2-3
could become
Requires(meta): libfoo >= 3.4.2-3
What about things like ensuring that subpackages are running the same
version as the main package so they get updated together?
This latter case is what I meant by the above, apparently not very
clearly :)
Care needs to be taken though when adding "meta" to things like this as
in many cases the order *does* matter.
- Panu -
9:08 a.m.
On 01. 04. 20 9:11, Panu Matilainen wrote:
Besides meta-packages, another potential use-case for meta (whether
Requires or
weak dependencies) is those just-in-case dependencies across sub-packages to
ensure nobody runs weird combinations even though sonames might permit it. Often
they are in the same direction as the soname dependency so it doesn't create any
additional ordering issues but sometimes they're in the opposite direction,
creating a wholly unnecessary dependency loop. Rpm itself is an example of this
(but we can't really use "meta" anytime soon as rpm needs to be
bootstrappable
from older versions)
Something like this?
https://fedoraproject.org/wiki/Changes/Automatic_strict_inter-package_dep...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2:45 a.m.
On 4/1/20 5:08 PM, Miro Hrončok wrote:
On 01. 04. 20 9:11, Panu Matilainen wrote:
> Besides meta-packages, another potential use-case for meta (whether
> Requires or weak dependencies) is those just-in-case dependencies
> across sub-packages to ensure nobody runs weird combinations even
> though sonames might permit it. Often they are in the same direction
> as the soname dependency so it doesn't create any additional ordering
> issues but sometimes they're in the opposite direction, creating a
> wholly unnecessary dependency loop. Rpm itself is an example of this
> (but we can't really use "meta" anytime soon as rpm needs to be
> bootstrappable from older versions)
Something like this?
https://fedoraproject.org/wiki/Changes/Automatic_strict_inter-package_dep...
Those kind of dependencies, yes.
https://github.com/rpm-software-management/rpm/issues/1105 is the
upstream ticket, but note the loose definition there: I'd rather find a
more elegant solution to than piling on more Requires everywhere.
- Panu -
11:45 a.m.
Panu Matilainen wrote:
new expression features (in
spec %if and macros) including but not limited to ternary operator (eg
%[1==0?"yes":"no"])
For dependencies I'm told that the syntax is
<expression> if <condition> else <expression>. So the syntax for
conditional expressions is different in different contexts within the
RPM spec language?
Björn Persson
2:01 a.m.
On 3/31/20 7:45 PM, Björn Persson wrote:
Panu Matilainen wrote:
> new expression features (in
> spec %if and macros) including but not limited to ternary operator (eg
> %[1==0?"yes":"no"])
For dependencies I'm told that the syntax is
<expression> if <condition> else <expression>. So the syntax for
conditional expressions is different in different contexts within the
RPM spec language?
Rich dependencies are an entirely different ballgame with a syntax of
their own, this has nothing to do with them.
- Panu -
2:32 a.m.
Dne 31. 03. 20 v 8:26 Panu Matilainen napsal(a):
# rpmdb --rebuilddb
I always wanted to ask: how the rebuilddb works? The man page states that rpmdb rebuilds
db from package headers. Where
are those headers stored?
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
3:10 a.m.
On 4/1/20 10:32 AM, Miroslav Suchý wrote:
Dne 31. 03. 20 v 8:26 Panu Matilainen napsal(a):
> # rpmdb --rebuilddb
I always wanted to ask: how the rebuilddb works? The man page states that rpmdb rebuilds
db from package headers. Where
are those headers stored?
The database rebuild indeed just reads the headers off the old database,
ignoring everything else in there, and builds a new one from scratch.
The headers are in the "main database" (RPMDBI_PACKAGES in the API),
physical storage differs across the database backends but in the BDB
backend people are most familiar with, its the Packages file (in sqlite,
its the Packages table instead)
Technically it doesn't matter where the headers come from, they could
just as well come from on-disk blobs or a catenated list of headers
(which is what rpmdb --exportdb/--importdb does)
- Panu -
12:40 p.m.
This is _only_ going into Rawhide / F33? It looks like the change to
the new OCaml dependency generator will require a complete rebuild of
all OCaml packages.
https://github.com/rpm-software-management/rpm/commit/a6fe37c39b39acbcbd0...
https://github.com/rpm-software-management/rpm/issues/913
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
2:36 a.m.
On 4/1/20 8:40 PM, Richard W.M. Jones wrote:
This is _only_ going into Rawhide / F33? It looks like the change to
the new OCaml dependency generator will require a complete rebuild of
all OCaml packages.
https://github.com/rpm-software-management/rpm/commit/a6fe37c39b39acbcbd0...
https://github.com/rpm-software-management/rpm/issues/913
Oh, bollocks. I totally forgot, and failed to realize the impact of
that. Sorry! Should I revert that in rawhiede, until an explicit "go"
signal from you? That's perfectly fine by me.
And yes this is only going to rawhide/f33, only micro version updates
are pushed to stable releases.
This is also just further proof that these things need to be in hands of
language SIGs, not rpm upstream. Perl and Python dependency generation
was already "outsourced" to respective lang-macros/generators packages,
I'd recommend doing the same with OCaml to put the right people in
control of things like this.
- Panu -
3:43 a.m.
On Thu, Apr 02, 2020 at 10:36:58AM +0300, Panu Matilainen wrote:
On 4/1/20 8:40 PM, Richard W.M. Jones wrote:
>
>This is _only_ going into Rawhide / F33? It looks like the change to
>the new OCaml dependency generator will require a complete rebuild of
>all OCaml packages.
>
>https://github.com/rpm-software-management/rpm/commit/a6fe37c39b39acbcbd014dd1e6d5653ff84254a1
>https://github.com/rpm-software-management/rpm/issues/913
>
Oh, bollocks. I totally forgot, and failed to realize the impact of
that. Sorry! Should I revert that in rawhiede, until an explicit
"go" signal from you? That's perfectly fine by me.
And yes this is only going to rawhide/f33, only micro version
updates are pushed to stable releases.
No, don't do anything now. I'm doing an OCaml rebuild of all OCaml
rawhide packages into a side tag. If that works then we can just fold
that side tag into Rawhide and it's all good.
This is also just further proof that these things need to be in
hands of language SIGs, not rpm upstream. Perl and Python dependency
generation was already "outsourced" to respective
lang-macros/generators packages, I'd recommend doing the same with
OCaml to put the right people in control of things like this.
I can't remember but isn't that how it originally worked for OCaml
and then it was added to RPM? In any case there's probably some value
in sharing this code across RPM-based distributions. (Note this code
came directly from SUSE, derived from work I originally did for Fedora).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
3:52 a.m.
On 4/2/20 11:43 AM, Richard W.M. Jones wrote:
On Thu, Apr 02, 2020 at 10:36:58AM +0300, Panu Matilainen wrote:
> On 4/1/20 8:40 PM, Richard W.M. Jones wrote:
>>
>> This is _only_ going into Rawhide / F33? It looks like the change to
>> the new OCaml dependency generator will require a complete rebuild of
>> all OCaml packages.
>>
>>
https://github.com/rpm-software-management/rpm/commit/a6fe37c39b39acbcbd0...
>> https://github.com/rpm-software-management/rpm/issues/913
>>
>
> Oh, bollocks. I totally forgot, and failed to realize the impact of
> that. Sorry! Should I revert that in rawhiede, until an explicit
> "go" signal from you? That's perfectly fine by me.
>
> And yes this is only going to rawhide/f33, only micro version
> updates are pushed to stable releases.
No, don't do anything now. I'm doing an OCaml rebuild of all OCaml
rawhide packages into a side tag. If that works then we can just fold
that side tag into Rawhide and it's all good.
Ok.
> This is also just further proof that these things need to be in
> hands of language SIGs, not rpm upstream. Perl and Python dependency
> generation was already "outsourced" to respective
> lang-macros/generators packages, I'd recommend doing the same with
> OCaml to put the right people in control of things like this.
I can't remember but isn't that how it originally worked for OCaml
and then it was added to RPM?
Back then rpm didn't support dependency drop-in dependency generators,
so IIRC OCaml dependencies were being created by manually overriding
%__find_requires and %__find_provides to the OCaml-specific scripts.
Moving it to rpm made sense when there was no other alternative, but
since rpm 4.9 with the new dependency generator, the push has been in
the other direction. Not entirely unlike a tide, yeah :)
In any case there's probably some value
in sharing this code across RPM-based distributions. (Note this code
came directly from SUSE, derived from work I originally did for Fedora).
Absolutely. We still haven't figured out a development model that
accomplishes this while still giving the control to the language SIGs
where it belongs to. rpm-extras is supposed to serve such a role, but
miserably failing so far.
- Panu -
5:06 a.m.
On Thu, Apr 02, 2020 at 09:43:35AM +0100, Richard W.M. Jones wrote:
On Thu, Apr 02, 2020 at 10:36:58AM +0300, Panu Matilainen wrote:
> On 4/1/20 8:40 PM, Richard W.M. Jones wrote:
> >
> >This is _only_ going into Rawhide / F33? It looks like the change to
> >the new OCaml dependency generator will require a complete rebuild of
> >all OCaml packages.
> >
>
>https://github.com/rpm-software-management/rpm/commit/a6fe37c39b39acbcbd014dd1e6d5653ff84254a1
> >https://github.com/rpm-software-management/rpm/issues/913
> >
>
> Oh, bollocks. I totally forgot, and failed to realize the impact of
> that. Sorry! Should I revert that in rawhiede, until an explicit
> "go" signal from you? That's perfectly fine by me.
>
> And yes this is only going to rawhide/f33, only micro version
> updates are pushed to stable releases.
No, don't do anything now. I'm doing an OCaml rebuild of all OCaml
rawhide packages into a side tag. If that works then we can just fold
that side tag into Rawhide and it's all good.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5
Only one package failed to build (out of 130) which is pretty good.
The dependencies seem OK, as in, packages were able to be installed
when rebuilding the later packages, and the expected ocaml(...) and
ocamlx(...) deps seem to be present, at least for a small handful of
packages that I looked at.
Rich.
> This is also just further proof that these things need to be in
> hands of language SIGs, not rpm upstream. Perl and Python dependency
> generation was already "outsourced" to respective
> lang-macros/generators packages, I'd recommend doing the same with
> OCaml to put the right people in control of things like this.
I can't remember but isn't that how it originally worked for OCaml
and then it was added to RPM? In any case there's probably some value
in sharing this code across RPM-based distributions. (Note this code
came directly from SUSE, derived from work I originally did for Fedora).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
1479
days inactive
1484
days old
23 comments
10 participants
participants (10)
-
Björn 'besser82' Esser -
Björn Persson -
Gary Buhrmaster -
Miro Hrončok -
Miroslav Suchý -
Panu Matilainen -
Pavel Raiskup -
Richard W.M. Jones -
Stephen Gallagher -
Vít Ondruch