Page MenuHomeFreeBSD

print/ghostscript9-agpl-*: Remove expired ports
ClosedPublic

Authored by michaelo on Oct 27 2023, 9:47 AM.
Tags
None
Referenced Files
F106663286: D42376.diff
Fri, Jan 3, 2:13 PM
Unknown Object (File)
Tue, Dec 24, 11:44 PM
Unknown Object (File)
Fri, Dec 6, 11:43 AM
Unknown Object (File)
Dec 1 2024, 8:48 AM
Unknown Object (File)
Dec 1 2024, 8:48 AM
Unknown Object (File)
Dec 1 2024, 8:48 AM
Unknown Object (File)
Dec 1 2024, 8:48 AM
Unknown Object (File)
Dec 1 2024, 8:48 AM
Subscribers

Details

Summary

2023-12-31 print/ghostscript9-agpl-base: Obsolete and unsupported upstream, consider using print/ghostscipt10
2023-12-31 print/ghostscript9-agpl-x11: Obsolete and unsupported upstream, consider using print/ghostscipt10

PR: 274751
Approved by: jrm (mentor), otis (mentor), maintainer timeout

Diff Detail

Repository
R11 FreeBSD ports repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 54188
Build 51078: arc lint + arc unit

Event Timeline

michaelo created this revision.

To be applied only by the end of the year...

There is a file Mk/bsd.default-versions.mk which mentions the possible values as:

# Possible values: 9, agpl, 10
GHOSTSCRIPT_DEFAULT?=   agpl

This also should be updated to reflect the changes.

In D42376#967046, @bofh wrote:

There is a file Mk/bsd.default-versions.mk which mentions the possible values as:

# Possible values: 9, agpl, 10
GHOSTSCRIPT_DEFAULT?=   agpl

This also should be updated to reflect the changes.

Good catch, addressed.

Thanks. If I am not mistaken you had a bug report where you marked this as DEPRECATED and set the EXPIRATION_DATE? Did you commit it?

Normally what happens is portmgr@ takes care of the deletion when they ar marked DEPRECATED/EXPIRATION_DATE.

In D42376#967057, @bofh wrote:

Thanks. If I am not mistaken you had a bug report where you marked this as DEPRECATED and set the EXPIRATION_DATE? Did you commit it?

Yes, here it is: https://github.com/freebsd/freebsd-ports/commit/bfd5ec44d9c34a70439334bf6f90eebe0cc11c3f

Normally what happens is portmgr@ takes care of the deletion when they ar marked DEPRECATED/EXPIRATION_DATE.

Should this be closed and put this on shoulders of portmgr@? I am fine with either.

If it was on a different date I would have let you do that as a practice during your mentorship.

But on this same date we have to remove the entire 12.X support and there are already a gazillions of ports to be removed. So I would say please put it on the shoulder of portmgr@ for now. I already have staged the entire removal of 12 and all of the removal of ports.

But as a practice and to to prove to your mentor that you really know about it pick up a port which is marked as deletion in the recent times and commit with Approved by: <one of mentor> portmgr (blanket). grep ^EXPIRATION and grep 2023-10 is your assistant.

michaelo retitled this revision from cleanup: Remove expired Ghostscript 9 ports: to print/ghostscript9-agpl-*: Remove expired ports.Oct 27 2023, 4:11 PM
In D42376#967059, @bofh wrote:

If it was on a different date I would have let you do that as a practice during your mentorship.

But on this same date we have to remove the entire 12.X support and there are already a gazillions of ports to be removed. So I would say please put it on the shoulder of portmgr@ for now. I already have staged the entire removal of 12 and all of the removal of ports.

Is that a typo? Did you mean really to say "put" or "put not"?

But as a practice and to to prove to your mentor that you really know about it pick up a port which is marked as deletion in the recent times and commit with Approved by: <one of mentor> portmgr (blanket). grep ^EXPIRATION and grep 2023-10 is your assistant.

