toast: Challenging my spongy pink organic brain

My difficulty in understanding stow was trying to figure out why I would want to set up an array of symlinks pointing to a central location. My difficulty in understanding toast is … a little different.

I’ll give you a screenshot this time, but it won’t help much.

toast, as I understand it, should act as a packaging envelope, downloading, compiling and “installing” software in a centralized location. So that much already sounds like stow, but toast apparently bills itself as a solution to local or non-system-wide software installations.

It’s an interesting idea; in theory, it could allow you to install software or specific versions at individual locations, and make them usable to a discrete user. I suppose it would also allow an administrator to pull down an updated (or obsolete) version and install it in lieu of a distro’s official release.

Since toast handles the bundling and installation more or less automatically, it also means you aren’t arbitrarily scattering files across your system tree without a unified and safe way to remove them. I hate to say it, but I do occassionally turn my nose up at software with no more instructions than sudo make install, because I know I’ll find fragments of that package months later, hiding in /opt/lib/local or some dumb place like that.

So yes, in theory, I’m a fan.

But my cursory adventures with toast were less than promising. About four out of every five packages I tried to “install” with toast were unreachable, and I was picking some heavy-hitters, not obscure stuff. perl was accessible, but python wasn’t, and neither was htop or util-linux. Those are some rather glaring omissions.

An added complication: coreutils was available, but wouldn’t build correctly. Which means that technically speaking, toast wasn’t doing much better than I might, if I had to build software manually and forcibly install it locally. Unfortunately toast is no guarantee that you’ll get a working package, if you get anything at all.

I see that there are add and change commands for toast, and it may be that I should be editing the locations of updated versions to toast, to access those missing titles. But I also see that toast is relying on sites like Freecode — now defunct — as some sort of index of software. And given that the most recent version of toast is already more than two years old, it might be that a toasty update is needed before it will do what it’s supposed to do.

So in short, I personally suspect toast’s age is interfering with its ability to find and build titles. And toast isn’t necessarily any better at building that software than I am, meaning my spongy pink organic brain might have a better chance of troubleshooting (“Oh, well, that’s not working because I don’t have GLU installed. Aha! Yer about to be boarded … ! Har har!“) than toast.

Given those shortcomings, my difficulty in understanding toast is … why not just jump into a cutting edge distro like Arch with AUR, or Debian Sid, or just micromanage your software, like Crux and some others? I am afraid my spongy pink organic brain is befuddled by this. … 😦

stow: Not just for package management any more

GNU stow is another one of those projects that took me a while to wrap my head around, but once I saw it in action, it made perfect sense. Of course, given that stow doesn’t really show any output, that statement is ironic on another level.

As I understand it, stow is intended as a kind of package manager for software you might build locally — which in my case, is quite a lot. stow works by creating symlinks from a program’s original location to a central depot of your creation.

The idea is that this reduces the chances of unforeseen conflicts, and makes managing random, scattered files easier, since most everything is in the same place. One program, one folder, and appropriate symlinks elsewhere in the system.

If that doesn’t make a lot of sense, don’t worry, because two hours before I wrote this, I was trying to wrap my head around it too. Now though, I think I see the value in it.

What clued me in was this post by Brandon Invergo, where he talks about creating a folder specifically for dotfiles with stow. Brandon is an easy read and he gives you a good visual illustration, so don’t worry if you’re not a fan of reading from blogs. Neither am I (ironic, isn’t it?).

If you step through his post, you’ll end up with a small tree of folders with the dotfiles of each program nested individually. Your home folder will still hold links to those files, and everything will still work as it should. So don’t panic. 😉

I tested it with two programs that I thought more or less bulletproof, even if my configurations were utterly vaporized: htop and snownews. And after Brandon’s instructions, wouldn’t you know it, everything worked fine.

Why would I want to do this? Well, like Brandon explains, this makes it much cleaner to synchronize your dotfiles against an online repository — for example, you can more conveniently dump your dotfiles on github. No more cherrypicking files and sending them singly.

But personally, I usually have a lump of folders and settings that I transfer between machines, to expedite setup or testing. Even just in the past two or three days, I’ve ended up manually copying files from one machine to another, and from that machine to a third. In the future, I expect I can install stow, rsync the dotfiles folder to the new machine and jump right in.

I suppose you could do this manually, file by file and link by link, and not need stow. But just thinking about that should make it obvious why stow is a good tool: Manually setting up all those links would be tedious to say the least.

I have the reassurance of Brandon and some other sites that even if you uninstall stow, your link systems will continue to work. That makes sense to me, even if I haven’t taken that step yet.

stow has the potential to be a game changer for you, if you need that kind of added flexibility with packages or with your personal configuration files. It won’t clean up your home directory — you’ll end up with just as many symlinks as you had configuration files, and in the same place — but it adds a layer of convenience that you might find immediately attractive.

yaourt: In the interest of parity

For someone who uses Arch Linux on almost every machine that passes through my hands, I seem to have spent a lot of time looking through Debian-based tools. Perhaps that’s a hint of my subconscious affiliation. …

Out of fairness, I’ll mention yaourt today. I know there are a lot of add-ons and frontends to the venerable pacman, but I’m a yaourt user for a couple of simple reasons.

The first is color. No, just kidding. 😉 The first is congruency: With very few exceptions that I know of, yaourt is almost command-for-command a match with pacman. Of course there are a few embellishments here and there, but I haven’t found anything yet that makes one or the other terrifically uncomfortable.

The second is transparency: What I really want as a bump up from pacman, is the ability to mesh cleanly with the AUR for searches and installation. I’m comfortable at this point in my Linux experience with installing “unsupported” software in Arch, and I’m generally clever enough to spot a malformed PKGBUILD and kick it into a working state. The only thing pacman lacks is the ability (permission?) to continue its searches and installs with the AUR.

But that’s enough about that. I think using yaourt puts me into a minority of Arch users. But it’s hard to tell because there are quite a few tools that embellish or boost pacman, and I know of no survey that sets us all into our individual camps.

To be honest, I’d prefer it stay that way. We’re all on the same team, whether you’re in with yaourt or pacman, Arch or Debian. One thing the world needs is a little less division. 😉

one: Another attempt at unification

Odd that one would come up in the rotation today, but I’m comfortable with that. If you remember kkm or wajig, you might appreciate what one hopes to accomplish — solidify the package management task in Debian to a single command. 😯

I don’t have a screenshot for you, because I suspect a successful screenshot of one would show … dpkg or aptitude or apt-get or apt-cache or what have you, doing what it usually does. Terrifically uninteresting.

one defaults to installing a package, meaning just one rsync should pull down rsync and install it. Simple enough.

After that, the default commands become one- or two- (or sometimes three-) letter mnemonics for whatever procedure you’re trying to accomplish. Ergo, s for search, i for details (or info), o for ownership, and so on.

Personally I have no compunction about using a tool like one, or wajig or kkm, to be clear. I occasionally find myself frustrated by having five or six separate tools available on a Debian system, when there is just pacman on my other computers.

I leave it to you to decide if something like one (or kkm or wajig, of course) is a good thing or a bad thing for the overall Debian structure. I am content to rely on Debian as a solid foundation distro, and permit each user the leeway to use unifying tools as they see fit.

And in case you’re keeping count, there are almost as many unification efforts now as there are tools to unify on a Debian system. How’s that for irony? 😆

whohas: A good idea, in theory

After all these years of scooping manually through individual repos to see which distro carries what software, you’d think something like whohas would really enthuse me.

But unfortunately it doesn’t. The idea sounds good, but it doesn’t seem to follow through.

whohas is a multi-distro search tool. It searches through a long list of Linux and BSD repositories and returns links to packages or results pages. Ideally, it would be wonderful for someone like me.

Unfortunately, the difficulty (I imagine) in maintaining something like this, is that you have to keep up with all the dozens of search tools and their respective eccentricities. If AUR, for example, suddenly decides to move to a new host, or even just tweaks its search address, and suddenly your multi-distro info retrieval tool is handicapped.

That seems to be the case with whohas. The documentation suggests whohas should support Arch, Debian, Fedora, Gentoo, Mandriva, openSUSE and a lot more, but I get results from maybe two of the 15 total available. And the rest are … missing, I guess I should say.

The git page for whohas shows attention within the last nine months, at the time of this writing. All the same, I don’t see much from Arch or Debian, which are the two I try to align myself with.

If whohas can support your distro or something that you occasionally jump to, then perhaps you’ll get more use from it than I did. As it stands for me, it was a good idea, but only in theory. 😦

wajig: Unite the clans!

Back to Linux Mint for this one. If you’re not using something Debian-ish, it probably won’t work for you … let alone appeal to you.

I haven’t been shy in the past, in critiquing Debian’s rather scattered approach to package handling. Between dpkg, apt-get, aptitude and apt-cache, with the added complications of things like debsums, deborphan and host of other tools, things get a little frazzled.

I understand most of the fragmented structure and the reasons for it, but I can also tell you that comparing those dozen programs to pacman is night-and-day.

If I had to pick a single tool to unify them, wajig would be my weapon of choice. wajig — look here if you have to know about the name right now — consolidates most of the tools I’ve already mentioned, and collates their individual commands into a master list.

Don’t worry, you don’t have to relearn new commands; most are grandfathered into wajig. So apt-get install appears as wajig install, and apt-cache search appears as wajig search. Convenient.

wajig also liases with some ancillary programs like deborphans and debsums, as I mentioned above. Remember if you want to take advantage of those features in wajig, you’ll need to install the programs that actually do those chores. wajig doesn’t doesn’t reinvent the wheel, it just makes it easier to spin it.

wajig does a few other things right — like an onboard tutorial, or a full list of commands and their descriptions. No color, but you can’t have everything.

If you’re serious about Debian and you frown on things that tamper with the delicate default ecosystem, then perhaps wajig isn’t for you. On the other hand, if you’ve stepped outside that walled garden and seen, for example, how Arch does things, wajig might be a much more appealing way to do business.

Just for my own part, I expect I’ll be installing it on the next Debian-based machine I build. I’m not so much a purist as to turn my nose up at convenience. … 😉

pkgfile: And pacman, for Archers only

Surprisingly, pacman was not on my list, but pkgfile is. I thought about looping back to the start of the P section, to get pacman in. After all, Debian users shouldn’t get all the attention.

But I think I can swoop through both in one quick shot. There’s very little that I can offer in the way of advice for either of them, which is probably good.

And most Archers are clever enough not to rely on me for advice with either, but instead to make their way to the most excellent Linux wiki in the universe, the Arch Linux wiki.

The best use I can offer for pkgfile is to skim through packages — even ones you don’t have installed — and check for program ownership. That’s not a big deal until you are scraping around looking for a lousy one-shot line application, and can’t seem to pin it down.

So even if an app doesn’t stand on its own, you have a way to locate a specific command.

As for pacman … what could I say that would possibly be useful? I think I shall just leave you with my favorite pacman trick: finding orphans.

pacman -Qqtd

Nothing innovative or original there; in fact I think I found that online some years ago. Probably on the wiki. 😕

kkm: For Debian fans with a wild streak

I felt a little bad that the earlier post about kbd didn’t really pull in the Debian crowd too, so I’ve got kkm here to keep you interested.

As I understand it, kkm is a wrapper to simplify apt-get and aptitude, and whether or not you like it will probably depend on your level of satisfaction with the traditional Debian commands.

And seeing as most of the Debian fans I know are fairly loyal to apt* and company, kkm might be a hard sell.

But if you’re both a Debian follower and a bit of a wild child, then this might work well for you.

Personally I see no fault in it, but I am a regular yaourt user … for much the same reasons that form the rationale for kkm. pacman is genius, I don’t deny that. But yaourt bridges the gap between pacman and AUR. 😈

