> 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)
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
Conan-Kudo commented on this pull request.
> addDep(>provides, ei->soname, NULL, ei->marker);
+ if (multiarch_deps)
+ addDep(>provides, ei->soname, NULL, ei->archmarker);
+ }
I'll add to the commit message about the backwards compatibility concern.
--
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
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
@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
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(>provides, soname, s,
The holdup here has been the rpmdbClose() changes, I've gotten rather wary of
changes to that area due to recent fix-regression-fix-regression round - see
commit 4c6e51e2c0e3deeb052ae3c47115b6d10cb0d696 which your change almost
reverts, and then the subsequent fixes and reverts in the history.
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:
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
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
Eh. It can cause a bit of awkwardness or need for discussion when you get
unlucky, agreed. So far I'm not very keen to send 3+ different PRs for small
fixes to cleanup when they don't depend on each other.
I appreciate the attention to detail. Cleanup fixes can be fiddly to get right
even
@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
13 matches
Mail list logo
