Skip to content

/ macports-ports

Permalink
Browse files
Loading status checks…

poppler: update to 0.76.0

  • Loading branch information
@cjones051073
cjones051073 committed Apr 29, 2019
Verified
This commit was signed with a verified signature.
cjones051073 Chris Jones
GPG key ID: 80CE1DC78DAB03DE Learn about signing commits
1 parent 9ef12b8 commit 86546aa0f4d8301db551c237bfc045df4435942b
Unified Split
Showing with 4 additions and 4 deletions.
  1. +4 −4 graphics/poppler/Portfile
8 graphics/poppler/Portfile
View file
@@ -10,7 +10,7 @@ PortGroup legacysupport 1.0

name poppler
conflicts xpdf-tools
version 0.75.0
version 0.76.0
license GPL-2+
maintainers {devans @dbevans} openmaintainer
categories graphics
@@ -24,9 +24,9 @@ master_sites ${homepage}

use_xz yes

checksums rmd160 60ed070dbe125f76c387324ba58e0a750ea7f8b1 \
sha256 3bbaedb0fa2797cac933a0659d144303e4d09eec6892c65600da987d8707199a \
size 1523872
checksums rmd160 312e7a9038f3fe91124b2b5e8acc40ceda82afcc \
sha256 370f5fcfe2bbf0c76fc394d338cd72ed7f2044b67f4eb4b115eb074ccfc70d63 \
size 1530264

depends_build-append \
port:pkgconfig

9 comments on commit 86546aa

@reneeotten

This comment has been minimized.

Sign in to view
Copy link
Contributor

@reneeotten reneeotten replied Apr 29, 2019 •
edited

in the past, most of the poppler updates also included revbumps of at least some ports that depend on it - is that not needed this time?
@cjones051073

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

@cjones051073 cjones051073 replied Apr 29, 2019

It would be useful if this info was in the port file, to let people like myself who occasionally do causal openmaintainer updates know this....

I did not see any issues though, at least none of the ports have installed have complained yet....
@dbevans

This comment has been minimized.

Sign in to view
Copy link
Contributor

@dbevans dbevans replied Apr 29, 2019 •
edited

The poppler dependents that need rebuilding are the ones that link with the low-level core library, libpoppler whose version is almost always (but not always) incremented on updates. Most ports use the higher level libraries whose version remains relatively stable over time. But with new ports coming
and going all the time, the ports needing a rebuild vary from time to time. My suggested procedure
is to install all dependents of poppler using the old version and then see what rev-upgrade reports
after upgrading to the new version. This will also show up any ports that will no longer build due to API changes (relatively frequent with the low-level library).

As with any openmaintainer upgrade, if you don't know enough about a port to understand the consequences of updating it, then you probably should leave it to the maintainer.
@dbevans

This comment has been minimized.

Sign in to view
Copy link
Contributor

@dbevans dbevans replied Apr 29, 2019

Ports that built with poppler 0.75.0 that now, at a minimum, need rebuilding with poppler 0.76.0 are

diff-pdf
extractpdfmark
inkscape
inkscape-devel
inkscape-gtk3-devel
pdf2djvu
scribus-devel (but not scribus)

I'm rebuilding them now to see if there are any other issues that need to be addressed.
@dbevans

This comment has been minimized.

Sign in to view
Copy link
Contributor

@dbevans dbevans replied Apr 30, 2019 •
edited

All of these are broken with 0.76.0. Will see what the issues are tomorrow.. Next time lets do a PR and work out the issues before merging.
@cjones051073

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

@cjones051073 cjones051073 replied Apr 30, 2019

Please can you put a comment then in the port file explaining the above. Openmaintainer allows members to make 'minor' version bumps to ports, and in my view 0.75 -> 0.76 is a minor version number change. Now, if poppler devs do things like change their API on such version changes, then indeed this is not a minor change. However, just looking at the portfile there is no indication of this.

I am not trying to be argumentative here, and I apologies for the problems the update caused. I am just saying for the vast majority of ports a version update like the one here is perfectly fine and causes no issues. poppler , it seems, is different to most so a comment in the portfile to that affect would be a good idea. I do occasionally scan all the ports I have installed to see if there is any minor version updates I can do under openmaintainer, so I cannot absolutely guarantee without such a comment in the portfile I won't forget this discussion in the future and do this again at some point...
@mojca

This comment has been minimized.

Sign in to view
Copy link
Member

@mojca mojca replied Apr 30, 2019

