Re: Modularity and the system-upgrade path

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

 



Le samedi 16 novembre 2019 à 08:37 +0100, Nicolas Mailhot a écrit :
> 
> Sure, do some rpm fixing if necessary so the result feels less like a
> kludge than %dist. But, don’t rely on an external framework to do
> things for you instead of doing the necessary work (if any) at the
> component format level.

Hell, there’s no even any need to change rpm itself, Group exists and
has been liberated from previous use..

Just shove the module name in Group, write all the necessary macros and
templates to decline %{group} info in necessary parts of the spec,
write the necessary dnf plugins to do smart things with Group info.

And then when that is shown working (as in, upgrade conflict resolution
works), and the correct way to do modules is finaly understood, the
behaviour of the macros and dnf plugin can be streamlined and merged
and hardcoded in rpm and dnf cores.

(which may never happen, as dist showed, but that's not a problem with
rpm the application, that's a problem with Red Hat and rpm the project
not investing in cleaning up technical debt)

Regards,

-- 
Nicolas Mailhot
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [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