On Tuesday, March 10th, 2026 at 10:25 PM, Maciej Barć <[email protected]> wrote:
> W dniu 10.03.2026 o 18:58, Ulrich Müller pisze: > >>>>>> On Tue, 10 Mar 2026, Filip Kobierski wrote: > > Maybe these packages could masked in a special profile? Or (if we want > > the information in the ebuild itself) introduce a new PROPERTIES or > > RESTRICT token? > > > > We have PROPERTIES=test_network and RESTRICT=network-sandbox and I think > it might be a good idea to put them into one of those. > But for me both feel like this information does not belong in the ebuild > file. Whilst package managers can recognize any token in PROPERTIES and RESTRICT as per the PMS, I don't think it makes sense to use it as they are for managing behavior during the build. Like what is the package manager going to do with it? Fail before merging? Ignore it and just make the user grep the ebuilds to do anything with this information? > > Why not place this in metadata.xml? > Maybe this calls for new tag that will tell maintainers that package > needs EXTENSIVE TESTING we already have a "reverse" tag to this in the > metadata called "<stabilize-allarches/>". Of all the options a new metadata element does sound the least worse option. It would require modifying GLEP 68 though. > I think introducing a "slop" PROPERTY feels like wrong approach to > engineering here. Just mark those packages as "bombs" because they might > explode and have to be handled with extreme care. I think metadata is > the right place for it. Yeah, I've had one package where the development skeeved me out even before they adopted LLM's. In that case it was an artifact of messy git discipline and the language having GUI editor leading to messy changes. So some marker about "here be dragons" would do something there, at least it could be used as heavy discouragement for stabilization. -- Best Regards Alfred Wingate