@cjones051073:

  • Basically any port update would theoretically need to be accompanied by testing and potentially revbumping all the dependencies. Just because the port doesn't have that explicitly mentioned in the Portfile doesn't mean that this shouldn't be done. Admittedly plenty of developers don't do this. I certainly never tried to build all of the 1000+ ports when perl bugfix version changes (I'm mentioning this extreme just because it's the most obvious one of my ports with lots of dependencies; the upstream policy is strictly not to break perl, so I'm usually confident that it's safe).
  • Changing the first significant number in version certainly doesn't count as "minor version bump" to me. I'm also pretty sure that upgrading root6 from 6.0 to 6.16 (which is just a few minor version bumps ahead) is not really painless, in particular not if you want to deal with older systems. Qt "minor" version bumps are also problematic enough that they always necessarily break anything but the latest two OS versions.
  • I agree that our definition of openmaintainer policy is confusing, but it was written back in times when subversion was used, and now with pull request I do find one reason less for committing openmaintainer ports directly. It is potentially problematic if developers do "minor version upgrades" without even opening a pull request and give the developer at least a short chance to hit the merge button or provide a reason for not merging the code.
  • poppler is widely known as a super problematic piece of software, for anyone who follows at least a tiny bit. I'm not aware of any single update that would not break a great deal of ports. TeX Live will get rid of it in the near future, as it's so painful to work with and maintain software, in particular when you want to support old systems.

@dbevans: I believe it would make perfect sense to remove the openmaintainer policy from poppler.
@michaelld

This comment has been minimized.

Sign in to view
Copy link
Contributor

@michaelld michaelld replied Apr 30, 2019

Unrelated but since we're having a discussion anyway: In my initial testing / log verification (OSX 10.14 and 10.6), Poppler no longer requires the self-conflict for building. It builds cleanly, and the log shows that all headers and libraries are ordered correctly: internal-to-build first then external-to-build. I'll keep testing / verifying on other OSX as I do updates, and if they check out too then I'll do a PR to remove that code chunk from the Portfile.
@cjones051073

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

@cjones051073 cjones051073 replied Apr 30, 2019

@cjones051073:

  • Basically any port update would theoretically need to be accompanied by testing and potentially revbumping all the dependencies. Just because the port doesn't have that explicitly mentioned in the Portfile doesn't mean that this shouldn't be done. Admittedly plenty of developers don't do this. I certainly never tried to build all of the 1000+ ports when perl bugfix version changes (I'm mentioning this extreme just because it's the most obvious one of my ports with lots of dependencies; the upstream policy is strictly not to break perl, so I'm usually confident that it's safe).

I would agree in an ideal work every single port update would be tested against all possible dependants it might have. In the real world its not at all possible for a user to do this themselves ( if we wanted this, it would have to be something down automatically during a PR).

Also, we have to accept we have a limited number of contributors updating ports. If we place far too stringent requirements on what needs to be done for even a 'trivial' update what will happen in practise is no one will make updates any more. We don't want this, so for me the current situation where ports can be updated quickly under openmaintainer is best. even if occasionally mistakes like here happen.

  • Changing the first significant number in version certainly doesn't count as "minor version bump" to me. I'm also pretty sure that upgrading root6 from 6.0 to 6.16 (which is just a few minor version bumps ahead) is not really painless, in particular not if you want to deal with older systems. Qt "minor" version bumps are also problematic enough that they always necessarily break anything but the latest two OS versions.

This is completely subjective. To me, if a package changes its API then that is not something I would expect in a X.N to X.(N+1) update. I would expect that to be a (X+1).0 update. Clearly though, popper devs work under a different policy here..

  • I agree that our definition of openmaintainer policy is confusing, but it was written back in times when subversion was used, and now with pull request I do find one reason less for committing openmaintainer ports directly. It is potentially problematic if developers do "minor version upgrades" without even opening a pull request and give the developer at least a short chance to hit the merge button or provide a reason for not merging the code.

I don't disagree, and I fact raised on the mailing list an idea that all updated should be done this way. This was totally shot down, as people wanted to be free to commit directly. I am therefore just following what is the community agreed policy here....

  • poppler is widely known as a super problematic piece of software, for anyone who follows at least a tiny bit. I'm not aware of any single update that would not break a great deal of ports. TeX Live will get rid of it in the near future, as it's so painful to work with and maintain software, in particular when you want to support old systems.

In this case then, a comment to that affect would be useful in the Portfiles itself.

@dbevans: I believe it would make perfect sense to remove the openmaintainer policy from poppler.

that might also make sense.
Please sign in to comment.
You can’t perform that action at this time.