Work getting hwcaps microchiecture package geneataion into rpm

[Reon Beon]

https://hackweek.suse.com/all/projects/support-glibc-hwcaps-and-micro-arc...
Comments

    dancermak
    5 days ago by dancermak | Reply

    This sounds very intriguing! I have a few notes about this:
        you might be interested in this (sadly stalled) upstream PR:
https://github.com/rpm-software-management/rpm/pull/1035 which adds better detection of
the currently running microarchitecture
        once rpm gains the ability to automatically generate subpackages
(https://github.com/rpm-software-management/rpm/pull/1485), this could be completely
automated
        I would suggest to use actual boolean dependencies instead of packageand:
Supplements: (libfoo1 and x86-64-v3)

    And please, please make some noise about this and coordinate it with the other rpm
based distros, so that we don't end up with yet another SUSE-ism but instead lead the
innovation.

[Dan Čermák]

Reon Beon via devel <devel(a)lists.fedoraproject.org&gt; writes:

> https://hackweek.suse.com/all/projects/support-glibc-hwcaps-and-micro-arc...
>  Comments
>
>      dancermak
>      5 days ago by dancermak | Reply
>
>      This sounds very intriguing! I have a few notes about this:
>          you might be interested in this (sadly stalled) upstream PR:
> https://github.com/rpm-software-management/rpm/pull/1035 which adds better detection of
> the currently running microarchitecture
>          once rpm gains the ability to automatically generate subpackages
> (https://github.com/rpm-software-management/rpm/pull/1485), this could be completely
> automated
>          I would suggest to use actual boolean dependencies instead of packageand:
> Supplements: (libfoo1 and x86-64-v3)
>
>      And please, please make some noise about this and coordinate it with the other rpm
> based distros, so that we don't end up with yet another SUSE-ism but instead lead the
> innovation. 
Heh, the places where you see your name pop up ;-)

Now, back to business: I think this project has great potential and
could allow rpm based distributions to ship optimized packages without
having to leave old hardware behind (like the fortunately abandoned
baseline increase proposal from a few years ago).

So anyone interested in this: hackweek is open to anyone and I think
that Antonio won't mind getting help ;-)


Cheers,

Dan

[Florian Weimer]

* Dan Čermák:

>  Reon Beon via devel <devel(a)lists.fedoraproject.org&gt; writes:
>
> >
> https://hackweek.suse.com/all/projects/support-glibc-hwcaps-and-micro-arc...
> > Comments
> >
> >     dancermak
> >     5 days ago by dancermak | Reply
> >
> >     This sounds very intriguing! I have a few notes about this:
> >         you might be interested in this (sadly stalled) upstream PR:
> https://github.com/rpm-software-management/rpm/pull/1035 which adds better detection of
> the currently running microarchitecture
> >         once rpm gains the ability to automatically generate subpackages
> (https://github.com/rpm-software-management/rpm/pull/1485), this could be completely
> automated
> >         I would suggest to use actual boolean dependencies instead of packageand:
> Supplements: (libfoo1 and x86-64-v3)
> >
> >     And please, please make some noise about this and coordinate it with the other
> rpm based distros, so that we don't end up with yet another SUSE-ism but instead lead
> the innovation.
>
>  Heh, the places where you see your name pop up ;-)
>
>  Now, back to business: I think this project has great potential and
>  could allow rpm based distributions to ship optimized packages without
>  having to leave old hardware behind (like the fortunately abandoned
>  baseline increase proposal from a few years ago).
>
>  So anyone interested in this: hackweek is open to anyone and I think
>  that Antonio won't mind getting help ;-) 
I've tried to comment on this web page, but the comment was rejected:

| We've been pondering if we can use LTO to make the rebuilds
| transparent to most packages. Basically, make sure that LTO data is
| retained even in the final link, and then rebuild for different ISA
| levels outside of the package build system, and strip the LTO data for
| the baseline build. This of course needs GCC changes.


Thanks,
Florian

[Reon Beon]

Interesting.

[Reon Beon]

It says all the pull request checks have passed but they haven't done them yet.
Unfortunately.

[Reon Beon]

It has been 5 months and sadly the github pulls haven't been done yet. Sadly.

[Reon Beon]

Support glibc-hwcaps in rpm
https://github.com/rpm-software-management/rpm/issues/1812