[SOLVED]Makepkg, tmpfs, and packages that persist after reboot.

Wesman26 · 2015-06-09 18:29:24

Howdy,
I'm making the switch to an SSD for my laptop soon and as such have been reading up on ways to improve longevity in the wiki and eventually got up to this part about compiling in tmpfs. After following this link I found an interesting bit:

Please be reminded that any package compiled in tmpfs will not persist across reboot. Therefore, such packages should be installed consecutively to building or be moved to another (persistent) directory.

Now, I'm a big suckless fan boy; I run dwm, because I haven't found a better window manager for my purposes, st is my default terminal, surf my default browser, and tabbed is useful for all manner of things. My concern here is that I use the abs and makepkg to customize these packages while keeping them up to date, but I can't readily find a way to make their builds persist over reboot if I use tmpfs as suggested in the wiki.

Have I missed something obvious? Or is there a link someone can point me to that will tell me what needs to be done?

Thanks in advance,
--Wes

Last edited by Wesman26 (2015-06-10 01:08:14)

Trilby · 2015-06-09 19:15:28

No you haven't missed anything obvious. There are a few ways to address this so you can have "persistent" builds and build in tmpfs, but I think more importantly there are a few reasons you shouldn't even care to.

1) The protection of an SSD by using tmps for compiling is only with large projects (like building firefox) and even then it's debatable if there is any noteworthy benefit on modern SSDs. As you are using suckless packages, there are not a lot of source and intermediate files for the compile.

2) The need for persistent compiles is pretty much non-existent for suckless packages. Your dwm *installation* will be persistent, you'll just loose the intermediate build files. But if you update to a new dwm source from git or a new release and/or you change your config.h, then there are no intermediate build files that will remain unchanged: so the benefit of the persisitent build folder is completely non existent.

So, for these cases (dwm, dmenu, st, and other small packages) either just keep your config.h and PKGBUILD somewhere, and build them in tmpfs each time you want to rebuild and lose the intermediate files (no loss). Or, just build them in place outside of tmpfs and miss the "protection" of your SSD (no loss).

But if you really do want to have your cake and eat it to, just sync your build folder into tmpfs (even just cp -a) then build, then sync back. But frankly, for small projects like suckless's, this copy-out and copy-back-in might produce more SSD read/writes than just building in place anyways.

EDIT: for context, I have an SSD, and I don't worry about much of any of that stuff on that wiki page. I build my aur packages in tmpfs, but I did this before I had an SSD. I build my own projects in ~/code/* where they live on the SSD. Modern SSDs are far more robust than the first incarnations of them, so a lot of this tweaking just for an SSD is not just pointless (trim/discard may be an exception that is still valuable).

Wesman26 · 2015-06-10 02:16:32

So what I'm hearing is that for any manner of modern SSD there's nothing really that needs to be tweaked to enhance longevity, except maybe the discard flag in fstab. Am I right in that assumption? Is there a reason you build your aur packages in tmpfs (aside from faster compile times)?

Sorry for being clueless, I've never used an SSD.

Trilby · 2015-06-10 02:26:31

That is what you are hearing from me. Whether I am correct, however, is a fair question. I am confident that the concerns you raise in this thread are of no consequence either way: your SSD is not at any risk due to building packages outside of tmpfs.

I build aur packages that I'm installing in tmpfs simply because I have no desire to keep the leftovers around, but that's just me. By the time I rebuild them to update them, none of the existing files would be of any use - it'd all have to be downloaded again anyways (except, perhaps, for the PKGBUILD for vcs packages).

Arch Linux

#1 2015-06-09 18:29:24

[SOLVED]Makepkg, tmpfs, and packages that persist after reboot.

#2 2015-06-09 19:15:28

Re: [SOLVED]Makepkg, tmpfs, and packages that persist after reboot.

#3 2015-06-10 02:16:32

Re: [SOLVED]Makepkg, tmpfs, and packages that persist after reboot.

#4 2015-06-10 02:26:31

Re: [SOLVED]Makepkg, tmpfs, and packages that persist after reboot.

Board footer