On Tue Dec 17, 2024 at 1:04 PM CET, Guillem Jover wrote: > 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: > > > > 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. > > > > 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 took ffmpeg for 'debugging' as it had all components, but it was actually for another package (mumble). My guess: with your patch and an example with all components (like ffmpeg), it should be clear for everyone even if they don't have them all. > > 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? > > > > 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. Yeah, while it seems simple to me, I don't have the insight and broader view that you have, hence maintainers call :-) > In any case, I'll try to get something going. Awesome! TIA :-) Cheers, Diederik
signature.asc
Description: PGP signature
