@ffesti Thank you for sharing a different analysis and point of view. I’ll
correct some things here (I don’t fundamentally disagree with what you wrote,
but you made some shortcuts that would block a real-world design)
> The current font and go macros are a pain to implement but - obviously -
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1223___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
> @ffesti Thank you for sharing a different analysis and point of view. I’ll
> correct some things here (I don’t fundamentally disagree with what you wrote,
> but you made some shortcuts that would block a real-world design)
>
> > The current font and go macros are a pain to implement but -
To give automatic sub packages more leeway to deal with files there needs to be
a way to "steal" files from other packages, so files can end up in different
packages depending on which sub package actually get created.
For those cases it is not desired to have the files in more than one package.
Right now there is no way to acess previously declared packages and their
attributes from within the spec file. Automatic package generation may need to
know what packages are there already to take them into account.
Note: This does not (yet) include a way to actually alter those packages.
--
File attributes are a powerful way of dealing with files. Unfortunately the
file classification is not available in %files. As they emerged from the
dependency generator code they are only executed after the %file lists are
turned into real files.
While dependency generator probably need to
@dmnks pushed 1 commit.
7ba7f3a0d2a9a2edfb03dda2e045e8f570487514 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 1 commit.
a1c384cd841bc6da2f2805fb4000b3a2e24254d8 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 2 commits.
1cd747fa9599424fcb0151518f4ff50e116c993e Exit
7b2074b61be01dba7568e4a8bafb8956693aa49f Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 2 commits.
7730c3f31e73e2ae290f8aab2caee33fca905361 Rename
b98ad2d140a924f6794dbff2eb3c842cd79f200e Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 1 commit.
5f583ba5136d94f5189fe2d044c0c215c9a69f7e Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 2 commits.
b9b42ef226facad6a632404aa385dffb30c28794 Exit
ad7d340e08d1e43a692805fc3077c33cad12e6f9 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 1 commit.
f343661ecb7eedf95c2206de57ad83ec71a0af3c Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 1 commit.
787f80c2340544fd55c0a1eb7dcdb6adcbe199e1 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 2 commits.
3173e9a82f1a7a66264d0e092c1a338be3a1456a Rename
1a1bf9a336294539befd81c6a4519bda2e45f843 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
But the same issue is with a single remove step. Try:
dnf install acpi -y
dnf remove acpi # wait till rpm -e acpi is performed in another terminal, then
approve it.
At the time of creation of remove operation for rpm
('dnf/db/group.py:_populate_rpm_ts()') the package i already gone, but rpm do
That's not the same issue at all, even if it appears similar from you point of
view.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I don't understand how the discussion come from something reasonably nice and
expressive which is within current RPM functionality such as `%if %{vercmp
%{python3_version} >= 3.9}` to proposing something weird such as `@1.2@ < @1.0@`
--
You are receiving this because you are subscribed to this
@dmnks pushed 1 commit.
a1a343679f089380af6192f6fa07f73b1e7310e8 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
This adds a (beginnings of) a version parsing and comparison API to librpmio.
Details in the commit messages, but the (obvious) motivation is to finally have
a meaningful API for handling rpm versions in and out of rpm. For maximum
coverage, this needs to be in librpmio which allows usage from
In Ruby, there is quite commonly used something like `%q{foo}`, `%r{foo}` to
denote quoted string and regexp respectively. Therefore my suggestion would be
to use `%v{1.2.3}` if we really need some special syntax.
But also `%{version:1.2.3}` wold be good enough. And maybe much better.
--
You
`%{version:1.2.3}` would be my choice as well, if only it would not be
confusing with `%{version}`. That' why I proposed `%{ver:5.6}`
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Folks, please keep the discussion in the ticket, this is just a PoC not
intended for merging and will go away soonish.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
(hmm, maybe we need a separate PoC label, or maybe we should just rename RFC to
PoC...)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Looking at this there are a couple of separate issues. I wonder if the reason
this has not been getting anywhere has been that we try to solve all these
different things at once. May be we should split this into separate features
and just start with one - solving only a few - but at least a few
It's not just a matter of what's nice, it's to a large degree also a question
of what's technically possible and available.
The quest at hand is to find the most reasonable syntax to identify strings as
versions at the most fundamental level of the "rpm language" which is the
expression
> I guess the easiest way to provide this is a spec file section that is not
> evaluated at parse time but is parsed after the build. We might want to
> disallow some things there but it will basically allow declaring sub
> packages. These could also be created by macros or by scripts
Intended to rebase this on top of #1221 to be able to use full version
comparison and use v".." syntax, but seems I emptied my bucket for to day. If
somebody's bored and wants to have a go, feel free. If not, I'll get back into
it next week.
--
You are receiving this because you are
To further elaborate on that, if deemed necessary/useful, a macro primitive
such as %{V:...} could be added for *converting to* the expression syntax. Eg
assuming the proposed pythonisque syntax, %{V:1.2} would simply expand to
v"1.2" which the expression parser would then understand as a
29 matches
Mail list logo
