On Thu, Jul 03, 2025 at 08:42:52AM -0400, Dan Ritter wrote: > Borden wrote: > > On a few projects, I've discovered how ancient some software is (like, > > last commit more than 15 years ago ancient). Unless I missed something, > > `apt-cache show` doesn't show the upstream release date.
Ignoring the usual gripes about outdated software versions in stable, this seems like a pretty great idea. I am not sufficiently familiar with the .deb metadata format, but I suspect including an Upstream-Version field to any given package would be trivial. Displaying that field in apt-cache show may or may not require a minor code change. > This runs into problems quickly. Relevant issues include: s/problems/exceptions/ > - no upstream ever existed > - the upstream no longer exists Okay, sure, and it's entirely reasonable to note that in the Upstream-Version field. > - the upstream doesn't release; the DD had to pick a particular > git/svn/hg... version and use that That can also be noted with an identifier for the commit, which certainly has a date attached. > - the official release date for the version was X, but this is > the eleventh time a DD has patched in fixes from later > versions That doesn't change the upstream version the package is based on. > - the package is synthetic and has multiple release dates, > possibly including other problems from above That can be noted in the Upstream-Version field and more details can be included in the description. Or not. > - there are roughly 60,000 packages in Trixie. At five minutes > per package to research the date, make a decision, add the > header and re-upload, that's 5000 hours of new work you are asking > volunteers to do. Two and a half years of full-time employment. I don't think the suggestion was that DDs would have to go through all previous packages and update them. It makes sense to do this going forward whenever a new package version is uploaded. Or possibly only when a package based on a new upstream version is uploaded. > Is it a plausible idea to suggest? Yes. Is making it mandatory > for Trixie reasonable? No. There was absolutely no suggestion that it should be mandatory. It's useful information that package maintainers can be encouraged to include in a standardized way. That's it. There is no need to invent burdens. > -dsr- --Gregory
