#20135 closed update (fixed)
file-4.26: update to 5.03
| Reported by: | boeyms@… | Owned by: | nerdling (Jeremy Lavergne) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.7.1 |
| Keywords: | Cc: | jay-macports@… | |
| Port: | file |
Description
file has been updated to version 5.03; attached is a Portfile patch to perform this update. It performs the following:
- updates the version and revision numbers;
- updates the checksums;
- updates the homepage; and
- removes
patch-src-file.h.diffsince it has been incorporated into file-5.03.
Additionally, have the other three patches in the files directory (patch-lzma.diff, patch-magic-Magdir-msdos.diff and patch-magic-Makefile.in.diff) been submitted upstream? If not, they might like to hear about them.
Attachments (1)
Change History (9)
Changed 15 years ago by boeyms@…
| Attachment: | file_4.26_to_5.03.diff added |
|---|
comment:1 Changed 15 years ago by tobypeterson
comment:2 Changed 15 years ago by blb@…
I'm guessing it's similar to the same idea with coreutils etc, though file isn't gnu so that doesn't make sense; I don't see having file in ${prefix}/bin overriding the one in /usr/bin as being anywhere near as dangerous as what coreutils provides...
comment:3 Changed 15 years ago by tobypeterson
The only real difference is that /usr/bin/file handles universal binaries to some extent.
comment:4 follow-up: 8 Changed 15 years ago by jay-macports@…
I'm not a big fan of the program-prefix either, but I'm not sure what the MacPorts rules are for when it's OK to override a built-in binary. Anyone know?
As for the patches - I remember thinking that I should do that when I took over the port, but I have no evidence that I actually did it. I have a vague recollection of deciding that some or all were obsolete. I'll take a closer look this weekend, and get these patches pushed. I think the lzma patch was for a "future" file format that never actually made it into the wild...
comment:5 Changed 15 years ago by nerdling (Jeremy Lavergne)
| Cc: | jay-macports@… added |
|---|---|
| Owner: | changed from jay-macports@… to snc@… |
| Status: | new → assigned |
It seems that LZMA support is already added, which is handled by patch-lzma.diff
comment:6 Changed 15 years ago by nerdling (Jeremy Lavergne)
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Committed in r54772. Also removed LZMA patch. Timeout.
comment:7 Changed 15 years ago by nerdling (Jeremy Lavergne)
I also went with Toby's advice that the program-prefix be dropped. I further added a note to the port description indicating that the missing functionality can be achieved via otool.
comment:8 Changed 15 years ago by afb@…
Replying to jay-macports@…:
I think the lzma patch was for a "future" file format that never actually made it into the wild...
The lzma patch was added upstream, just that "new LZMA" was renamed to XZ. See http://tukaani.org/xz/
Can we also reconsider the bizarre "--program-prefix=g" option? I don't really understand what that's supposed to accomplish. :(