Bug 242287 - sysutils/ufetch: Minor tweaks to Makefile and bump to latest commit
Summary: sysutils/ufetch: Minor tweaks to Makefile and bump to latest commit
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords: buildisok
Depends on:
Blocks:
 
Reported: 2019-11-28 20:44 UTC by Lewis Cook
Modified: 2019-12-09 09:28 UTC (History)
1 user (show)

See Also:


Attachments
Updated port patch (1.40 KB, patch)
2019-11-28 20:44 UTC, Lewis Cook
vulcan: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Lewis Cook 2019-11-28 20:44:16 UTC
Created attachment 209516 [details]
Updated port patch

In the initial port submission, DISTVERSION was incorrectly set (rather, needed to use the date of the commit instead to avoid confusion). This is now remedied in the patch, updated to the latest commit and bumped both PORTREVISION and PORTEPOCH (plus corresponding distinfo). Also made a few minor tweaks to the Makefile for clarity.
Comment 1 Automation User 2019-11-28 20:48:53 UTC
Build info is available at https://gitlab.com/swills/freebsd-ports/pipelines/99330817
Comment 2 Koichiro Iwao freebsd_committer 2019-12-09 09:15:52 UTC
I think bumping PORTEPOCH is enough but am not really sure.
Comment 3 Lewis Cook 2019-12-09 09:28:06 UTC
(In reply to Koichiro Iwao from comment #2)

Thanks for your response. I've been referring to the porters handbook in this particular instance, and more specifically it's noted:

> People using binary packages will never see the update if PORTREVISION is not bumped. Without increasing PORTREVISION, the package builders have no way to detect the change and thus, will not rebuild the package.

As we're changing the DISTVERSION to 'g20191028' when it was previously '0.1-1', (from what I've read) there could be a potential issue where it's not seen as an update, but rather a downgrade in version. Which lead to me bumping both of the values avoiding any conflict―forcing a rebuild of the package and prompting users of a new update.

Although I'm not 100% certain if this is completely necessary. If a change is needed I'm more than happy to do so. Cheers!