ldebdiff: what local change did I make to a package?

When fixing or modifying a package I at times change the installed files directly. However, once the changes are okay and it is time to prepare a diff, having to keep track and manually diff'ing the installed files is time consuming.

That's when ldebdiff does its thing: it runs diff against the original files of a given package and the ones installed on a system.
For example:

$ ldebdiff acpi-fakekey
--- unpacked/etc/init.d/acpi-fakekey    2012-04-05 05:14:21.000000000 -0500
+++ /etc/init.d/acpi-fakekey    2012-04-12 12:10:55.000000000 -0500
@@ -4,8 +4,8 @@
 
 ### BEGIN INIT INFO
 # Provides:          acpi-fakekey
-# Required-Start:    $local_fs $remote_fs
-# Required-Stop:     $local_fs $remote_fs
+# Required-Start:    $remote_fs
+# Required-Stop:     $remote_fs
 # Default-Start:     2 3 4 5
 # Default-Stop:      
 # Short-Description: Start acpi_fakekey daemon

($remote_fs implies $local_fs)

Installed-Size: 0

Redefining the meaning of Installed-Size:

Package: gcipher
Version: 1.1-1
Installed-Size: 0

$ dget gcipher=1.1-1
...
$ dpkg -x gcipher_1.1-1_all.deb gcipher
$ du -hs gcipher
188K    gcipher
$ du --apparent-size -hs gcipher
75K     gcipher

On mirrors and why there are so few

Yes, I said few.

Even if in my blog post about Debian's ever-growing mirrors network it seemed like we have a lot of mirrors, truth be told: they are too few. There are many partial or even complete mirrors out there that are not listed.

If you are the administrator of one of those mirrors, please consider submitting your Debian mirror. It helps keep track of them and expose them to more users.

Granted, there are some that due to policies (on remote connections, bandwidth use, etc.) they are kept private. Hidden behind a LAN, hoping that people inside actually use them. As of this time, there's not much that can be done about them. If they were to be listed somewhere, there's no way for somebody to check them from the outside.

Some other mirror networks require that an IP (or a range) be whitelisted, allowing them to access the mirrors from the outside to perform routine checks. For some reason, I thought Fedora's was one of them but, apparently, they use a different approach: they ask private mirrors to run a tool.

I think that each approach has its pros and cons.

An ever-growing mirrors network

As of the time of writing, Debian's mirrors network has around 330 mirrors serving the archive over http, and around 300 serving it over ftp.

This month alone, 6 more mirrors were added. Other 6 more were added last month.

There are mirrors in 73 countries. All this couldn't be possible without the help of the sponsors.

However, some interesting questions arise: do people actually use those new mirrors? is having so many mirrors worth the extra load put on the primary mirrors?

I would personally answer: no, and maybe.

Blogosphere: When was the last time you took a look at the mirrors list and/or tried to find a mirror that served you better?

Your APT caching proxy is not that efficient

So you read about an "APT caching proxy" and that it can "save time and network bandwidth."
Sounds like something you should have, right? After all, the trade-off is just some additional disk space. APT already has its own cache at /var/cache/apt/archives/, so part of what the caching proxy would store in disk is already there.

Truth is, for a single client a caching proxy might not provide any benefit and might even cause a slowdown, but for at least one of the alternatives it is even worse: every request that goes through the proxy that requires a download from a mirror creates a new connection.

It is 2012 and a piece of software that aims to "save time and network bandwidth" can't even use keep-alive connections?

You are doing it wrong...

... when you join a team and then every other team member stops working.

(There's a possibility that you are doing such a great job that there's no need of the others, but think about the case when your work or your way of working is killing them.)

the bash way is faster, but only with bash

Some bashisms are syntax sugar at first sight, such as the += concatenation syntax. Usually, they happen to be faster than their more portable counterparts. But only with bash itself.

Take the following script as an example:

#!/bin/sh
# script1-portable.sh
part="$(seq 1 100000)"

for i in $(seq 1 10); do
seq="${part}"
seq="${seq}${part}"
done

$ time bash script1-portable.sh
user 0m20.837s

Now, compare to the following script that uses += :

#!/bin/sh
# script1-bash.sh
part="$(seq 1 100000)"

for i in $(seq 1 10); do
seq="${part}"
seq+="${part}"
done

$ time bash script1-bash.sh
user 0m14.227s

Yes, it's faster. However, when the first script is run with dash:

$ time dash script1-portable.sh
user    0m0.609s

[[ is another example:

#!/bin/sh
# script2-portable.sh
a="$(seq 1 100000)"; b="$(seq 1 100)"

for i in $(seq 1 10); do
[ "$a" = "$b" ]
done

$ time bash script2-portable.sh
user    0m9.148s

And the version using the bashism:

#!/bin/sh
# script2-bash.sh
a="$(seq 1 100000)"; b="$(seq 1 100)"

for i in $(seq 1 10); do
[[ $a = $b ]]
done

$ time bash script2-bash.sh
user    0m4.223s

Then again, the bash way is faster, yet it doesn't compare to dash:

$ time dash script2-portable.sh
user    0m0.588s