Yup, the soname abstraction and the libtool style major.minor.micro version in
the filename don't exactly meet in practise.
So reading through the comments more throroughly, turning the version *in the
filename* (or symlink) into a version as suggested by @keszybz. That'd be
enforcing the libto
Oh and BTW, even for a proof-of-concept, you really need to start with the
internal dependency generator. In the external one, the whole world-iview is
upside down, and starting there is likely to run into conceptual problems
elsewhere.
--
Reply to this email directly or view it on GitHub:
htt
@pmatilai requested changes on this pull request.
Splitting it up at some random point in the middle makes no sense for rpm.
Call it `%___build_pre_env` and move *all* the environment stuff there and I'm
willing to consider.
--
Reply to this email directly or view it on GitHub:
https://githu
The external dependency generator has been on life support for about 20 years
now and we've been warning about it being deprecated for almost seven years
now. Yet it's still being used by some, and continues to attract unwanted
attention by simply being there.
I think it's time to finally pull
Last I checked, the only thing I know of still using this mechanism is the
MinGW/Windows binary dependency generator. @rwmjones, did this get fixed
sometime in the last few years?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2373#is
> > add a versioned requires. (libcurl.so.4()(64bit) → libcurl.so.4()(64bit) >=
> > 4.8.0).
>
> The whole point of sonames is that it's NOT tied to versions but the soname
> abstraction, and this kind of dependency breaks that point.
I can think of one real-world case this would have broke: the
AIUI mingw was one of the first ever to adopt the new-style internal generator,
but there are bunch of others, including but not limited to using the
filter-macros in Fedora. And then there's kernel ksyms stuff, only relevant for
RHEL. And whatever other distros are doing in this space.
--
Rep
Can someone describe (for example) a simple regular expression to use on spec
files to determine if they use this "external dependency generator"?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2373#issuecomment-1408270777
You are rece
In the spirit of release early and often, here goes the (admittedly rough)
first public draft of the rpm v6 package format that people have seen mentions
of here and there. As you'll notice, this will be a relatively conservative
update to the format, a facelift if you like, rather than a radica
Look for `_use_internal_dependency_generator` (getting set to 0, that's the
only thing it's ever used for) references in specs and macros. In Fedora,
another telltale is `%filter_setup` which uses that internally.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-soft
Also another hint is if you override `%_find_requires`, I think?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2373#issuecomment-1408550189
You are receiving this because you are subscribed to this thread.
Message ID:
It seems like we removed it from OCaml packages around Fedora 20, and from
libguestfs in Fedora 22. It is not used in any current package that I maintain.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2373#issuecomment-1408559567
You
Yeah, `%__find_requires` and `%__find_provides` overrides are telltale signs
worth checking, but neither of those do nothing at all by themselves unless
accompanied with `_use_internal_dependency_generator`. I've seen more than one
case where these were simply forgotten behind.
--
Reply to thi
To complement the following verify options:
[--nolinkto] [--nofiledigest] [--nosize] [--nouser] [--nogroup] [--nomtime]
[--nomode] [--nordev] [--nocaps]
I would like to suggest the following new options:
[--noconfiglinkto] [--noconfigfiledigest] [--noconfigsize] [--noconfiguser]
[--noconfiggroup]
Sorry but no, rpm has way too many cli switches as it is.
You can use 'rpm -Va --noconfig' to ignore config files entirely. For finer
control over which files to verify, the rpm verify functionality is available
in the Python bindings.
--
Reply to this email directly or view it on GitHub:
http
Closed #2375 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2375#event-8388429235
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint ma
> I can think of one real-world case this would have broke: the SDL ->
> sdl12-compat transition
Would that have required Fedora to do more than either [bump the so
version](https://github.com/libsdl-org/sdl12-compat/commit/883b629995e998e04b2ccd80a2c3ada46b0ce093)
or, worst case, manually add
> (libcurl.so.4()(64bit) → libcurl.so.4()(64bit) >= 4.8.0)
I'm going to start work on an implementation of this soon. I've been looking
over elfdeps.c and thinking through implementation details, yesterday.
One thing that comes to mind is that while the Provides: change would be
backward compa
> > I can think of one real-world case this would have broke: the SDL ->
> > sdl12-compat transition
>
> Would that have required Fedora to do more than either [bump the so
> version](https://github.com/libsdl-org/sdl12-compat/commit/883b629995e998e04b2ccd80a2c3ada46b0ce093)
> or, worst case, m
> to deal with weaknesses in the Debian's packaging system
I'm curious... do you have a reference that describes those weaknesses? (I
have very little experience with dpkg)
> Bumping the soversion would have been a big deal, since it's an ABI break
I'm not suggesting bumping the major version.
Ah, I misremembered when it came to where the weakness was. It had to do with
how the Steam Runtime "judges" library versions:
https://github.com/libsdl-org/sdl12-compat/issues/53#issuecomment-979976631
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-manage
"evr" is a defined strategy for creating a string summarizing a package's
critical details as a string, which the user can query. `(none)` is just a
special value the `rpm` cli uses to represent the nonexistence of a tag. I
would not expect an EVR to ever look like `(none):4.18.0-1.fc37`, that
Could the signature also cover something indicating the package version?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-4824257
You are receiving this because you are subscribed to this thread.
Message ID:
I ran test cases using rpm-4.18.0 and found one test case failed:
```
...
357: rpm -e and shared files removed 1.1 ok
358: rpm -e and shared files removed 1.2 ok
359: rpm -e and verify colored files removed 1.1 ok
360: rpm -e and verify colored files removed 1.2 ok
3
I tried to manually execute the test case and found that verifying conflicta
and conflictb alone was as expected.
```
[root@localhost testing]#
FAKECHROOT_BASE=/root/rpmbuild/BUILD/rpm-4.18.0/tests/rpmtests.dir/363/testing
fakechroot rpm --define "_buildhost testhost" --define "_topdir /build"
I get the same results as you, without -- force.
```
[root@localhost ~]# rpm -ivh /tmp/test-1.0-1.noarch.rpm
Verifying... # [100%]
Preparing... # [100%]
file /usr/sbin/aaa conflicts between attempted installs of test-1.0-1.noarch
and
That's a good question. Starting with, how exactly is the package version
determined? If we assume stricter header layout for v6 then it can't really be
in a header tag because we need to know the format before parsing it. A new
header magic I guess, but then that feels heavy-handed when the hea
> One thing that comes to mind is that while the Provides: change would be
> backward compatible, the Requires: change would not. New packages would be
> generated with Requirements that existing packages wouldn't satisfy, which
> would require a "rebuild the world" deployment that obsoletes mos
Ack, thanks for confirming that.
The "use-case" for --force is to replace some file(s) from another package with
different content, in which case it's reasonable to allow an operator override.
But there's no circumstance in which it makes sense for a package to overwrite
it's own contents as wo
[POSIX defines optarg only for options with
arguments](https://pubs.opengroup.org/onlinepubs/95399/functions/getopt.html)
and callback() is expecting optarg to be NULL for options without arguments,
however, at least on musl optarg will carry a pointer to the argument of the
previous option
30 matches
Mail list logo
