Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux