On Fri, Feb 05, 2021 at 01:47:00PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Feb 05, 2021 at 08:10:28AM -0500, Neal Gompa wrote: > > On Fri, Feb 5, 2021 at 7:03 AM Marek Marczykowski-Górecki > > <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Thu, Feb 04, 2021 at 10:56:43PM -0500, Neal Gompa wrote: > > > > On Thu, Feb 4, 2021 at 9:23 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > > > > > > > > > On Fri, Feb 05, 2021 at 12:17:28AM +0100, Marek Marczykowski-Górecki wrote: > > > > > > > > > > > > Does it make sense? > > > > > > > > > > That does make sense to me... and perhaps this fits in with that we > > > > > generate debuginfo/debugsource rpms when we build something. We just expand things > > > > > to also produce a buildinfo subpackage (of course then we need tools to > > > > > gather them/put them in a repo/allow users to install them, etc). > > > > > > Can you expand on that last part? Are you referring to some automation > > > that pulls debuginfo rpms into a separate repository? I guess the > > > buildinfo one should go into sources repo, right? > > > > > > > > Then, you could 'dnf install foobar-buildinfo-1.0-1.fc35' and possibly > > > > > there could be tools that would read that .buildinfo and feed the > > > > > src.rpm into mock or whatever with that input? > > > > > > > > > > > > > That is, of course, another valid strategy, and may make sense given > > > > the archful nature of some things. > > > > > > New sub-package sounds like a good idea. Is it ok to package it as a > > > single file in /usr/src/buildinfo? > > > > > > > Sure, we'd probably have buildinfo packages in a separate repository > > like we do debuginfo packages. Most people will never use them. > > > > The advantage of -buildinfo packages is that we can start with a > > buildinfo file and actually add more as we want to have more complete > > build records, including macros, environment variables, etc. > > Is it really worth creating a package for this? The payload could just > as well be implemented as a json file. Wrapping this in a separate > subpackage seems like unnecessary overhead. If we want to expose it in > a way that allows installing using dnf, maybe we could just stash it > in the debuginfo package? debuginfo packages are rather big already, > so the extra file wouldn't really matter much. The size of debuginfo packages depends on your POV. If you're already pulling in debuginfo packages, then the buildinfo won't make them bigger so it is not a concern on that side. If you're trying to consume the buildinfo data though, it feels pretty suboptimal to have to pull in the enourmous debuginfo RPM just to get access to a tiny piece of build info data. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
