very minor note: when updating these blocks, the comments haven't been updated.
This comment:
/* periods and plusses are escaped, splats become '.*' */
could read:
/* periods, plusses and carets are escaped, splats become '.*' */
and this one:
/* Copy pattern, escaping periods, pr
https://github.com/rpm-software-management/rpm/commit/2797d00ecd224a59a8ca967f40240e827ff31c69
was an awful change. Please revert it.
It doesn't matter that you've never published to pypi; so long as you install
an egg-info file people will rely on its contents. I was expressing a
dependency on
This isn't about package dependencies. It's about Python ecosystem
dependencies. These particular dependencies are read by setuptools/distutils,
and by tox.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com
No. No, not that either. The *code* works fine, if it actually gets run,
because the name of the module itself (`rpm`) has not changed. This is about
bits of Python-ecosystem infrastructure that allow for the expression and
checking of dependencies. Specifically, in my case, `setuptools` and `to
BTW, I'm around on Freenode and RH internal IRC (adamw on both) for anyone who
wants to talk about this in real time. Also tagging @Conan-Kudo and @ffesti as
the committers.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
h
Here's a commit that had to write a whole extra function in its `setup.py` to
get around this:
https://github.com/rebase-helper/rebase-helper/commit/2f1401c0adfc139aa3ecc12cdc21086d2fe69ac9
which is not an approach I can easily take, because I want to share the same
requirements between `setup.
"Since we don't publish to PyPI for very obvious reasons, any reliance on
setuptools information was always hokey."
The document I linked above *specifically states that it is reasonable to
express dependencies on things that aren't in pypi*. In a section
titled...[Dependencies that aren't in
See edit.
--
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/373#issuecomment-353669089___
Rpm-maint mailing list
Rpm-maint@lists.
No. You're wrong. Really, you're wrong. It's very simple to demonstrate. These
are the steps.
git clone https://pagure.io/fedora-qa/relvalconsumer.git
cd relvalconsumer
git checkout 1.1.0
sudo python setup.py install
Try that with an older `python2-rpm` installed, and it will wor
"Adding 2 egg-info files with different Name: strings might work." - yes, it
might, but that would be your job, not mine. It's a potential solution to this
problem, but you'd need to understand (which you apparently don't right now)
exactly what the purpose and meaning of these files is, and the
Please stop focusing on my specific use case here. The point is, you're
providing a library, and its metadata for Python distribution purposes is
significant, and it's a really bad idea to just change its name in that
metadata purely for purposes of 'neatness' or predictability when you've
*alr
OK, let's both calm down a bit. I was just annoyed at running into this
entirely unnecessary problem while i was in a hurry last night. I agree that in
practical terms it's not a major disaster that's likely to affect lots of
people catastrophically. It's still *wrong*, though.
Let's take a sec
BTW, there's a rather [cryptic
bit](https://setuptools.readthedocs.io/en/latest/setuptools.html#metadata) of
the setuptools docs that sort of suggests you might be able to use a `provides`
kwarg to `setup()`, so we could try something like:
setup(name='@PACKAGE_NAME@',
version='@VERSION
I'm definitely only talking about Python concepts here. C concepts don't play
into all this *at all* since we're only talking about Python ecosystem stuff.
"If setup tools is constructing module paths from egg-info Name: directives
(which is rather deficient)"
No, it's not doing that. There is
@Conan-Kudo Oh, I'm sure *everyone* who tries to express a dependency like this
tries the name 'rpm' first. I certainly did. :P But as you say, that never
previously did work, so anyone who's previously tried and not just given up
when 'rpm' didn't work must surely have landed on 'rpm-python', l
@n3npq "After reading #273, it isn't clear why a egg-info mechanism tied to
pypi"
egg-info isn't "tied to" pypi, just like RPM isn't "tied to" dnf or zypper or
yum or Fedora's repositories or SUSE's repositories or Red Hat's repositories.
egg is a "built distribution" format, just like .rpm is
@Conan-Kudo "Actually, what they did was just not specify it at all in
setuptools." - sure, that's what I meant by "just given up when 'rpm' didn't
work". I was positing that some obsessive nerds like myself would figure out
what the name actually was and use that, while some people would just s
I'm sort of reaching the point where I'm thinking it's just not worth trying to
explain it any more, especially since apparently trying to bring an RPM analogy
into the discussion has only made things *more* confusing, not less. But no,
there's no "duelling" going on. I only referred to RPM conc
"rather than blaming rpm developers for Newer! Better! Bestest! Python (and
depsolvers) changes."
Python didn't *change* anything here. rpm did: the name in the `setup.py` you
ship. That's it. That's the extent of the change that caused the problem. I'm
still baffled as to why it seems so hard
@pmatilai we were already done with the noise before more people started
chipping in =)
I was rather assuming that *RHEL* has also been shipping the `.egg` files,
meaning that the `rpm-python` name will be baked into RHEL 7 and thus around at
least somewhere for God knows how long, unless we ca
Aha, that's good to know. So in that case maybe we really could just change the
name in F26. Or say that it's not worth caring about enough to fix since it'll
only matter during F26's lifetime anyway.
--
You are receiving this because you are subscribed to this thread.
Reply to this email direc
Note, there is a pattern here that seems valid to me, which triggers this
warning. See [Fedora's evolution-data-server
package](https://src.fedoraproject.org/rpms/evolution-data-server/blob/rawhide/f/evolution-data-server.spec).
An edited extract:
```
# 0-99: General patches
# 100-199: Flatpak
Closed #3865 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3865#event-18708651801
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
AdamWill left a comment (rpm-software-management/rpm#3865)
well, hmm, I guess it *could* still be rpm's "fault" that this is now fatal to
the image build where it wasn't before? I'll have to dig into how dnf uses rpm
exactly.
--
Reply to this email directly or view it on GitHub:
https://github
AdamWill left a comment (rpm-software-management/rpm#3865)
OK, so this isn't rpm, and it's *two* things.
the fakeroot case is quite simple, and it's caused by bash 5.3. Installing
fakeroot with bash 5.2 gives no errors. Installing fakeroot with bash 5.3, one
of the commands prints a usage messa
AdamWill left a comment (rpm-software-management/rpm#3865)
I was actually trying to fix the same thing at the same time and we collided :D
I rebased my changes on yours - I disabled the test that was frequently failing
on s390, and also adjusted the scriptlets so they will always exit 0, as per
AdamWill created an issue (rpm-software-management/rpm#3865)
**Describe the bug**
Since Fedora Rawhide updated to RPM 6.0 beta 1 (package rpm-5.99.91-1.fc43 , in
Fedora-Rawhide-20250710.n.0), it seems like multi-line update-alternatives
calls in RPM scriptlets aren't working. We've seen this in
AdamWill left a comment (rpm-software-management/rpm#3865)
OK, yeah, if I change fakeroot.spec to look like this:
```
/usr/sbin/alternatives --install "%{_bindir}/fakeroot" fakeroot
"%{_bindir}/fakeroot-tcp" 50 --slave %{_bindir}/faked faked
%{_bindir}/faked-tcp --slave %{_libdir}/libfakeroot/li
AdamWill left a comment (rpm-software-management/rpm#3865)
that's only fakeroot, though. wine-core doesn't have trailing continuations,
but it also fails.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3865#issuecomment-3089828688
You
AdamWill left a comment (rpm-software-management/rpm#3865)
hmm, dang...I can actually reproduce the problem in a mock root with
rpm-5.99.90-6.fc43.x86_64 . So maybe it's not rpm 6.0 beta 1 causing this? But
if not I have no darn clue what *is* causing it.
--
Reply to this email directly or vie
30 matches
Mail list logo
