@keszybz commented on this pull request.
> @@ -245,6 +245,10 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%clamp_mtime_to_source_date_epoch 0
+# If true, make sure that timestamps in built rpms
+#
Sorry but no, as we've already said several times in several places. Not for
this reason anyhow.
We want to be able to rely on this tag being there in packages built with a
modern rpm. And that is what the suggested change breaks. When you build it in
a container of the "target era", it's
%{zzz foo} handled now, totally forgot that one...
I do think it should be an error just like it is on builtins, but noticed that
in the ticket this is something you stumbled on in the wild, so we can make it
a warning for a while and later turn it into an error. So, warning it is for
now.
--
Yeah this is something for the depsolve layer, rpm has no concept of repos and
cannot know what packages are available.
On the depsolve layer this becomes a somewhat different problem: is the package
really gone, or is it just temporarily unavailable due to out of sync mirrors
or another repo
@pmatilai commented on this pull request.
> @@ -303,6 +300,24 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
return rc;
}
+static rpmRC doBuildDir(rpmSpec spec, int test, StringBuf *sbp)
+{
+char *doDir = rstrscat(NULL,
+ "rm -rf
@pmatilai commented on this pull request.
> @@ -303,6 +300,24 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
return rc;
}
+static rpmRC doBuildDir(rpmSpec spec, int test, StringBuf *sbp)
+{
+char *doDir = rstrscat(NULL,
+ "rm -rf
What if a current RPM version complained about a package created w/o the tags?
It's already possible to generate them by simply using an older RPM version, so
I don't really see how "latest RPM always creates them" guarantees this feature
any more than latest RPM if patched to allow creation of
@dmnks commented on this pull request.
> @@ -303,6 +300,24 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
return rc;
}
+static rpmRC doBuildDir(rpmSpec spec, int test, StringBuf *sbp)
+{
+char *doDir = rstrscat(NULL,
+ "rm -rf ",
Argh, I've got a little tangled up here. What was discussed here was *another*
(currently non-existing) option similar to `--allowerasing` but for packages
that have *no* obsoleting package in the repos... Nevermind my last comment
then.
--
Reply to this email directly or view it on GitHub:
Looking at Fedora's system upgrade guide, there's this:
> If some of your packages have unsatisfied dependencies, the upgrade will
> refuse to continue until you run it again with an extra --allowerasing option.
That's basically what we've discussed so far, it's just not the default.
Letting
@JanZerebecki commented on this pull request.
> @@ -245,6 +245,10 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%clamp_mtime_to_source_date_epoch 0
+# If true, make sure that timestamps in built rpms
+#
Whether there's a reasonable replacement for the removed packages is another
thing, a "social" one I suppose. That is, ideally there always are such
replacements (Obsolete-ing the removed package) and if there aren't, that
should somehow perhaps be communicated in the Release notes or similar.
Yeah, I'd think that by performing a system upgrade the user explicitly grants
the permission to the package manager (DNF) to remove any unsupported packages
that prevent a complete system upgrade.
--
Reply to this email directly or view it on GitHub:
It's not possible to keep them anyway. That's the problem.we want to solve:
remove them when it's no longer possible to keep them.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8682257
You are receiving
Well, maybe. But that would be certainly task for DNF.
Although I still believe that some people prefer to keep the removed packages
around as long as possible. Maybe even longer, but then they could possible
exclude those from transaction.
--
Reply to this email directly or view it on
I've said it before and I will repeated it here. Dnf should gain an option to
allow erasing packages iff they are no longer available in the repos. Dnf
system upgarde should default to this option (at least for Fedora-provided
repos).
That way, we can stop manually tracking each retired
What the fedora-obsolete-packages can do is to remove such package immediately.
But that is not strictly needed. It is needed only when the ABI is broken.
I would like to have something like:
`Obsoletes: rubygem-byebug unless libruby.so.3.2()(64bit)`
or:
`Obsoletes: rubygem-byebug if
This would probably also clash with DNF's own depsolving logic (libsolv).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8681813
You are receiving this because you are subscribed to this thread.
Message ID:
What rpm *could* help with is to e.g. optionally remove a package whose
dependencies can't be satisfied in a given transaction. Basically, an analogy
to `--allowerasing` in DNF. However, I'm not sure if that's really what rpm
wants to support...
--
Reply to this email directly or view it on
I think your question therefore belongs to the DNF layer. In fact,
`--allowerasing` might just be what you're after.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8681697
You are receiving this because you
> Lets have some package installed on a system, which is already removed from
> the repository. This package might work just fine as long as their
> dependencies are satisfied. But after the dependencies change, the package
> needs to be removed.
A package installed on the system has its
Oh, just noticed the linked ticket above is actually from the
fedora-obsolete-packages repo :facepalm:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8681230
You are receiving this because you are
Yes, the package is precondition. But the question is if the `Obsolete` can be
more nuanced.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8681216
You are receiving this because you are subscribed to this
One way, I think, is to introduce a special distro-wide obsoleter package.
Example from Fedora:
https://src.fedoraproject.org/rpms/fedora-obsolete-packages. This assumes that
the maintainers of the retired packages update the package manually, though.
--
Reply to this email directly or view
Maybe the basename() case should also have some more advanced tests than the
one that is there to match the added dirname cases, see @mlschroe's link. Other
than that, looks fine now.
--
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> @@ -1306,9 +1307,9 @@ static void doFoo(rpmMacroBuf mb, rpmMacroEntry me,
> ARGV_t argv, size_t *parsed)
b++;
} else if (rstreq("dirname", me->name)) {
buf = xstrdup(argv[1]);
- if ((b = strrchr(buf, '/')) != NULL)
-
> The problem with not installing items is that one can't be certain if they
> are indeed not installed. They can be pulled in indirectly through some other
> dependency, or appear later on after a system update. That happens quietly,
> and will change the way rpm builds. The cmake option on
> That said... This does make the cmake file a bit noisier. I wonder what the
> actual use cases are for disabling these (versus just not installing the
> given build dependency in the first place, assuming a clean build system or
> container is set up for the build).
The problem with not
Yeah, while the patch here just mirrors what we already do, it does feel a bit
draconian.
The autotools-era standard was to autodiscover unless overridden one way or the
other, when moving to cmake I just took the shortest shortcut I could find:
make most stuff mandatory, allow disabling.
OK, the above cmake feature seems to only work with `find_packages()`, not
`pkg_check_modules()`...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2914#issuecomment-1978815299
You are receiving this because you are subscribed to this
That said... This does make the cmake file a bit noisier. I wonder what the
actual use cases are for disabling these (versus just not installing the given
build dependency in the first place, assuming a clean build system or container
is set up for the build).
A quick googling also reveals:
@Conan-Kudo approved this pull request.
Sure, I suppose.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2914#pullrequestreview-1916977215
You are receiving this because you are subscribed to this thread.
Message ID:
Now with the cmake options in place, this looks fine to me.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2914#issuecomment-1978795518
You are receiving this because you are subscribed to this thread.
Message ID:
@ffesti commented on this pull request.
> @@ -1306,9 +1307,9 @@ static void doFoo(rpmMacroBuf mb, rpmMacroEntry me,
> ARGV_t argv, size_t *parsed)
b++;
} else if (rstreq("dirname", me->name)) {
buf = xstrdup(argv[1]);
- if ((b = strrchr(buf, '/')) != NULL)
-
@pmatilai commented on this pull request.
> + if (!strcmp(buf, "")) {
+ buf = rstrcat(, ".");
+ } else if (strcmp(buf, ".") && strcmp(buf, "..") && strcmp(buf, "/")) {
+ /* strip trailing / */
+ size_t l = strlen(buf);
+ if (buf[l-1] == '/')
+
@pmatilai commented on this pull request.
> @@ -1306,9 +1307,9 @@ static void doFoo(rpmMacroBuf mb, rpmMacroEntry me,
> ARGV_t argv, size_t *parsed)
b++;
} else if (rstreq("dirname", me->name)) {
buf = xstrdup(argv[1]);
- if ((b = strrchr(buf, '/')) != NULL)
-
See https://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
for testcases ;-)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2945#issuecomment-1978695068
You are receiving this because you are subscribed to this thread.
Right, I don't know why these aren't calling the respective stdlib functions to
begin with. It's not like it's expensive or anything.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2945#issuecomment-1978694251
You are receiving this
@ffesti commented on this pull request.
> + if (!strcmp(buf, "")) {
+ buf = rstrcat(, ".");
+ } else if (strcmp(buf, ".") && strcmp(buf, "..") && strcmp(buf, "/")) {
+ /* strip trailing / */
+ size_t l = strlen(buf);
+ if (buf[l-1] == '/')
+
@ffesti pushed 1 commit.
225f33d2c833a186ba46af75d9aed3e50ada1ec6 Use dirname (3) instead of our own
code
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2945/files/cbff9947298bc694be5b7b1b3a3745bff844ce03..225f33d2c833a186ba46af75d9aed3e50ada1ec6
You are receiving
If you strip trailing slashes you also have to do it for %basename
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2945#issuecomment-1978685964
You are receiving this because you are subscribed to this thread.
Message ID:
Indeed, there's no deeper meaning to the test, it's all about argument handling
and nothing to do with dirname itself (the context of
c5909bd8698e56ffa4d1bb380116d61d6b48b8dd makes it quite clear)
--
Reply to this email directly or view it on GitHub:
My suspicion is that %dirname was used there not to test for it returning the
filename unchanged but it was chosen as leaving the parameter unchanged made it
a good test case for undefined arguments.
--
Reply to this email directly or view it on GitHub:
Reopened #624.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/624#event-12012718668
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Reopening, this never actually worked or it has regressed:
> $ rpmbuild -bb simple.spec
error: line 8: Unknown tag: Recommends(meta): fu
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/624#issuecomment-1978585547
You are receiving
Yet another practical example from Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=2252661
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1346#issuecomment-1978531887
You are receiving this because you are subscribed to this
@pmatilai commented on this pull request.
> + if (!strcmp(buf, "")) {
+ buf = rstrcat(, ".");
+ } else if (strcmp(buf, ".") && strcmp(buf, "..") && strcmp(buf, "/")) {
+ /* strip trailing / */
+ size_t l = strlen(buf);
+ if (buf[l-1] == '/')
+
For example, `rpm -e --test --deploops fwupd fwupd-plugin-modem-manager
fwupd-plugin-uefi-capsule-data fwupd-plugin-flashrom` on Fedora 39 shows no
output despite there being a dependency loop that causes an incorrect erase
order.
On install it's visible:
> warning: 1 Strongly Connected
Strip trailing /
Keep . and .. untouched
Keep root dir for files in the root dir
Return . for files without directory and empty strings
See man 3 dirname
Resolves: 2928
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2945
--
@mlschroe commented on this pull request.
> @@ -245,6 +245,10 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%clamp_mtime_to_source_date_epoch 0
+# If true, make sure that timestamps in built rpms
+#
In case folks didn't notice the PR from @mlschroe :
https://github.com/rpm-software-management/rpm/pull/2944
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8676851
You are receiving this because you are
@pmatilai commented on this pull request.
> @@ -245,6 +245,10 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%clamp_mtime_to_source_date_epoch 0
+# If true, make sure that timestamps in built rpms
+#
52 matches
Mail list logo
