Wandering Thoughts archives


Fedora 18's TexLive packaging failure

Fedora 18's texlive package has a problem. Actually it has at least two problems, one of which makes it our problem. The first problem is that other packages require bits of it to be installed; this is the only reason I have any texlive packages installed. The second problem is that the TexLive package maintainers have chosen to split it up into a truly absurd number of sub-packages. Many of these sub-packages are small, only a few kilobytes (some are below a kilobyte), and some of them are actually empty.

(Other fun things include multiple copies of the GPL, duplicated between various sub-packages. For some packages, the GPL text is the largest single file. Also, some of those empty packages are explicit dependencies of other packages. Why? Who knows.)

Another issue seems to be that texlive's internal dependencies keep creeping around in a way that expands the number of texlive packages installed on your machine over time. My work machine crept up to over a thousand texlive packages, amounting to a fifth of all packages installed on it, and I've seen texlive package updates require additional texlive packages.

This isn't just a problem of massive clutter and its discontents, or of stupid packaging gone absurd. Various yum operations, such as installing package updates, take an amount of time proportional to the amount of packages (no matter how small or empty the package is). Having hundreds of little texlive packages installed thus slows them down drastically; the straw that broke the camel's back on my work machine was a package update that took more than an hour because it was updating over a thousand texlive packages. This elevates texlive's absurd number of sub-packages from merely a bad idea to actively harmful (both because long package update times annoy people and because they encourage people not to update things at all).

I don't know how Fedora allowed things to reach this level of absurdity. But it is absurd and stupid. I've filed a bug about the package count (I didn't discover the other absurdities until now) but to be honest I don't expect anything to change.

(By the way, having this many texlive packages doesn't help people in the least if they want a minimal texlive installation. There are so many packages and they are so absurdly named that I defy anyone who is not deeply immersed in TexLive arcana to figure out what packages they need and what packages they don't.)

I'm sure that the TexLive packagers have some reason for doing all of this; people are rarely crazy. It's just that their reason is a bad one because it has led them into a maze of absurdities. To me this smells of a vastly over-engineered solution, perhaps one put together in the nominal name of efficiency. If so, it has backfired (as these things often do); in a quest for efficiency it has instead created great inefficiency.

linux/FedoraTexliveFailure written at 21:44:52; Add Comment

Why ZFS still needs an equivalent of fsck

One of the things that is more or less a FAQ in ZFS circles is why ZFS doesn't need an equivalent of fsck and why people asking for it are wrong. Unfortunately, the ZFS people making that argument are, in the end, wrong because they have not fully understood the purpose of fsck.

Fsck has two meta-purposes (as opposed to its direct purposes). The obvious one is checking and repairing filesystem consistency when the filesystem gets itself into an inconsistent state due to sudden power failure or the like; this is the traditional Unix use of fsck. As lots of people will tell you, ZFS doesn't need an external tool to do this because it is all built in. ZFS even does traditional fsck one better in that it can safely do the equivalent of periodic precautionary fscks in normal operation, by scrubbing the pool.

(Our ZFS pools are scrubbed regularly and thus are far more solidly intact than traditional filesystems are.)

The less obvious meta-purpose of fsck is putting as much of your filesystem as possible back together when things explode badly. ZFS manifestly needs something to do this job because there are any number of situations today where ZFS will simply throw up its hands and say 'it sucks to be you, I'm done here'. This is not really solvable in ZFS either, because you really can't put this sort of serious recovery mechanisms into the normal kernel filesystem layer; in many cases they would involve going to extreme lengths and violating the guarantees normally provided by ZFS (cf). This means external user-level tools.

(zdb does not qualify here because it is too low-level a tool. The goal of fsck-level tools for disaster recovery is to give you a relatively hands-off experience and zdb is anything but hands-off.)

PS: despite this logic I don't expect ZFS to ever get such a tool. Writing it would be a lot of work, probably would not be popular with ZFS people, and telling people 'restore from your backups' is much simpler and more popular. And if they don't have (current) backups, well, that's not ZFS's problem is it.

(As usual that is the wrong answer.)

solaris/ZFSWhyFsck written at 01:30:08; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.