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.

Naively, it seems feasible to add such a field, which front-ends like Synaptic can also display.

Yes, I can click through https://packages.debian.org/ to find the link to the upstream code base and then pick through whatever interface the repo has to find out when they released whatever software version I'm using. But Debian could also include it.

I think the usefulness of this feature is self-evident, especially when deciding which package from several options to install. Version numbers don't really tell much, unless they use increasingly fashionable date versioning. If two packages,
superficially, do the same thing, I'll probably want the newer package. Alternatively, if I'm trying to stick to the most heavily tested software, I'll probably want an older package. If I want a package that supports technology that came out 10 years
ago, using 15-year-old software probably isn't going to cut it.

Aside from the "If you want it so much, you implement it and submit a PR," objections, what do people think of this?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

This runs into problems quickly. Relevant issues include:

- no upstream ever existed

- the upstream no longer exists

- the upstream doesn't release; the DD had to pick a particular
git/svn/hg... version and use that

- the official release date for the version was X, but this is
the eleventh time a DD has patched in fixes from later
versions

- the package is synthetic and has multiple release dates,
possibly including other problems from above

- 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.

Is it a plausible idea to suggest? Yes. Is making it mandatory
for Trixie reasonable? No.


-dsr-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu 03 Jul 2025 at 10:13:08 (+0200), Borden wrote:

I think the usefulness of this feature is self-evident, especially
when deciding which package from several options to install. [ … ]
If two packages, superficially, do the same thing, I'll probably
want the newer package. Alternatively, if I'm trying to stick to
the most heavily tested software, I'll probably want an older package.

Aside from the "If you want it so much, you implement it and
submit a PR," objections, what do people think of this?

I skimmed my list of packages that I add to new installations,
and I couldn't see any where upstream release date would be my
criterion for choosing one over another, rather than functionality,
suitable interface, length of my previous experience, etc.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu Jul 3, 2025 at 9:13 AM BST, Borden wrote:

Aside from the "If you want it so much, you implement it and submit a
PR," objections, what do people think of this?

I'd suggest the next step would be refining the idea as a Debian
Enhancement Proposal (DEP): https://dep-team.pages.debian.net/


--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ [email protected]
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu 03 Jul 2025 at 17:56:29 (+0100), Jonathan Dowland wrote:

On Thu Jul 3, 2025 at 9:13 AM BST, Borden wrote:

Aside from the "If you want it so much, you implement it and
submit a PR," objections, what do people think of this?

I'd suggest the next step would be refining the idea as a Debian
Enhancement Proposal (DEP): https://dep-team.pages.debian.net/

So does this fit somewhere into DEP-12?

"DRAFT DEP-12: Per-package machine-readable metadata about Upstream"

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu Jul 3, 2025 at 6:31 PM BST, David Wright wrote:

So does this fit somewhere into DEP-12?

"DRAFT DEP-12: Per-package machine-readable metadata about Upstream"

Reading DEP-12, it's not a great fit, because upstream release date is a property of a specific release, rather than an upstream project, and the
other fields the DEP talks about are scoped to the project as a whole.
It also looks like it might be stalled. But I would encourage interested parties to reach out to the DEP-12 authors, at least, and see what they
think.

--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ [email protected]
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)