We wont be able to get rid of the internal OpenPGP parser in 4.19, and even
beyond that it could be useful as a bootstrap survival aid. But if it is to
stay at all, we need to cut down on the complexity dramatically. By far the
most complexity comes through subkeys whose handling still has any n
Interesting, I didn't know that. It's an idea. Of course, arch in dependency
version is also just an idea that does have some desireable qualities over
something else, but also downsides and limits.
Anyway, before any actual decisions we need to come up with actual list of
requirements and goal
> Yes it happens a lot, in one highly specific corner. Which is often best
> served by having that specific corner handle it because it has its own
> wrinkles that do not apply elsewhere, like version comparing the name here.
>
> In principle, Debian versioning isn't _that_ different from rpm. I
@frozencemetery Can you change `Also-authored-by` to `Co-authored-by`? The
latter is the generally recognized "magic tag" by Git commit processing
automation.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2249#issuecomment-1318604927
Y
I mean something like this: `libfoo.so.1 = 1.2.3`. Debian actually does this in
their symbol files, which allows packages to determine what minimum version
alongside a soname they need.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2
Do you mean the soname version or symbol versions? In either case though, the
problem is they *look* like versions but are nothing like rpm versions at all,
only equivalence matters so it'd just be confusing a plenty. Also the soname
version is a literal part of the string programs link against
> Thoughts? Downsides I'm not seeing? Multiple different versions of a provide
> is not something we commonly have so there may be gremlins related to that.
Actually, why don't we do this for adding the actual version for soname
dependencies? I don't think it makes sense to use the arch this way
@JetXujing pushed 1 commit.
84ecb642ef5965fd3dc565b1299f39a3aea74a49 fix rpm is blocked when open fifo file
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2261/files/cd361d59bd2ce67f38631f817001e0cda437f24b..84ecb642ef5965fd3dc565b1299f39a3aea74a49
You are receiving t
> Commit message should probably give a bit more background. It should mention
> the ticket it fixes but not rely on the information in the ticket still being
> available.
Thanks for your reply, I've added commit message
--
Reply to this email directly or view it on GitHub:
https://github.com/
Commit message should probably give a bit more background. It should mention
the ticket it fixes but not rely on the information in the ticket still being
available.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2261#issuecomment-13183
PR #1038 suggested appending the entire arch as a marker to the extracted
sonames, eg `libfoo.so.1()(x86_64)` but I dislike it as it pollutes the
dependency name, making it unnecessarily hard to query for.
Just this morning it dawned on me that perhaps we could place the architecture
into the
Okay, I think this has sat here long enough.
We basically already came to a decision to add multiarch support to rpm v6
format in 2019 (see #2197) but the details left open. I'm not merging it as I
don't think this is exactly how it's going to be, so I'm closing this now, lets
move the discussi
Closed #1038.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1038#event-7831237853
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Rpm-
13 matches
Mail list logo
