Thank you for your quick response. I have some responses, below: > - no upstream ever existed > - the upstream no longer exists > >From my experience, the package usually gets delisted when there is no >upstream. If there's no upstream, where is the source coming from?
> - the upstream doesn't release; the DD had to pick a particular git/svn/hg... > version and use that > - the package is synthetic and has multiple release dates, possibly including > other problems > Rolling releases, if that's what you're referring to, usually date-stamp their releases. Things like LineageOS and Mobian packages come to mind. > - the official release date for the version was X, but this is the eleventh > time a DD has patched in fixes from later versions > In fairness, Debian has its own versioning notation for non-upstream patches, which doesn't seem to have caused chaos yet. > - 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 wasn't suggesting this is feasible for Trixie. Even if it were, as not to break backwards compatibility, it would have to be an optional field, which I think would address the above issues. Much of it could be automated away: on the next release pull, add the upstream release date to the package. If there's no decent date stamp or controversy, leave empty. I'm hearing a lot of technical challenges, which at least tells me that my idea isn't inherently bad. Yes, most packages might not use it, but, honestly, how many packages are truly, 100% compliant to any specification? Even if 20% of the 60,000 packages can feasibly implement this feature, that's still greater than 0%, and it sounds like it could be useful.
