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
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
@pmatilai Personally, I'd also like a solution to an annoying case that I have
on macOS where I have binaries with multiple architectures in them. What you're
saying here could probably be expanded to handle that too, I suppose, since it
essentially turns architectures into qualifiers for
Been thinking about this on and off. I'm totally convinced that we should
record the dependency architecture, rather than the existing super dumb
()64bit() marker thing. I'm just far less convinced that the architecture
should be embedded in each and every dependency string we store.
If we
@Conan-Kudo , I didn't say this looks bad or anything like that. It's just that
we're talking about a change with massive, long-standing effects. With such a
thing, we really need to know where we are going and where we want to be in 10
years rather than just "this change doesn't look half bad
For the package overall, it may be best to just use the Provides/Requires
mechanism with multiple things being generated, e.g.
Requires: cpu(arm)
Requires: cpu(neon)
Requires: cpu(thumb)
or
Requires: cpu(x86_64)
Requires: cpu(mmx)
Requires: cpu(sse)
Requires: cpu(sse2)
where cpu(*) features
I think I did okay in this PR avoiding many freak cases, though I definitely
see your point about the broader architecture handling.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> For example, while the arch marker generation seems pretty obvious in
> general, starting something new with hardcoding ARM stuff gives me the
> willies. I want ARM to stop being the freak case that always being worked
> around, and have the design flexible enough to cover it.
I'm not
This needs to be looked at together as a whole with any arch handling changes
we are about to do, so we don't end up doing something now that we'll bitterly
regret in six months time. So we need to build up the big picture first.
For example, while the arch marker generation seems pretty
Oh, another use case for some new architecture detection and handling library.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Meh. I am still not a big fan of this solution, but we can still change the
defaults later on. It indeed seems unlikely someone won't ship the compat
Provides anytime soon.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Incidentally, that's why I'm always populating biarch Provides. We're going to
be stuck with them for a _long_ time due to RHEL and SLE and proprietary
software.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ffesti If someone is trying to build a cross-distro package, accounting for
legacy from a newer-ish system (think Google Chrome or Bluejeans/Zoom Linux
RPMs being built on a specific host and shipped for everybody), being able to
flip behaviors makes sense.
--
You are receiving this because
Otherwise this looks pretty reasonable.
--
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/pull/1038#issuecomment-589081451___
Rpm-maint
Not a fan of the %__multiarch_deps macro tbh.
First it does not allow to completely switch to the new multiarch-deps whihc is
something distributions probably want to do at some point. So it does not
remove the need to eventually patch the .attr file.
The other question is whether there should
@Conan-Kudo pushed 1 commit.
17a2747565834832809d2ae53b739c9d94b9bca2 elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@mlschroe This should be good to look at again. :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo commented on this pull request.
> + break;
+case EM_MIPS:
+ elf_machine = "mips";
+ break;
+case EM_PPC:
+case EM_PPC64:
+ elf_machine = "ppc";
+ break;
+case EM_S390:
+ elf_machine = "s390";
+ break;
+case EM_ARM:
+
@Conan-Kudo pushed 1 commit.
7532c16153a793d516989f7b0cec622e85c10b33 elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Conan-Kudo commented on this pull request.
> + break;
+case EM_MIPS:
+ elf_machine = "mips";
+ break;
+case EM_PPC:
+case EM_PPC64:
+ elf_machine = "ppc";
+ break;
+case EM_S390:
+ elf_machine = "s390";
+ break;
+case EM_ARM:
+
mlschroe commented on this pull request.
> + break;
+case EM_MIPS:
+ elf_machine = "mips";
+ break;
+case EM_PPC:
+case EM_PPC64:
+ elf_machine = "ppc";
+ break;
+case EM_S390:
+ elf_machine = "s390";
+ break;
+case EM_ARM:
+ if
@mlschroe I've added a default to enable biarch when neither option is set.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo commented on this pull request.
> + break;
+case EM_MIPS:
+ elf_machine = "mips";
+ break;
+case EM_PPC:
+case EM_PPC64:
+ elf_machine = "ppc";
+ break;
+case EM_S390:
+ elf_machine = "s390";
+ break;
+case EM_ARM:
+
@Conan-Kudo pushed 1 commit.
f7ce837d5b6ed7663ce5774c6507fde6731436fe elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@Conan-Kudo pushed 1 commit.
b79056006456be9a923b2dc17c789f35fce2b3a8 elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
I don't like that it doesn't output anything if neither `--biarch-deps` not
`--multiarch-deps` is provided. I think it would be better to either change the
option to `--no-biarch-deps` or at least default to biarch if neither option is
given.
--
You are receiving this because you are
@mikhailnov what is e2k?
--
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/pull/1038#issuecomment-581179157___
Rpm-maint mailing list
It would be nice to add e2k here
--
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/pull/1038#issuecomment-581179105___
Rpm-maint
@Conan-Kudo pushed 1 commit.
5af676e833c61b294e3595bd50286aac07c3cb57 elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@Conan-Kudo pushed 1 commit.
7ac477c99bbfc2c1a3f26b483b474e33f5297852 elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@Conan-Kudo pushed 1 commit.
fb305121ad7228b56f7b86ede47b021b99a573c9 elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@Conan-Kudo pushed 1 commit.
df1293617f4b70f371aae69aaa058de0ab2bae16 elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@pmatilai @ffesti I *finally* revised #360. Phew!
--
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/pull/1038#issuecomment-581094273___
This changes elfdeps to emit dependency strings that contain full architecture
names instead of just declaring whether something is `64bit`. This means that
systems that allow more than two architectures to be installed on the same
computer will actually be able to resolve library dependencies
34 matches
Mail list logo
