On Fri, Jan 13, 2023 at 11:01 AM Sergey Zhmylev <s.zhmy...@yadro.com> wrote: > > > > > What is the use-case for this level of control then, and why would it > > be specific to RPM? > > > > Despite Alexander's words about this document, most of (I suppose, > actually all) wide-used rpm-based distros use the same well-known rpm > packages naming convention: red hat, opensuse, centos, oracle > enterprise linux, fedora, ... > > There are a lot of useful tools in this huge world of enterprise-level > distros, especially all those staff related to static security > scans/audit and around SBOM collection and processing. Those tools > rely on some basic rules of rpm naming for their analysis and do not > handle architectures like "genericx86_64".
You mean things that the Yocto Project does itself ? :) My humorous answer is on purpose. If there are gaps in the tooling, the project is interested in filing those gaps, and doing it in a way that anyone using the project could leverage. Not just the users of a specific packaging format. It isn't that we wouldn't want to enable that sort of tools / packaging capability, but if it opens us up to complexity or other issues down the road, it needs to be carefully considered. Which is what the questions in the thread are trying to determine. > > I.e. this level of control opens for us a tremendous window of > possibilities when our build pretends to be a mature distro. > FWIW. I would not characterize a distro created with the Yocto project as "immature". Cheers, Bruce > BR, Sergei > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#175837): https://lists.openembedded.org/g/openembedded-core/message/175837 Mute This Topic: https://lists.openembedded.org/mt/96233100/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
