Sharing Programs in a Dropbox Folder

garchws · 2015-11-04 22:12:12

I am currently storing config files in a dropbox folder (i.e., things like keyboard shortcuts). The problem is that these keyboard shortcuts depend on certain programs to work (like xmodmap, xev, xcave, etc), and I intend for multiple computers to use these shortcuts that might not have these programs installed. My idea is to put the compiled programs into a bin (inside dropbox) that all computers that have access to the Dropbox can access. Is this possible? Would it be better to store the binaries, or the file packages together so that they could be compiled for each particular computer locally? One idea is to set `pacman --cachedir <dropbox_dir>` for each of these packages, which would allow somebody else to recursively use their own pacman to install all of the dependencies on their own local machine. Would this approach work?

respiranto · 2015-11-04 22:46:25

Why don't you simply maintain a list of packages in your dropbox folder, which will be used by pacman to install the packages if necessary?
You could also store a simple shell script which does so.

Storing the binaries or packages (1) somewhere will most likely lead to problems, unless you sync these files regularly from one of the mirrors, i.e. maintain your own small mirror.
Installing these packages / files would be more or less like a partial upgrade, which is not supported in Arch.

By the way, instead of `pacman --cachedir <dropbox_dir>` you would better use simply `pacman -U <dropbox_dir>/<needed-pkgs>'.

1) Assuming you are talking of Arch packages, they are also containing binaries, thus don't require any compiling.

ayekat · 2015-11-04 22:52:28

I would also rather use git to synchronise configuration files among multiple machines. This way you avoid having to use Dropbox.

You can take a look at one of the bazillions of git repositories that are stored on all sorts of git hosting platforms (Github, Bitbucket, ...) to get some examples.

For binaries... what respiranto wrote.

Last edited by ayekat (2015-11-04 22:53:27)

garchws · 2015-11-04 22:54:03

Respiranto, when you say "Why don't you simply maintain a list of packages in your dropbox folder, which will be used by pacman to install the packages if necessary?", what do you mean?

Do you mean have a text file that has a bunch of lines like

pacman -S vim
pacman -S firefox

Or something else?

respiranto · 2015-11-04 23:18:32

No, I mean a file which contains nothing but the package names, separated by newlines, or spaces if you prefer that.
You could then use it as follows:

for pkg in `cat "$file"`
do
	test pacman -Qq "$pkg" > /dev/null 2>&1 || pacman -S "$pkg"
done

garchws · 2015-11-04 23:24:03

Ok. Is there a way to take an existing Arch installation and "back into" such a file? Basically, provide a list of all installed packages that another person could use to essentially clone a machine?

respiranto · 2015-11-04 23:28:22

`pacman -Q` or - to keep it shorter: `pacman -Qe`.
You might also want to exclude the base group and maybe some others from the list, which could be achieved by using e.g. grep, sed or awk, knowing the command `pacman -Qgq`.

See also pacman(8).

Last edited by respiranto (2015-11-04 23:29:05)

Trilby · 2015-11-04 23:31:11

respiranto, that whole loop with the double pacman for each package and all could be replaced with a single pacman command:

pacman -Syu --needed $(cat file)

And to generate a list:

pacman -Qetq > file

Also, -Qe doesn't just keep the list shorter than -Q, but it keeps from breaking the installation reason.

jasonwryan · 2015-11-04 23:35:32

respiranto wrote:

while IFS= read -r pkg; do
    test pacman -Qq "$pkg" > /dev/null 2>&1 || pacman -S "$pkg"
done < file

Fixed that for you...

garchws · 2015-11-05 01:46:38

The command `pacman -Qetq` yields packages that I -- as far as I recall -- I *didn't* install with pacman (in some cases I installed them with yaourt).

Is this is the expected behavior? If so, how does pacman know about those packages?

jasonwryan · 2015-11-05 01:55:25

You really need to read up on how Yaourt actually works...

ayekat · 2015-11-05 08:48:17

Yes, the `-Q` switch makes pacman apply searches on the local database (a.k.a. the installed packages). By default it doesn't care where the packages came from, since it is not important.

You can, however, filter out packages that are not found in the sync database (a.k.a. installed with `pacman -U`):

pacman (8) wrote:

-n, --native
Restrict or filter output to packages that are found in the sync database(s). This is the inverse filter of --foreign.

respiranto · 2015-11-05 13:44:21

jasonwryan wrote:

respiranto wrote:

while IFS= read -r pkg; do
    test pacman -Qq "$pkg" > /dev/null 2>&1 || pacman -S "$pkg"
done < file

Fixed that for you...

Thank you, I have never really learned to use bash properly, I am mostly just learning by doing.

Shouldn't $IFS also work with its default value $'\n\t '?
Of course this assumes that the user has not set a custom $IFS which, as I think, doesn't make much sense to do globally, since probably some programs depend on its default behavior resp. value.

Trilby wrote:

And to generate a list:
pacman -Qetq > file

Using -t is problematic, since it will not list explicitly installed packages, which are optional dependencies of another installed package, thus it would not be installed when the list is parsed by pacman. Using -t twice, i.e. -tt, does circumvent this issue, as it only omits packages which are non-optional dependencies of another installed package.
However, I think using -t at all is not a good idea, because, in my opinion, the relevant information of such a file should be what I did explicitly install, not what is necessary to get all the same packages on another system.
Furthermore, by using -t{,t}, the database on the new system would be different, i.e. when removing a package with -Rs, which another one is a dependency of, the latter will be removed as well, although it was explicitly installed on the old system.

Trilby wrote:

Also, -Qe doesn't just keep the list shorter than -Q, but it keeps from breaking the installation reason.

By keeping the list shorter, I meant keeping the actual number of lines in the file small. Of course I forgot -q, but that's not relevant.
Keeping the installation reason is of course a valid point, which I forgot to mention, however, as I said above, is also a reason against using -t.

Last edited by respiranto (2015-11-05 13:44:55)

Trilby · 2015-11-05 14:54:50

You are indeed right about -t, that should not be used in this case.

Arch Linux

#1 2015-11-04 22:12:12

Sharing Programs in a Dropbox Folder

#2 2015-11-04 22:46:25

Re: Sharing Programs in a Dropbox Folder

#3 2015-11-04 22:52:28

Re: Sharing Programs in a Dropbox Folder

#4 2015-11-04 22:54:03

Re: Sharing Programs in a Dropbox Folder

#5 2015-11-04 23:18:32

Re: Sharing Programs in a Dropbox Folder

#6 2015-11-04 23:24:03

Re: Sharing Programs in a Dropbox Folder

#7 2015-11-04 23:28:22

Re: Sharing Programs in a Dropbox Folder

#8 2015-11-04 23:31:11

Re: Sharing Programs in a Dropbox Folder

#9 2015-11-04 23:35:32

Re: Sharing Programs in a Dropbox Folder

#10 2015-11-05 01:46:38

Re: Sharing Programs in a Dropbox Folder

#11 2015-11-05 01:55:25

Re: Sharing Programs in a Dropbox Folder

#12 2015-11-05 08:48:17

Re: Sharing Programs in a Dropbox Folder

#13 2015-11-05 13:44:21

Re: Sharing Programs in a Dropbox Folder

#14 2015-11-05 14:54:50

Re: Sharing Programs in a Dropbox Folder

Board footer