Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)
Christoph Biedl: > Emilio Pozuelo Monfort wrote... > >> One thing with compat 10 that doesn't make a lot of sense to me is how >> dh_missing is enabled by default but a no-op. It'd make more sense to me to >> change that in compat 11 to be enabled by default and run with --list-missing >> (--fail-missing is probably too much at this point), or make it run with >> --list >> or --fail-missing, but not enabled by default, and make it an addon. > > As I planned to create a related wishlist bug report about that issue: > Agreed. > > The --fail-missing option saved my lower back many times in the past, > even when it was placed in dh_install. Therefore I'm certain it would > help other people as well. In other words, I was about to suggest to > make --list-missing the default in 11, and switch to --fail-missing > in 12. Noted. :) > Those who somehow manage to trigger a false negative (possibly > dracut is one of these) would have to use a --ignore-missing override > (not yet implemented) then, or use a more elaborate ignore mechanism: > They have two options (both are already implemented): dh_missing --exclude echo '' >> debian/not-installed > That is debian/not-installed which should no longer ignore file paths > then, also drop the warning on the usage of this file. What made you consider the use of debian/not-installed discouraged? I am not aware of any intentional warning against using debian/not-installed. The only two "warnings" related to not-installed are: * Wildcards are not supported. * It is not a fancy global "--exclude" mechanism; only a list of files that are (intentionally) missing. I.e. it will not make dh_install ignore the file. > There are often > files that should not go into a package, *.la files from library > packaging to begin with. Given the suggested policy change above, their > number will increase. Overriding dh_install defeats readability of > debian/rules, also -X might hit more files than intended. > > Christoph > Your concrete example suggests this could be solved by wildcard support in debian/not-installed. Would that work for you? :) > PS: Talking about "planned to create a wishlist bug report" ... after > losing several hours while fiddling with dh_systemd_* I saw the need for > a cleanup. Glad to see it's already underway. > You are welcome. :) I was considering to punt this until compat 12, but then I found several bugs in the interaction between dh_systemd_enable and dh_installinit. The fixes caused a handful of RC bugs in other packages, which made me realise that we should fix this sooner rather than later. Thanks, ~Niels
Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)
Emilio Pozuelo Monfort: > On 18/11/17 12:41, Niels Thykier wrote: >> I have received several requests to make --list-missing or >> --fail-missing the default (#650129 and #858834) and I intend to do so >> eventually. I am a little concerned with adding more changes to compat >> 11 (the list is rather long already), but I am happy with making >> --list-missing the default for compat 12. > > Fair enough, though it seems unlikely that --list-missing would cause any > trouble... but you are the debhelper expert ;) > It is not that --list-missing in itself will cause a lot of issues. It is that the documentation from v10 -> v11 is dauntingly long already and I want to avoid making it worse. In fact, I have already moved a handful of things to compat 12 to reduce the scope of v11. >> As for the sequences; we can add those to the next version of debhelper >> (a sequence change the parameters passed to a helper). If you file a >> bug for it with how you envision that, then I am happy to add it in one >> of the next uploads of debhelper. :) > > No need for a sequence if dh_missing starts doing something useful by default. > > Cheers, > Emilio > Ack. I mainly proposed it for enabling easier dh_missing already in compat 11. That said, we might get enough compat 12 items that it would make sense to release compat 12 before the release of buster. Thanks, ~Niels
Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)
Maximiliano Curia: > ¡Hola Niels! > > El 2017-11-18 a las 11:41 +, Niels Thykier escribió: >> Emilio Pozuelo Monfort: >>> It'd make more sense to me to change that in compat 11 to be enabled >>> by default and run with --list-missing (--fail-missing is probably >>> too much at this point), or make it run with --list or >>> --fail-missing, but not enabled by default, and make it an addon. So >>> that one can have: > >>> No dh_missing: > >>> %: >>> dh $@ > >>> Or for dh_missing: > >>> %: >>> dh --with missing $@ > >>> I think one of those two options would make more sense than the >>> status quo, and I probably lean towards the first option (enabled by >>> default with --list-missing). > >>> Thoughts? Let me know if you want a bug report about this. > >> I have received several requests to make --list-missing or >> --fail-missing the default (#650129 and #858834) and I intend to do so >> eventually. I am a little concerned with adding more changes to >> compat 11 (the list is rather long already), but I am happy with >> making --list-missing the default for compat 12. > > Please consider adding wildcard support for the debian/not-installed > files before making this the default. In the package pkg-kde-tools, the > /usr/share/pkg-kde-tools/qt-kde-team/3/list-missing.mk make script > implements a (rather primitive) support for wildcards in > debian/not-installed which might be used as a base for dh_missing. > I am happy to consider it. Please file a bug against debhelper for it, so I do not forget about it. :) Bonus if you can point to some existing cases where wildcard support would have worked or where you had to use the above tool instead. > Otherwise, please make allow this functionality to be easily disabled. > > Happy hacking, It can always be disabled by disabling the helper. The procedure for that (assuming no existing overrides exists) is in essence: echo '# Disable dh_missing' >> debian/rules echo 'override_dh_missing:' >> debian/rules Thanks, ~Niels
Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)
¡Hola Niels! El 2017-11-18 a las 11:41 +, Niels Thykier escribió: Emilio Pozuelo Monfort: It'd make more sense to me to change that in compat 11 to be enabled by default and run with --list-missing (--fail-missing is probably too much at this point), or make it run with --list or --fail-missing, but not enabled by default, and make it an addon. So that one can have: No dh_missing: %: dh $@ Or for dh_missing: %: dh --with missing $@ I think one of those two options would make more sense than the status quo, and I probably lean towards the first option (enabled by default with --list-missing). Thoughts? Let me know if you want a bug report about this. I have received several requests to make --list-missing or --fail-missing the default (#650129 and #858834) and I intend to do so eventually. I am a little concerned with adding more changes to compat 11 (the list is rather long already), but I am happy with making --list-missing the default for compat 12. Please consider adding wildcard support for the debian/not-installed files before making this the default. In the package pkg-kde-tools, the /usr/share/pkg-kde-tools/qt-kde-team/3/list-missing.mk make script implements a (rather primitive) support for wildcards in debian/not-installed which might be used as a base for dh_missing. Otherwise, please make allow this functionality to be easily disabled. Happy hacking, -- "If it ain't broke, don't fix it" -- Bert Lance "If we can't fix it, it ain't broke" -- Lieutenant Colonel Walt Weir Saludos /\/\ /\ >< `/ signature.asc Description: PGP signature
Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)
On 18/11/17 12:41, Niels Thykier wrote: > I have received several requests to make --list-missing or > --fail-missing the default (#650129 and #858834) and I intend to do so > eventually. I am a little concerned with adding more changes to compat > 11 (the list is rather long already), but I am happy with making > --list-missing the default for compat 12. Fair enough, though it seems unlikely that --list-missing would cause any trouble... but you are the debhelper expert ;) > As for the sequences; we can add those to the next version of debhelper > (a sequence change the parameters passed to a helper). If you file a > bug for it with how you envision that, then I am happy to add it in one > of the next uploads of debhelper. :) No need for a sequence if dh_missing starts doing something useful by default. Cheers, Emilio
Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)
Emilio Pozuelo Monfort: > On 12/11/17 11:25, Niels Thykier wrote: >> Hi, >> >> >> The debhelper compat level 11 is about to be finalized and we invite you >> to test it out. There are no additional changes planned to compat 11 at >> the moment, but there might be changes in response to feedback from testers. > Hi, Thanks for the feedback. :) > One thing with compat 10 that doesn't make a lot of sense to me is how > dh_missing is enabled by default but a no-op. Just a clarification; dh_missing is enabled by default in all compat levels (being an no-op). It is a no-op in all stable compat levels (i.e. <= 10) because it mirrors the default in dh_install. > It'd make more sense to me to > change that in compat 11 to be enabled by default and run with --list-missing > (--fail-missing is probably too much at this point), or make it run with > --list > or --fail-missing, but not enabled by default, and make it an addon. So that > one > can have: > > No dh_missing: > > %: > dh $@ > > Or for dh_missing: > > %: > dh --with missing $@ > > I think one of those two options would make more sense than the status quo, > and > I probably lean towards the first option (enabled by default with > --list-missing). > > Thoughts? Let me know if you want a bug report about this. > > Cheers, > Emilio > I have received several requests to make --list-missing or --fail-missing the default (#650129 and #858834) and I intend to do so eventually. I am a little concerned with adding more changes to compat 11 (the list is rather long already), but I am happy with making --list-missing the default for compat 12. As for the sequences; we can add those to the next version of debhelper (a sequence change the parameters passed to a helper). If you file a bug for it with how you envision that, then I am happy to add it in one of the next uploads of debhelper. :) Thanks, ~Niels
Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)
Emilio Pozuelo Monfort wrote... > One thing with compat 10 that doesn't make a lot of sense to me is how > dh_missing is enabled by default but a no-op. It'd make more sense to me to > change that in compat 11 to be enabled by default and run with --list-missing > (--fail-missing is probably too much at this point), or make it run with > --list > or --fail-missing, but not enabled by default, and make it an addon. As I planned to create a related wishlist bug report about that issue: Agreed. The --fail-missing option saved my lower back many times in the past, even when it was placed in dh_install. Therefore I'm certain it would help other people as well. In other words, I was about to suggest to make --list-missing the default in 11, and switch to --fail-missing in 12. Those who somehow manage to trigger a false negative (possibly dracut is one of these) would have to use a --ignore-missing override (not yet implemented) then, or use a more elaborate ignore mechanism: That is debian/not-installed which should no longer ignore file paths then, also drop the warning on the usage of this file. There are often files that should not go into a package, *.la files from library packaging to begin with. Given the suggested policy change above, their number will increase. Overriding dh_install defeats readability of debian/rules, also -X might hit more files than intended. Christoph PS: Talking about "planned to create a wishlist bug report" ... after losing several hours while fiddling with dh_systemd_* I saw the need for a cleanup. Glad to see it's already underway. signature.asc Description: Digital signature
Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)
On 12/11/17 11:25, Niels Thykier wrote: > Hi, > > > The debhelper compat level 11 is about to be finalized and we invite you > to test it out. There are no additional changes planned to compat 11 at > the moment, but there might be changes in response to feedback from testers. One thing with compat 10 that doesn't make a lot of sense to me is how dh_missing is enabled by default but a no-op. It'd make more sense to me to change that in compat 11 to be enabled by default and run with --list-missing (--fail-missing is probably too much at this point), or make it run with --list or --fail-missing, but not enabled by default, and make it an addon. So that one can have: No dh_missing: %: dh $@ Or for dh_missing: %: dh --with missing $@ I think one of those two options would make more sense than the status quo, and I probably lean towards the first option (enabled by default with --list-missing). Thoughts? Let me know if you want a bug report about this. Cheers, Emilio
Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)
Adrian Bunk: > On Sun, Nov 12, 2017 at 10:25:00AM +, Niels Thykier wrote: >> ... >> >> Backport availability >> = >> ... >> *Caveat*: Packages using the cmake build system should be careful as >> cmake in stretch does not respond to the >> -DCMAKE_INSTALL_RUNSTATEDIR=/run change in compat 11. If this is a >> problem for your package, the package should probably stay at compat 10 >> until buster is released. > > Is anything preventing a backport of cmake to stretch-backports? > > This would allow debhelper to add Breaks on older cmake versions, > which would also automatically handle all backports situations > in a correct way. > > > cu > Adrian > Assuming a cmake backport is feasible and materializes, then I am happy to add the Breaks in debhelper to make this case "just work(tm)". That said, I am not ready to commit to maintaining a backport of cmake nor have I researched whether it is feasible at all. Thanks, ~Niels
Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)
On Sun, Nov 12, 2017 at 10:25:00AM +, Niels Thykier wrote: >... > Full list of changes in compat 11 > = >... > > - The cmake buildsystem now passes > > -DCMAKE_INSTALL_RUNSTATEDIR=/run to cmake(1). > > > > Caveat: This option silently does nothing in cmake versions > > prior to 3.8. Please keep this in mind if your package is > > regularly backported to a suite (e.g. stretch-backports) > > where cmake is older than 3.8. >... > Backport availability > = >... > *Caveat*: Packages using the cmake build system should be careful as > cmake in stretch does not respond to the > -DCMAKE_INSTALL_RUNSTATEDIR=/run change in compat 11. If this is a > problem for your package, the package should probably stay at compat 10 > until buster is released. Is anything preventing a backport of cmake to stretch-backports? This would allow debhelper to add Breaks on older cmake versions, which would also automatically handle all backports situations in a correct way. > Thanks, > ~Niels cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
