[aur-requests] [PRQ#3918] Merge Request for libtiff4
Toost_Inc [1] filed a request to merge libtiff4 [2] into libtiff3 [3]: Both packages essentially provide the same libraries, with one depending on another but using another symlink (`libtiff.so.4` instead of `libtiff.so.3`), which could be easily added to the other package. It's quite a mess, creates weird dependency circles and has conflicting files to to top it off. I've created a patch [*], that will solve this problem, which I've also posted in the comments of the libtiff3 package. [*] https://gist.github.com/ToostInc/e94039b0d077d8251965 [1] https://aur.archlinux.org/account/Toost_Inc/ [2] https://aur.archlinux.org/pkgbase/libtiff4/ [3] https://aur.archlinux.org/pkgbase/libtiff3/
On Fri, 21 Aug 2015 02:09:09 +0000 (UTC) notify@aur.archlinux.org wrote:
Toost_Inc [1] filed a request to merge libtiff4 [2] into libtiff3 [3]:
Both packages essentially provide the same libraries, with one depending on another but using another symlink (`libtiff.so.4` instead of `libtiff.so.3`), which could be easily added to the other package.
It's quite a mess, creates weird dependency circles and has conflicting files to to top it off.
I've created a patch [*], that will solve this problem, which I've also posted in the comments of the libtiff3 package.
[*] https://gist.github.com/ToostInc/e94039b0d077d8251965
[1] https://aur.archlinux.org/account/Toost_Inc/ [2] https://aur.archlinux.org/pkgbase/libtiff4/ [3] https://aur.archlinux.org/pkgbase/libtiff3/
I think they're fine separate, but I would do it the other way around. Make libtiff3 the main package (since that's the upstream soname), then make a separate libtiff4 package that just has the symlinks and nothing else. There's a lot of other simplification I would do, as well, but it should work as-is. Doug
As the current maintainer of both packages, I'm not convinced that merging them is a good idea. Having them separate, makes it easier for people to specify what soname exactly they need without having to worry about implementation details like which is a symlink etc. In an ideal world it could be a single package that provides=(libtiff3 libtiff4) so that other packages could continue to list either of them in their 'depends' array. But afaik, the AUR API and AUR helpers don't support that. On the other hand, Doug's suggestion does make sense to me: On Fri, Aug 21, 2015 at 5:06 AM, Doug Newgard <scimmia@archlinux.info> wrote:
Make libtiff3 the main package (since that's the upstream soname), then make a separate libtiff4 package that just has the symlinks and nothing else. There's a lot of other simplification I would do, as well, but it should work as-is.
I'll await the outcome of this merge request; if they stay separate I'll probably go ahead and do that. Also, can you elaborate on those other simplifications? (Maybe on the package comment page rather than here.)
On Fri, 21 Aug 2015 12:20:57 +0200 "Sam S." <smls75@gmail.com> wrote:
On Fri, Aug 21, 2015 at 5:06 AM, Doug Newgard <scimmia@archlinux.info> wrote:
Make libtiff3 the main package (since that's the upstream soname), then make a separate libtiff4 package that just has the symlinks and nothing else. There's a lot of other simplification I would do, as well, but it should work as-is.
I'll await the outcome of this merge request; if they stay separate I'll probably go ahead and do that. Also, can you elaborate on those other simplifications? (Maybe on the package comment page rather than here.)
Sure, I'll post there. Another thing you could consider is making them a split PKGBUILD. Both packages would be built with a single PKGBUILD. This might satisfy Toost_Inc, and would reduce maintenance for you, even though these probably don't require much maintenance. Doug
On Fri, Aug 21, 2015 at 3:45 PM, Doug Newgard <scimmia@archlinux.info> wrote:
Another thing you could consider is making them a split PKGBUILD. Both packages would be built with a single PKGBUILD.
Could downstream packages specify either libtiff3 or libtiff34 in their 'depends', or would they have to specify the pkgbase of the split package? I'd like to avoid the latter.
On Fri, 21 Aug 2015 22:06:06 +0200 "Sam S." <smls75@gmail.com> wrote:
On Fri, Aug 21, 2015 at 3:45 PM, Doug Newgard <scimmia@archlinux.info> wrote:
Another thing you could consider is making them a split PKGBUILD. Both packages would be built with a single PKGBUILD.
Could downstream packages specify either libtiff3 or libtiff34 in their 'depends', or would they have to specify the pkgbase of the split package? I'd like to avoid the latter.
Each package is treated separately, so packages could depend on libtiff3 or libtiff4 just the same as if they were separate PKGBUILDs.
OK, I'll make them a split package then. Not sure what this means for this merge request, will it need to be accepted so I can upload the split package as libtiff3?
Yeah, looks like I can't push the split package as long as libtiff4 exists separately: remote: error: cannot overwrite package: libtiff4 remote: error: hook declined to update refs/heads/master To ssh://aur@aur4.archlinux.org/libtiff3.git ! [remote rejected] master -> master (hook declined) Someone please accept this merge request then... :)
Ping... Btw, here's the split PKGBUILD I plan to upload to libtiff3 once the packages have been merged, in case someone wants to look it over while we wait: https://gist.github.com/smls/ac07a165b2f8b3829043
On 27/08, Sam S. wrote:
Ping...
Btw, here's the split PKGBUILD I plan to upload to libtiff3 once the packages have been merged, in case someone wants to look it over while we wait: https://gist.github.com/smls/ac07a165b2f8b3829043
Sorry for the delay, package has been merged now. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
Request #3918 has been accepted by Kyrias [1]. [1] https://aur.archlinux.org/account/Kyrias/
participants (4)
-
Doug Newgard
-
Johannes Löthberg
-
notify＠aur.archlinux.org
-
Sam S.