Closed #360.
--
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/360#event-2949768349___
Rpm-maint mailing list
Rpm-maint@lists.rpm.o
Half a year later, this still isn't going anywhere that I can tell. Lets just
close it with the notion that you'll reopen/submit a new one once you have
something new. Years old PR's aren't good for anybody.
--
You are receiving this because you are subscribed to this thread.
Reply to this emai
@ffesti I'm in the middle of reworking this now per the feedback you and
@pmatilai gave. OpenMandriva is interested in this change landing, so I've
prioritized getting this PR done.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on G
Switching over such central piece of the of the dependency system is not an
trivial matter. This patch still misses the necessary compatibility shims to be
able to switch over a distribution:
Enable the new Provides first and only later move the Requires to the new style
and as third disable the
@Conan-Kudo: I will add yet another horror to my Packaging Hall of Shame.
Meanwhile there aren't any common platforms that have/need 6 elf architectures,
so there is some other attribute of the libraries that is being mapped into an
"arch".
The enum used to define elf architectures is tied to s
> Adding a per-package Debian platform string that is inherited across elf
> dependencies within a package would be mostly sufficient (but would not
> permit a single package to carry multiple elf binaries from different, which
> no one has attempted and is better handled with subpages IMHO)
Sa
For full multiarch you'd have to encode a whole lot more than 4 bits into the
color. Which is not to say it couldn't be done, but for something that
apparently nobody would be using (at least in part because of 15 year old
simplistic repo format, sigh, another part being not that many people
un
@mlschroe: yes colors aren't in repository metadata. That problem is perhaps
best solved by extending repository markup rather than appending a platform
string to dependencies.
Adding a per-package Debian platform string that is inherited across elf
dependencies within a package would be mostly
Ah, I see that this is with external tools/elfdeps.c which has no way to pass a
file color and so Yet Another Mechanism is being invented.
I'd suggest that compatibility with the internal rpm elf dependency generator
is perhaps more important than compatibility with Debian multiarch platform
na
Ah, I see that this is with external tools/elfdeps.c which has no way to pass a
file color and so Yet Another Mechanism is being invented.
I'd suggest that compatibility with the internal rpm elf dependency generator
is perhaps more important than compatibility with Debian multiarch platform
na
That's because the needed information simply isn't available in the repository
metadata...
--
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/360#issuecomment-368811843___
Conan-Kudo commented on this pull request.
> addDep(&ei->provides, ei->soname, NULL, ei->marker);
+ if (multiarch_deps)
+ addDep(&ei->provides, ei->soname, NULL, ei->archmarker);
+ }
I'll add to the commit message about the backwards compatibility concern
Conan-Kudo commented on this pull request.
> @@ -146,6 +244,8 @@ static void processVerDef(Elf_Scn *scn, GElf_Shdr *shdr,
> elfInfo *ei)
continue;
} else if (soname && !soname_only && !skipPrivate(s)) {
addDep(&ei->provides, soname, s, ei-
Note that elf dependency color already disambiguates more than 2 elf
architectures, including identical requirement strings, so there is no real
need to add a multiarch platform string to Requires:.
Colored dependencies will match only white or same colored dependency strings.
The real problem
Okay so those two cases seem to be intentional for creating backwards
compatible provides, but for requires one obviously doesn't need to create
compat entries. Clearly there needs to be a way to handle the compat situation,
but if somebody was starting from a distro from scratch you probably wo
pmatilai commented on this pull request.
> addDep(&ei->provides, ei->soname, NULL, ei->marker);
+ if (multiarch_deps)
+ addDep(&ei->provides, ei->soname, NULL, ei->archmarker);
+ }
Oh and ditto here too, shouldn't the non-archmarker addDep() be behind an
pmatilai commented on this pull request.
> @@ -146,6 +244,8 @@ static void processVerDef(Elf_Scn *scn, GElf_Shdr *shdr,
> elfInfo *ei)
continue;
} else if (soname && !soname_only && !skipPrivate(s)) {
addDep(&ei->provides, soname, s, ei->m
pmatilai commented on this pull request.
> + snprintf(archmarker, sizeof(archmarker), "(%s%s-%s)", elf_machine,
> elf_endian, elf_bitsize);
+ break;
+case EM_X86_64:
+ /* This handling for x32 makes me weep inside... */
+ if (ehdr->e_ident[EI_CLASS] == ELFCLASS32) {
+
Conan-Kudo commented on this pull request.
> + snprintf(archmarker, sizeof(archmarker), "(%s%s-%s)", elf_machine,
> elf_endian, elf_bitsize);
+ break;
+case EM_X86_64:
+ /* This handling for x32 makes me weep inside... */
+ if (ehdr->e_ident[EI_CLASS] == ELFCLASS32) {
pmatilai commented on this pull request.
> + snprintf(archmarker, sizeof(archmarker), "(%s%s-%s)", elf_machine,
> elf_endian, elf_bitsize);
+ break;
+case EM_X86_64:
+ /* This handling for x32 makes me weep inside... */
+ if (ehdr->e_ident[EI_CLASS] == ELFCLASS32) {
+
@mlschroe Done.
--
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/360#issuecomment-344594754___
Rpm-maint mailing list
Rpm-maint@li
@mlschroe I removed the redundant `addArchedDep()` as it's identical and I can
just pass in the multiarch variant to be added.
--
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/pu
@mlschroe Oh wait, I see what you're talking about. You mean use `addDep()` and
pass in the archmarker instead...
--
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/360#issuec
@mlschroe I originally had it with `--no-multiarch` to disable for testing to
make it easy, and I thought it was okay to leave that way, but I switched it as
you asked.
As for why I didn't touch `addDep()`? It's easier for me to have a different
function when I want to generate both old-style a
Why isn't this "can be enabled with --multiarch" and no-multiarch is the
default?
--
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/360#issuecomment-344572524
addArchedDep seems to be identical to addDep, so I don't see why you don't just
use ei->marker but generate it differently.
--
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/
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 corr
27 matches
Mail list logo
