Package Details: sxiv-git 2015.01.05.g47e6cd0-1

Git Clone URL: https://aur.archlinux.org/sxiv-git.git (read-only)
Package Base: sxiv-git
Description: Simple (or small or suckless) X Image Viewer
Upstream URL: https://github.com/muennich/sxiv
Licenses: GPL2
Conflicts: sxiv
Provides: sxiv
Submitter: None
Maintainer: jasonwryan
Last Packager: jasonwryan
Votes: 30
Popularity: 0.715973
First Submitted: 2011-01-23 13:55
Last Updated: 2015-06-08 09:42

Dependencies (4)

Required by (3)

Sources (1)

Latest Comments

mkoskar commented on 2014-10-24 11:25

@jasonwryan: I see, I've missed that info in man page. Good to know. Ok no problem, I maintain my clone anyway because of 'config.h', just wanted to minimize tweaks I do. Still though, I'm wondering if there is another, more suitable way how to do this. Probably is not very common use case. Thanks ;)

jasonwryan commented on 2014-10-24 09:27

@mkoskar given that $startdir is deprecated and its use "strongly discouraged" (man pkgbuild), I am inclined to leave things as they are for the time being. I agree it is not ideal, but it sucks the least, as far as I can tell.

mkoskar commented on 2014-10-24 07:54

@jasonwryan: Sorry for late response ... I don't think there are any advantages per se, but if you think of it SRCDEST doesn't make sense here really I believe, because the 'config.h' in this case is not a 'source' file (otherwise it would be listed in source array). In fact it's a kind of trick when build "depends" on something outside of regular sources (which normally shouldn't be the case). So we can either pretend it's a source and say packager has to ensure to copy it into SRCDEST (or $srcdir in that case is more correct), or we say it's not source at all and rather it is something living somewhere else. I've suggested BUILDDIR because it was working for me, but realized it can be changed too an it is probably frequent use-case? I've did some testing now, and found out that regardless where SRCDEST and BUILDDIR are pointing $startdir always points to original location from which `makepkg` is run, so I think it is reasonable and justified to use $startdir here. It could be that there is some better solution to this though ;).

jasonwryan commented on 2014-10-18 06:55

@mkoskar What advantage is there to preferring BUILDDIR over SRCDEST (apart from in your case)? The VCS guidelines seem to prefer the former: https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines#VCS_sources

mkoskar commented on 2014-10-16 18:32

@jasonwryan: I've found out that $SRCDEST doesn't work for me since I have set it to point to global cache directory. Figured out that $BUILDDIR is want we want. If you fancy you can grab fixed version ($SRCDEST -> $BUILDDIR, + removing some trailing whitespace) from <https://raw.githubusercontent.com/mkoskar/pkgbuilds/master/sxiv-git/PKGBUILD>. Thanks!

jasonwryan commented on 2014-10-12 06:53

Thanks sekret. I'm going to leave things as they are for the time being; I appreciate the suggestions, but unless there is something particularly broken about this approach, I see no compelling reason to change it.

sekret commented on 2014-10-10 21:24

An even better way to handle the config.h (in my opinion) is e.g. https://aur.archlinux.org/packages/ra/ratox-git/PKGBUILD
I put the config.h into the sources, BUT
1. made the checksum being skipped
2. made a custom config.h to be opted in

That way those of you who don't want to customize anything in the config.h, the package will always work and the only disadvantage is that you have to download that file when getting the sources from here. VERY small disadvantage! ;)

For those of you who DO use a custom config.h, all you have to do is remove the # in the prepare function and of course keep your config.h up to date by yourself.

Why not just search for the config.h in $SRCDEST? Well, this can be set to a different location in /etc/makepkg.conf which e.g. I do, I'm sure many others as well. For those of you who don't do that, give it some thought, it really makes sense. This means that in case of a custom SRCDEST you would have to have all your config.h files (from dwm, sxiv, $(other suckless projects) ) in $SRCDEST, which we all know is impossible, since the filename is the same for all of them.


I know this is something to be debated about, but since this above described method was suggested by devs in the comments of some package here in the AUR (sorry for not being able to find it right now..) I think it's worth mentioning.


One other thing, I want to suggest to use

git describe --long --tags | sed -r 's/^v//;s/([^-]*-g)/r\1/;s/-/./g'

in the pkgver function. Using the date is nice to see how active the project is, but the real info lies in the above command.


Ok that was a lot now! All just suggestions!

jasonwryan commented on 2014-10-10 20:19

@mkoskar: yes, you are right. I have updated the PKGBUILD. Cheers.

mkoskar commented on 2014-10-10 12:06

I think it would make more sense to not distribute `config.h` in the package (meaning as a 'source'). `prepare` would just copy one if you happen to have it in your source directory, if not some message could be emitted. As of now the `config.h` is outdated, which is expected since this is 'development' package. But then that may (and does) lead to compile errors.

quite commented on 2014-08-02 14:34

Okay, that was a change upstream. -a is now needed to play on start

All comments