Package Details: libtiff4 3.9.7-4

Git Clone URL: (read-only)
Package Base: libtiff3
Description: Library for manipulation of TIFF images (legacy version, provides
Upstream URL:
Keywords: image legacy library
Licenses: custom
Submitter: rafaelff
Maintainer: smls
Last Packager: smls
Votes: 84
Popularity: 0.338058
First Submitted: 2012-02-07 01:20
Last Updated: 2015-09-11 04:42

Latest Comments

smls commented on 2015-09-11 04:44

libtiff3 and libtiff4 are now a split package.

(Also, I cleaned up the PKGBUILD based on Scimmia's suggestions.)

Scimmia commented on 2015-08-21 14:07

Er, that's 5 and 4 lines, not 4 and 3.

Scimmia commented on 2015-08-21 14:06

In addition to the tips mentioned for libtiff3

We are now guaranteed to start in $srcdir, so your initial `cd "${srcdir}/tiff-${pkgver}"` can just be `cd tiff-${pkgver}`

Just like mkdir or install, rm can take multiple arguments. `rm -rf ${pkgdir}/usr/bin` & `rm -rf ${pkgdir}/usr/include` can just be `rm -rf ${pkgdir}/usr/bin ${pkgdir}/usr/include`, or better yet, use brace expansion: `rm -rf ${pkgdir}/usr/{bin,include}`. I see you've done this when removing the libraries, I would combine them all into one rm command, spanning multiple lines to keep things straight.

Don't forget quotes anytime you use a path with $pkgdir and $srcdir.

Scimmia commented on 2015-08-21 13:55

Some tips for simplifying the PKGBUILD. This is currently the symlink package, so I'll comment about that specifically.

!libtool is the default, there's no need to specify it.

`mkdir usr` & `mkdir usr/lib` can simply be `mkdir -p usr/lib`. You can also specify more than one dir at a time, so `mkdir -p usr/lib usr/share/licenses` can replace 4 command. Personally, I prefer `install -d` for this instead of `mkdir -p`; it can be used the same way with multiple dirs specified and additionally allows you to specify permissions.

There's no need to `cd` to the dir to just make a symlink or two. `ln -s libtiff4 usr/share/licenses/libtiff3` works just as well.

Put them together, and the entire package function could be 4 lines. Could even be 3 if you eliminate the initial `cd "${pkgdir}"`, but that's probably not worth it since you'd have to specify it on every subsequent line.

Toost_Inc commented on 2015-08-21 01:59

The seperate libtiff3 and libtiff4 packages are a giant mess of conflicting files and dependency circles, even though they provide exactly the same package.
Seeing as you now maintain both packages, you should you really try to merge them into one package.

I'll file a merge request in a bit, but I took the liberty of making a patch[1], which you can easily download and apply using `git apply merge-libtiff4-libtiff3.patch`.


smls commented on 2015-08-13 14:51

Re-added libtiff4.

smls commented on 2015-08-13 02:49

huh, libtiff4 used to exist a short while ago. I guess it fell victim to the latest purge of orphan packages?

cmlr commented on 2015-08-13 00:52

libtiff4 no longer exists in AUR, it shouldn't be a dependency.

mrueg commented on 2014-09-07 11:03

I had the same issue as m45t3r. Even including the rm line at various places in the PKGBuild didn't help.

I only got libtiff3 to install after manually removing the offending files between the install of libtiff4 and libtiff3. (I had to use sudo for that, fyi.)

rafaelff commented on 2013-06-29 12:28

@m45t3r: I'm sorry, but wasn't able to reproduce your problem with

It seems like you did not set a command to remove and in your PKGBUILD, so they will be included indeed in the resulting package.

Try adding the following (somewhere after 'cd ${pkgdir}/usr/lib/'):
# Remove version 3, this is supplied by libtiff3 package
rm -f

p.s.: please always add double quotes (") around every ${pkgdir} or ${srcdir}.

m45t3r commented on 2013-06-28 03:57

I am the maintainer of libtiff4 and I am having some problems to provide only When I try to delete the symlink to it doesn't appear on the package but it still appears on filesystem linked to (yeah, I know, crazy right?).

So I am thinking to merge these two packages (maybe renaming it to libtiff-legacy or something like that) and provides both and, since this would make maintaining it easier (my package uses the lastest libtiff from 3.9 series) and would solve my problem (for now, I am providing the too, but this may be confusing to some users).

As for why we need, some programs depend on it, even if it isn't a official decision of upstream (seems it was something invented by Debian guys). So basically binary programs that are compiled for Debian system (and maybe Fedora too, but I can't confirm) needs it.

rafaelff commented on 2013-02-28 00:41

Thanks, typo fixed.

KanocX commented on 2013-02-27 15:34

There is a small typo in your dependencies... Please replace the "ligbl" with "libgl" ;)

rafaelff commented on 2013-02-27 04:02

You're correct, so I reverted it. Thanks for the warning.

ShyPixie commented on 2013-02-27 02:29

Why do not you just use 'libgl' (instead of mesa-libgl) in makedepends? This satisfies all needs in all cases.

mesa-libgl provides libgl
nvidia-304xx-utils provides libgl
nvidia-utils provides libgl
catalyst-utils provides libgl

rafaelff commented on 2012-09-18 22:55

nvidia-utils provides libgl. It means that if you replace libgl with nvidia-utils, the "libgl" dependency will be satisfied.

rafaelff commented on 2012-09-18 22:20

nvidia-utils provides libgl. It means that if you replace libgl with nvidia-utils, the "libgl" dependency will be satisfied.

Denommus commented on 2012-09-18 22:12

This package needs libgl, but it conflicts with nvidia-utils. I want the proprietary nvidia drivers, so I can't install uplink-hib.

rafaelff commented on 2012-02-07 01:23

This legacy package was created as a workaround to deal with PCSX2 0.9.8 needs. Other users might simply want to install libtiff (currently version 4.0.0) from [extra] repository.