I am not fully sure I understood your message. I have updated the commit message according to the grep results. Is that what you were looking for?

Is that a typo? Did you mean really to say "put" or "put not"?

No it was not a typo. I requested you to put it on portmgr@ shoulder. Normally the end of the quarterly dates are a bit rough as there are lots of changes specially deletes. And often it's prone to mistakes specially git rebasing properly.

I am not fully sure I understood your message. I have updated the commit message according to the grep results. Is that what you were looking for?

Hence I requested you to pick a port and delete which is not on the end of the quarterly dates but are on more recent dates. An easy way to find such port is:

find . -type f -name Makefile -d 3 -exec grep -E '^EXPIRATION_DATE.*2023-10' {} \+
In D42376#967104, @bofh wrote:

Is that a typo? Did you mean really to say "put" or "put not"?

No it was not a typo. I requested you to put it on portmgr@ shoulder. Normally the end of the quarterly dates are a bit rough as there are lots of changes specially deletes. And often it's prone to mistakes specially git rebasing properly.

Alright, I actually assumed that you wanted me to lift it off your shoulders to reduce work. Nevermind.

I am not fully sure I understood your message. I have updated the commit message according to the grep results. Is that what you were looking for?

Hence I requested you to pick a port and delete which is not on the end of the quarterly dates but are on more recent dates. An easy way to find such port is:

find . -type f -name Makefile -d 3 -exec grep -E '^EXPIRATION_DATE.*2023-10' {} \+

Alright, I will take a peek at this next week.

In D42376#967059, @bofh wrote:

If it was on a different date I would have let you do that as a practice during your mentorship.

But on this same date we have to remove the entire 12.X support and there are already a gazillions of ports to be removed. So I would say please put it on the shoulder of portmgr@ for now. I already have staged the entire removal of 12 and all of the removal of ports.

But as a practice and to to prove to your mentor that you really know about it pick up a port which is marked as deletion in the recent times and commit with Approved by: <one of mentor> portmgr (blanket). grep ^EXPIRATION and grep 2023-10 is your assistant.

Better use make -V EXPIRATION_DATE instead of manual grepping, which might get things wrong in corner cases.

I think my comments has not been too descriptive or were in details or there were too many jargons. So just to clarify in details.

  • You do not need portmgr approval to mark a port DEPRECATED
    • Use your own judgement to do so
    • If the port is maintained by someone else use Approved by: portmgr (blanket)
    • Ask yourself whether if the port is EOL upstream?
    • Ask yourself whether if the port is BROKEN on all supported versions for a long time
    • Ask yourself whether if the port is unmaintained by upstream and if there is a modern alternative
    • Ask yourself whether if the port is dependent on legacy technologies which are also marked for deletion(like MySQL 5.7, or Node16, or qt5-webkit)
  • You do not need portmgr approval to remove a port which is marked DEPRECATED and has an EXPIRATION_DATE. You can delete the port on the EXPIRATION_DATE please mark your timezone. It's safe to delete or remove after UTC 0000.
  • The reason I requested you not to delete this specific case
    • The end date of a supported version is dirty as there are lots of changes
    • The end date of a quarterly is also dirty as lots of removal takes place
    • As newcomer there is a chance of making mistakes with git rebase/merge conflicts and everything
    • I do not want a newcomer to wear a pointy hat during their mentorship and get frustrated or receive flames from others
    • Everyone will say to use rmport which is not too ideal for this specific case as there will be squashing involved for removing two different ports and also amending
  • The reason I requested you to pick up another port for deletion which are more recent like from 2023-10 or 2023-11
    • There are always some ports to delete(Mostly every week)
    • It's safer for a newcomer also as there are not too much rebase/conflicts involved
    • It gives you the same experience of removing a port but with lot less stress

I hope my description explains the reasons behind my rationale thinking. But feel free to defer my thought process. :)

This revision was not accepted when it landed; it landed in state Needs Review.Dec 31 2023, 12:08 AM
This revision was automatically updated to reflect the committed changes.