If kkm can pull off the same stunt between apt-cache, apt-get and aptitude … well, you see where we’re going.

Anyway, no screenshot this time — my Debian machine is offline with hardware adjustments. You’ll have to install kkm and see what it looks like for yourself.

And then tell us what you think. Let’s see how many swirlies we can convert, shall we? And how many cling fiercely to aptitude‘s built-in minesweeper game. 😉

P.S.: Updated only days ago. … 🙂

Bonus: D is for Debian

About six months ago I scoured an ancient Debian package-a-day web site for all its fruit (with bew, if you must know), and came up with a long list of applications … some text-only, some graphical.

The graphical stuff has been going to the Package of the Day subreddit, and the rest I kept for future reference.

One side effect of that scouring (not necessarily good or bad) was that there was a huge crop of Debian-specific stuff. And of course, almost all of it starts with D.

So here’s a quick rundown on a few things that you can take advantage of, but really only if you’re using Debian or a derivative.

• alien: Like deb2targz, which I just mentioned, alien will convert .deb packages to tar.gz format.
  
  

  It will though, also convert to rpm, slp, LSB and even Solaris format. It can patch on-the-fly, incorporate scripts into packages and a lot more. deb2targz is good, but if you use Debian anyway, you should probably grab alien instead.

• debian-goodies: dpkg, aptitude, apt-cache and apt-get always satisfied almost every need I had in Debian, but debian-goodies adds a lot more tools to the mix.
  
  

  Some of the coolest? debget, which bypasses aptitude and company to yank just a package off the repository. And dpigs, which shows which packages are hogging space. 😉

• dh-make-perl: I know next to nothing about perl or Debian packaging, but if I understand the description correctly, this should be a help with both.
  
  

  I leave it to you to pick up the torch on that one.

• deborphan: deborphan has been around forever, and it’s one of the first things I used to install whenever I worked with either Debian or Ubuntu.
  
  

  deborphan skillfully skims through lost or detached packages on your system and lists them as orphans. It makes it quite easy to recover space after a mess of installations, or to check for leftover crud. (By the way, Arch users have something similar in pacman -Qqtd … you’re welcome. 😉 )

• dlocate: Again, if I understand the description and the help flags, dlocate amplifies some of the search functions of dpkg.
  
  

  It’s more than just a replacement for dpkg -S though, as you can see above. Check the help flag; it’s got a ton of features.

• discover-config: I have this on my list as a hardware check system, but it seems unwieldy and I’m not sure if it’s meant to be used beyond boot scripts.
  
  

  It works sure enough, but I might just be mishandling it. The package page and man pages might give more information.

• dwww: I’ll mention just one more, and I don’t have a screenshot because I couldn’t figure out how to get it working. dwww, as all the program descriptions and man pages suggest, allows you to peruse documentation with a browser. I tried for a little bit but got no love from it. If there is a howto out there for setting it up, send me a link. I’m curious.

That’s enough from the Debian pond now. If you’re not a Debian fan, you probably found this excruciating to start with, but if you have any swirly in your bloodstream you might find something fun to mess with there.

We now return you to your regularly scheduled blog. 😉

deb2targz: Crossing the streams

I mentioned a long time ago that I occasionally fall back on deb2targz when I’m checking out little programs here and there.

In my case, there are times when, for example, a program won’t build in Arch, but it’s available precompiled in the Debian repositories.

For times like that, deb2targz shunts the .deb file to a tar.gz, which can be used in Arch as well as a few other distros too.

deb2targz only does one thing. It doesn’t take any switches that I can see. It doesn’t have a man page that I could find. And aside from the information on the home page, that’s all the guidance you get.

On the other hand, I’ve never had a problem with it, and “sparse” doesn’t mean “non-functional.”

For the record, I don’t bother actually installing the tar.gz file. Decompressing it and ripping out the binary is usually as close as I get.

If that works, it works. If not, I have a few other tricks up my sleeve. 😈

And yes, I know about alien. What do you think is next?