Hi, On Wed, Dec 22, 2021 at 11:26:58PM +0100, Andrea Pappacoda wrote: > Those extra headers should definitely get included in the package, I > did not notice that the CMake script installs only [1] date.h :/
(Perhaps a bit overkill here, but if it is reasonably easy to do, try to build a test program as an autopkgtest. Perhaps even the testsuite. As a bonus you get faster transitions to testing.) > I'll patch this in the next revision! It will probably come after the > holidays though, as I'll busy studying / fixing my mail server / > partying. No problem – as somewhat evident by my own reply delay: A late happy festive days & an upcoming happy new year! (if applicable) I work on/use that program once in a year and that was before I reported this here, so it isn't super urgent to begin with 😉 (it is generating an ods file for a friend who records daily business statistics in it [which are then summed up by week and month] – not rocket science, but wiring 12 months by hand in Libreoffice is just too error prune/tedious). > Regarding the r-cran-tzdb package, you see my (short) discussion with > its maintainer in #998331 [2] Ah, okay. Thanks for discussing it already! (I tend to be in the "no-embeds" camp, but I see how people can disagree on that and this embed in particular isn't so bad to really object) > As for sponsoring, it would of course be nice, but in the meantime I'd > like you to ask a quick question about this package: do you think that > packaging it under libhowardhinnant-date-dev was a good idea? Because > I patched the project to install CMake config files with the > "howardhinnant-date" name instead of just "date", but its headers > still get installed to paths like "date/date.h". My reasoning for this > was to not pollute the global namespace with such a general name, but > I also wanted to not break projects correctly including date/date.h. Yeah, I think it is fine as is. "date" really would have been a bit short as a package name beside that nobody would know what the package contains as there are a gazillion things named 'date' (including the command itself…). Making a package name shorter/more generic is an easy rename usually, so if it turns out that the world expects it to have another name that is easy to do. Removing a name conflict on the other hand tends to be a huge pain for maintainers and users alike: Prior "art": node (JS and amateur radio), chromium (browser and game), firebird (browser and database – upstream renamed to firefox quickly), … So, if that can be avoided, that is a service to everyone. It is still a very generic term even in /usr/include, but I assume that at this point nobody in the C/C++ community will try to claim it and having the same name as upstream here has clear benefits while renaming would probably mean additional work/patches for every user. So that is a bridge you better think about crossing only if there is a need. ☺ Best regards David Kalnischkies
signature.asc
Description: PGP signature
