On 01/05/2017 07:20 PM, Josh Boyer wrote: >> * Switch to using the Debian style of multi-arch layout, which instead of >> /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this would >> include the emergence of a de-facto standard for system layout between the major >> distributions. > > What does SuSE do for multi-lib? Or Arch or Gentoo? I don't think > Fedora switching would mean a de-facto anything. > Hmm, assuming http://www.pilotlogic.com/sitejoom/index.php/wiki?id=398 remains accurate (found it in a Google search), it looks like most distros are doing some combination of /usr/lib[32|64]. Though of course, on some distros, /usr/lib == 64-bit and others it's 32-bit. So I think there's definitely value in the explicit approach that Debian takes. >> So if we were to go this route, it would mean a great deal of work fixing up >> hundreds (if not thousands) of spec files to add explicit architecture >> dependencies, or else new functionality in DNF/libsolv to ensure that >> architectures don't change in a transaction. Or, ideally, both. > > Why wouldn't you have the rpm macros package automatically include the > %{?_isa} suffix in all built packages? The RPMs are built in > arch-specific chroots, so if it was done automatically it would likely > just need a mass rebuild? Am I missing a reason that wouldn't work? > Off the cuff, I can think of at least one quick example: SSSD. SSSD has a server and client libraries for both architectures (so 32-bit and 64-bit processes can both access the name service). If we arbitrarily added %{?_isa} to the sssd-clients sub-package, that would mean that pulling in sssd-clients.i686 on a 64-bit install would force it to pull in the 32-bit SSSD service, which would be a filesystem-level conflict (both would attempt to provide /usr/bin/sssd, /usr/libexec/sssd_*, /var/lib/sss/* etc.). That being said, maybe there's value in making this similar to the autoprovides, where we can set a flag in the spec file to skip automatically adding it. Since this is probably the exceptional case, that might be cleaner. Although as I think about it further, we would have to figure out how to handle virtual Provides: as well... there's no obvious way to differentiate them during rpmbuild, because they're fundamentally just strings. It's probably doable, but it will complicate matters and needs to be kept in mind. >> I think there is a lot of potential with these ideas (and they're compatible >> with our plans for modularity as well). Would people be willing to participate >> in such a task if we were to undertake it? > > Can you elaborate on the modularity plans, or point to a thread or > documentation if you've already described it? > Well, the short version is that we want to keep 32-bit and 64-bit runtimes in separate modules. So if you wanted to install 32-bit support, you'd pull in the matching 32-bit enhancement module for the base runtime you have. There's no documentation for this so far, but I'm planning to write something up very soon (tomorrow, if I can free up the cycles). The main reason for this is trying to simplify the module-building process. We really don't want to attempt to build both arches within the same buildroot for most of the reasons we've established in this extended conversation. My first proposal was one possible approach for this, but this second idea would solve the same problem, possibly with less jarring impact.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
