Hi! On Tue, 2024-12-17 at 11:24:30 +0100, Diederik de Haas wrote: > On Tue Dec 17, 2024 at 4:32 AM CET, Guillem Jover wrote: > > On Mon, 2024-11-25 at 18:40:09 +0100, Diederik de Haas wrote: > > > Trying to figure out what exactly the various variables from pkg-info.mk > > > return, I added a number of 'debug' statements to my (modified) clone of > > > ffmpeg package repo's debian/rules file and got the following results: > > > > Hmm, wasn't the comment header at the top of the file not clear > > enough? If so I think that deserves to be improved, which I've tried > > with the attached patch. > > The main problem I had is that based on the description I could make a > (somewhat educated) guess as to what a variable would return, while I > needed to know exactly what I would be getting back. > As usual, once you *know* you can then see/follow the logic that was > used, but (in my case) I needed debug statements to *know*. > > The attached patch is an improvement :-) > But do (also) consider adding a practical (fictitious) example like I > did with the ffmpeg version.
I guess given the optional nature of the epoch and revision, I'd need to add at least three versions and their values for each variable. Hmm. :) Will see whether that does not end up very cluttered. > > I'm not sure these are something common enough to want to extract > > though, and my codesearch.debian.net search imagination is failing me > > (or giving me too many false positives for SOURCE_DATE_EPOCH). > > That is (ofc) a maintainers call, but my thought was: if you already > provide most version parts in variables, why not all? The cost seems > negligible to *me* as you already have done 90% of the work needed? > > You're obviously much more fluent in Makefile syntax/parsing then I am, > so it would be great if someone like you could provide it then me trying > to come up with something ... which (in my case) usually means searching > on codesearch and hoping/assuming that that other person did it correctly. > > I looked into this due to the debian-rules-parses-dpkg-parsechangelog > lintian message. Not providing all the parts *could* mean people would > still need to do that ... for that tiny bit that is NOT provided in > pkg-info.mk. Ah, the debian-rules-parses-dpkg-parsechangelog lintian tag! Ok, then I see where you are coming from, and why just for this alone that would make sense. I think there's indeed also a point of being complete about what gets exposed. My initial apparent reluctance was coming from thinking about a potential future where dpkg-buildpackage can obsolete all these make fragment files, and provide the information itself, and how that could end up polluting the environment for all children processes, for example. In any case, I'll try to get something going. Thanks, Guillem
