Hi Steve, On Wed, May 17, 2023 at 10:39:21PM -0700, Steve Langasek wrote: > > I note that this may pose problems with intra-library interaction. Say > > we need to enable time64 on a higher level library and a lower level > > library does not use time_t, but uses off_t. As such, you'd opt out of > > lfs on the lower level library, but the upper one uses it with lfs by > > having enabled time64. How do you intend to deal with such cases? > > In such a case the lower-level library should opt in to lfs and have a > package name change as well. Up to this point I've casually assumed there > weren't any such packages, but this can also be detected via static analysis > of the archive.
Did you encounter such cases in your updated analysis? > > Something that would help with this transition would be a > > checker-as-a-service kind of thing that indicates: > > * Is my package affected by time64? > > * Does my package enable time64? > > + On i386? > > * Do time64 changes affect downstream packages? > > + Which? > > > I understand that answering these questions on a per-package basis is > > far from trivial. That much is evident from your analysis. I think this > > is ok. Even if such a service says "unknown" 10% of the time, that'd > > still be very useful. Do you think you could turn your analysis into a > > continuous checking service? > > This sounds like a substantial amount of work (and computing resources, to > enable this to "continuously" check) and I don't think I understand how it > would help the transition, if all of the library transitions are being > coordinated centrally. Could you elaborate? I'm not sure how this would look like exactly. I see some options: + The lists that already exist describe the second level of affectedness (changes ABI) already. + A double-rebuild varying time64 could employ reproducible builds to judge affectedness (generally) and we would get a list of unaffected packages in particular. + If we enable this via dpkg, .buildinfo files can be used to track how many packages have been rebuilt with time64 (given that ben will not always see a difference). + Finally the benfile you proposed may also help to judge this. I don't yet quite see how this transition can accurately be tracked using ben, but I'm hoping for a positive surprise here. Failing that, fusing some of these information sources into a continously updated view would improve our understanding of how far this went. I agree that the amount of work to spend on such tracking needs to be balanced. In effect, we practically do want to rebuild much of the archive here and while some of that will cause dependency changes, there are enough examples that will be invisible to ben to justify a bit more tracking effort here in my view. I hope you can agree with this view. Helmut
