Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #280547 > unrolled thread

Feature idea: show upstream release dates on packages

Back to article view | Back to linux.debian.user

Contents

  Feature idea: show upstream release dates on packages Borden <borden_c@tutanota.com> - 2025-07-03 10:40 +0200
    Re: Feature idea: show upstream release dates on packages Dan Ritter <dsr@randomstring.org> - 2025-07-03 15:10 +0200
      Re: Feature idea: show upstream release dates on packages Gregory Seidman <gsslist+debian@anthropohedron.net> - 2025-07-03 16:20 +0200
      Re: Feature idea: show upstream release dates on packages Borden <borden_c@tutanota.com> - 2025-07-04 06:20 +0200
    Re: Feature idea: show upstream release dates on packages David Wright <deblis@lionunicorn.co.uk> - 2025-07-03 16:40 +0200
    Re: Feature idea: show upstream release dates on packages "Jonathan Dowland" <jmtd@debian.org> - 2025-07-03 19:00 +0200
      Re: Feature idea: show upstream release dates on packages David Wright <deblis@lionunicorn.co.uk> - 2025-07-03 19:40 +0200
        Re: Feature idea: show upstream release dates on packages "Jonathan Dowland" <jmtd@debian.org> - 2025-07-04 22:40 +0200

#280547 — Feature idea: show upstream release dates on packages

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?

[toc] | [next] | [standalone]

#280553

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-

[toc] | [prev] | [next] | [standalone]

#280554

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

[toc] | [prev] | [next] | [standalone]

#280569

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.

[toc] | [prev] | [next] | [standalone]

#280556

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.

[toc] | [prev] | [next] | [standalone]

#280560

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
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#280562

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.

[toc] | [prev] | [next] | [standalone]

#280573

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
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web