[RFE] Execute dependency generators on the .spec file which ships them

[voxik]

It would be very handy, if the dependency generators shipped by package could be used during build already.

E.g. when we build ruby package, it builds rubygems-devel package, which ships generators for rubygem- packages. But it also provides dozen of rubygem- subpackages and it would be very handy to utilize that generator already.

[ignatenkobrain]

I think if you override %__ruby_provides to %{buildroot}…, that should do the trick...

[ignatenkobrain]

But I agree, it is ugly.

[voxik]

I don't think I have anything to override, because I would need to have the *.attr file installed. I can define the %__ruby_provides but is it really that easy? I'd be surprised. Why we would need to have the *.attr file then?

[jasontibbitts]

I don't believe it's that easy if you don't already have a .attr file. It doesn't look to me as if RPM will look at %__foo_magic or %_foo_provides unless it sees %_fileattrsdir/foo.attr first. Of course, you could override %_fileattrsdir instead, but then you would have to copy the contents of the system directory because RPM looks only in one place. Even if you told RPM to look in the buildroot, the locations of the scripts would be wrong.

Looking at the code, I think that with ugly hacks it might be possible to get around all of that, but I can't imagine the rather small benefit would justify the ugliness given the tiny number of packages which install file attributes.

[pmatilai]

Yup, this is one of the main shortcomings of the "new" attr-based dependency generator and was just recently discussed again in the context of dynamic buildrequires. Besides self-dependencies (eg modules included in a language standard library and such), it'd be useful for source-based dependencies (automated depgen without shipping an otherwise irrelevant file in the package).
I thought there was a ticket for this already but maybe I'm mixing it up with the recent discussion elsewhere...

[voxik]

Looking into this again and in more detail, I think it would be enough if there were some dummy.attr file loaded. This would later enable to just define some __dummy_requires macro and this could be enough.

My (probably very silly idea) would be to ship find.attr file with RPM, that would enable to reuse the __find_requires macro used previously for the external helpers. This functionality is controlled by separate macro anyway. But I don't think that RPM protect these macros in any special way.

[voxik]

Of course, there is no need to ship a file if the proper keyword (e.g. find as I proposed above) is added into the fc->atypes list right here:

rpm/build/rpmfc.c

Lines 1186 to 1196 in c284d09

	if (rpmGlob(attrPath, NULL, &files) == 0) {
	nattrs = argvCount(files);
	fc->atypes = xcalloc(nattrs + 1, sizeof(*fc->atypes));
	for (int i = 0; i < nattrs; i++) {
	char *bn = basename(files[i]);
	bn[strlen(bn)-strlen(".attr")] = '\0';
	fc->atypes[i] = rpmfcAttrNew(bn);
	}
	fc->atypes[nattrs] = NULL;
	argvFree(files);
	}

I think that if we had the proper keyword, I could try to come up with a patch

[voxik]

Other option for me is to extract the generators into separate package, to have them available in the right place for the build. This has its own pros/cons

[voxik]

My (probably very silly idea) would be to ship find.attr file with RPM

Should I create package shipping such file for Fedora 🤪 It would need to be explicitly BRed, so it should not create any havoc 🤔

[voxik]

My (probably very silly idea) would be to ship find.attr file with RPM

Should I create package shipping such file for Fedora 🤪 It would need to be explicitly BRed, so it should not create any havoc 🤔

More details including implementation, where I went with local_generator name:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3MHROKOM53HM6NF7RGGLFBIQFG5IEIQG/