Package Details: relink 1.2-1

Git Clone URL: (read-only, click to copy)
Package Base: relink
Description: A simple utility that modifies your symlinks
Upstream URL:
Licenses: GPL3
Submitter: maandree
Maintainer: maandree
Last Packager: maandree
Votes: 2
Popularity: 0.000000
First Submitted: 2014-04-30 17:14 (UTC)
Last Updated: 2015-12-01 06:13 (UTC)

Latest Comments

XG_SiNGH commented on 2015-10-18 21:44 (UTC)

build() fails for me :( ... mv: cannot move ‘’ to ‘bin/’: No such file or directory ... Aborting... O_O

TrialnError commented on 2015-04-11 11:53 (UTC)

Not sure if I can follow your explanation why it's not bad to include it to both arrays Generating/compiling those packages via makepkg will pull the stuff from depends, then makedepends (+ additionally checkdepends). So you get all the deps. The difference is just, what will be installed if you install the generated pkg.tar.xz (The things from depends and if you want to some things from optdepends, the reason why makedepends exist. Just for really makedepends like tex2html or whatever for generating docs or to provide features that are optdepends but need to be there while compiling)

maandree commented on 2015-04-08 02:09 (UTC)

I have added to my todo list to unlist base and base-devel packages. I think it should be listed in both arrays because it should be possible to precompile packages and distribute binary copies of them without pulling in all runtime dependencies. So it is theoretical functional reason why I do this. Concerning dep:s of dep:s, which many packages omit. I think it is important because an outer dep. can change its dep:s or be provided by another package with different dep:s.

TrialnError commented on 2015-04-08 01:50 (UTC)

Well in case of the base/base-devel thing. The two wiki pages I listed before are the Guidelines and preferred and the Warning Field in the Prerequisites states to not include them. Splattered across the MLs and Bugtracker are messages about this (one example, although from 08 this answer from the devs didn't change ). About the multiple mentions in the various depends arrays. Not sure if it's written down explicitly. I thought it were in the Guidelines and maybe back then it was there. So it seems to be user choice. My point would be that unnecessary redundancy should be avoided, since everything listed in depends will be pulled when the package is built, so it's already "makedepends". And you have your reason to include this information, because it leaves no room for interpretation or uncertainness.

maandree commented on 2015-04-08 00:18 (UTC)

@TrialnError I know, but I prefer to have all dependencies explicitly listed. So I will include base and base-devel packages, add runtime dep:s to make dep:s if they are needed during build too, and packages used directly by the source even if they are a dependency of an dependency. If there is any functional reason, or documented convention (that it is preferred, not just that people tend) not to, I will fix this for my packages.

TrialnError commented on 2015-04-08 00:03 (UTC)

One note for this PKGBuild, but it is fitting also for blueshift, dooble and every else that does the following. You add to makedepends coreutils and/or make and possible some more that are from the base and base-devel group. But a requirement for AUR is that base and base-devel are installed and those packages shouldn't be added in the depends arrays Also if something is a runtime dep it's sufficient to add it to the depends array. Additional adding to makedepends don't yield any benefit (just if this thing is optional, but needed while compiling) So coreutils, make and texinfo could be removed from makedepends and coreutils from depends for this PKGBuild, since all those are from base and base-devel