Creating a Trusted Local Repository from which Software Updates can be installed.

[Geochelone]

luvr, thank you You are correct, I missed that part. Once I changed Release to $L1, it worked as expected. Thanks!

[luvr]

The Problem.

After you created your local repository, you keep updating it by copying ever newer package versions into it. The old versions of the packages, however, never get removed from the repository. As a result, whenever you regenerate its index file, you get tons of warning messages such as the following:

 ! Package firefox-3.0 (filename ./firefox-3.0_3.0.8+nobinonly-0ubuntu0.8.10.2_i386.deb) is repeat but newer version;
   used that one and ignored data from ./firefox-3.0_3.0.5+nobinonly-0ubuntu0.8.10.1_i386.deb !
 ! Package firefox-gnome-support (filename ./firefox-gnome-support_3.0.7+nobinonly-0ubuntu0.8.10.1_all.deb) is repeat;
   ignored that one and using data from ./firefox-gnome-support_3.0.8+nobinonly-0ubuntu0.8.10.2_all.deb !

In this post, I present a quick'n'dirty hack to allow you to remove the old packages from the repository, in order to eliminate these warnings. As an added benefit, your repository will get cleaned up, and the space that was taken up by the old packages will be freed up.

A Fair Warning.

The hack that I present here seems to work, but I developed it as a patch to the ”dpkg-scanpackages” Perl script, which, admittedly, I hardly understand. I simply searched for the places where the script generated the warning messages, and inserted what I assume to be the appropriate print statements in what I assume to be the appropriate places. In addition, I deleted quite a bit of code from the end of the script, because it seemed to be unnecessary for my purposes.

I did test my patched script on my simple repository, and it works fine there; I don't know, however, if it would work equally well on a complex repository. Try it at your own risk!

A Warning about debmirror.

Warning:

If you use debmirror to maintain a local repository, then you really should not perform any manual maintenance on your local copy.

Note:

For information on the use of debmirror, see "How to make your own Ubuntu Repository DVDs," posted by BobSongs.

The online repositories will generally keep a number of old package versions available for a while. If you manually delete these, and you subsequently run debmirror to bring your local repository up-to-date again, then debmirror will notice that they are missing from your local copy, and redownload them (since it wants to bring your local repository fully in sync with the online version).

You should really leave it up to debmirror to maintain your local repository; once the old package versions are removed from the online repository, the next time you run debmirror, they will be deleted from your local repository as well.

(Thanks to Geochelone for reporting this issue--cfr. Post #18 in this thread.)

Preparing for the Patch.

The ”dpkg-scanpackages” Perl script, which I used as the basis for my patch, should be located in your /usr/bin directory. I didn't, of course, want to mess with this existing script, so I decided to create a copy under a new name, and hack that copy. I used ”gen-deloldpackages” as the name for my patched script; if you want to apply the patch as I attached it to this post, you will have to create your copy under the same name—e.g., in your home directory—with the following commands:

cd
cp /usr/bin/dpkg-scanpackages gen-deloldpackages

Note:

I developed the patch on version 1.14.20ubuntu1 of the "dpkg-scanpackages" script under Ubuntu 8.10 ("the Intrepid Ibex")—which is apparently identical to version 1.14.24ubuntu1 of the script under Ubuntu 9.04 ("the Jaunty Jackalope"). If you use any other version of the script, then the patch may or may not work right.
To verify the "dpkg-scanpackages" version on your system, you can simply run the following command:

dpkg-scanpackages --version

If you're running Ubuntu 8.10, the output should look like this:

Debian dpkg-scanpackages version 1.14.20ubuntu1.

Under Ubuntu 9.04, on the other hand, the output should look like this:

Debian dpkg-scanpackages version 1.14.24ubuntu1.

Applying the Patch.

Download the ”patch_gen-deloldpackages.zip” file attached to this post. Save it into your home directory (or wherever you created the ”gen-deloldpackages” file in the first place), and run the following command to unzip it:

unzip patch_gen-deloldpackages.zip

This will create the ”patch_gen-deloldpackages” file—which you can use to apply the patch, as follows:

patch < patch_gen-deloldpackages

Just to be sure, you may want to verify that the patched script file is executable—i.e., that you can run it as a shell command; to this end, enter the following command:

ls -l gen-deloldpackages

The output should look something like this:

-rwxr-xr-x 1 luvr luvr 6588 2009-04-18 23:38 gen-deloldpackages

In particular, the three ”x” characters that I highlighted in the output should be present; if they aren't, then you should use the folllowing command to set them:

chmod +x gen-deloldpackages

Then, rerun the ”ls” command, above, to be absolutely, positively sure.

Testing the Patched Script.

The patched script works somewhat similar to the original, ”dpkg-scanpackages,” except that it won't actually create a new index file. To test it, enter the directory in which you set up your local repository, and run the folllowing command:

~/gen-deloldpackages . /dev/null

Note:

The ”~/” that are prepended to the name of the script, indicate that the file is located in your home directory. If you stored the script in any other location, you will have to modify the path accordingly.

You should see the very same warnings that you got from the ”dpkg-scanpackages” command, but every warning should be followed by a line that begins with ”rm”—e.g.:

 ! Package firefox-3.0 (filename ./firefox-3.0_3.0.8+nobinonly-0ubuntu0.8.10.2_i386.deb) is repeat but newer version;
   used that one and ignored data from ./firefox-3.0_3.0.5+nobinonly-0ubuntu0.8.10.1_i386.deb !
rm './firefox-3.0_3.0.5+nobinonly-0ubuntu0.8.10.1_i386.deb'
 ! Package firefox-gnome-support (filename ./firefox-gnome-support_3.0.7+nobinonly-0ubuntu0.8.10.1_all.deb) is repeat;
   ignored that one and using data from ./firefox-gnome-support_3.0.8+nobinonly-0ubuntu0.8.10.2_all.deb !
rm './firefox-gnome-support_3.0.7+nobinonly-0ubuntu0.8.10.1_all.deb'

The ”rm” lines are the commands to remove the old packages; if you want to execute the script for real, you will want to catch these lines into a genuine file, and execute that as a shell script—as described next.

Executing the Patched Script for Real.

The ”rm” lines that the patched script generates, are output to the ”standard output” stream, while the warning messages go to ”standard error.” Thus, if you redirect ”standard output” to a file, these ”rm” lines will go there, while the warnings will still be displayed on screen—e.g., the following command will send the ”rm” lines to a file named ”deloldpkgs”:

~/gen-deloldpackages . /dev/null > deloldpkgs

Note:

If you prefer to suppress the warning messages, then you can additionally redirect ”standard error” to ”/dev/null,” as follows:

~/gen-deloldpackages . /dev/null > deloldpkgs 2> /dev/null

Now that the list of ”remove” commands is present in a file, you will want to run that file in order to actually execute the commands—i.e., to delete the old package files. To that end, you could make the ”deloldpkgs” file executable (just like you may have had to do with the ”gen-deloldpackages” before), and then run it—e.g.:

chmod +x deloldpkgs
./deloldpkgs

As an alternative, though, you could simply ”source” the file into your shell session, using the ”.” (i.e, simply a dot) command, as follows:

. deloldpkgs

Note:

The ”.” (dot) command is really just a shorthand for the ”source” command. The following will, therefore, work equally well:

source deloldpkgs

Either way, once the ”deloldpkgs” file finishes, the old packages should have disappeared from your repository.

Tip:

Instead of writing the list of "remove" commands to an actual file, and subsequently executing them in a separate step, you may pipe the output of the "gen-deloldpackages" into a standard shell, as follows:

~/gen-deloldpackages . /dev/null 2> /dev/null | sh

This combines the generation of the command list, and its subsequent execution, into a single step; as an added bonus, it also eliminates the need for the intermediate file.

[k3lt01]

Hi luvr. I have only just seen this thread after checking BobSongs thread for updates.

If I may make 1 comment on what you are trying to do, with regards to the OP, have you seen this? Apt-Catcher-Server. To me it does exactly what you initially wanted to do. After I finish setting up my home server/network it is what I plan to do.

[luvr]

Apt-Catcher-Server

Thanks for the link--I think I'll look into it for Jaunty, when that is released in a few days.

[j.crilly]

Is it possible to change the default location that Ubuntu stores the deb files from /var/cache/apt/archives/ to say /media/Elements/repos?

This would save copying the files...

[luvr]

Is it possible to change the default location that Ubuntu stores the deb files from /var/cache/apt/archives/ to say /media/Elements/repos?

This would save copying the files...

I'm not sure whether or not there's an option to change the location of the APT cache, but even so, I don't think that it would be a good idea to use that location directly for your local repository. The APT system removes files from its cache from time to time, so you really cannot use it as a reliable repository.

Having said that, copying the files to your local repository can be as simple as running the following command:

cp --update --verbose /var/cache/apt/archives/*.deb /your/local/repository

(which copies only new and updated debian package files to your local repository--you could even abbreviate the "--update" option to "-u" and remove the "--verbose" option, if you want to shorten the command).

Just add this command to the top of the "update-repository" script, and it will be automatically executed whenever you update your local repository.

Note:

I attached an updated version of the "update-repository" script to the original post. It now includes the command to copy the new debian package files to the local repository.

[luvr]

The Problem.

You successfully installed the “Microsoft TrueType core fonts” software package (i.e., “msttcorefonts”) on one computer that has full internet access, and you are making the package available locally—e.g., through a local software repository.

You are now trying to install the package on another computer, but this time with limited or no internet access, e.g., with the following command:

sudo apt-get install msttcorefonts

When the command starts up, it produces the following output:

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  cabextract ttf-liberation ttf-mscorefonts-installer
The following NEW packages will be installed:
  cabextract msttcorefonts ttf-liberation ttf-mscorefonts-installer
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/1101kB of archives.
After this operation, 2159kB of additional disk space will be used.
Do you want to continue [Y/n]?

You notice, specifically, the line that reads “Need to get 0B/1101kB of archives.” From this output line, you draw the conclusion that the software packages will not be downloaded from the internet, but that the files that you want to install, will be taken from your local repository instead.

However, when you continue the operation, you discover that the installer still attempts to download a set of Microsoft Windows executable (“.exe”) files from SourceForge; these downloads will, obviously, fail if the computer does not have an active internet connection—e.g.:

--2009-04-27 15:27:13--  http://surfnet.dl.sourceforge.net/sourceforge/corefonts/andale32.exe
Resolving surfnet.dl.sourceforge.net... failed: Name or service not known.
wget: unable to resolve host address `surfnet.dl.sourceforge.net'
--2009-04-27 15:27:13--  http://mesh.dl.sourceforge.net/sourceforge/corefonts/andale32.exe
Resolving mesh.dl.sourceforge.net... failed: Name or service not known.
wget: unable to resolve host address `mesh.dl.sourceforge.net'
--2009-04-27 15:27:13--  http://dfn.dl.sourceforge.net/sourceforge/corefonts/andale32.exe
Resolving dfn.dl.sourceforge.net... failed: Name or service not known.
wget: unable to resolve host address `dfn.dl.sourceforge.net'
--2009-04-27 15:27:13--  http://heanet.dl.sourceforge.net/sourceforge/corefonts/andale32.exe
Resolving heanet.dl.sourceforge.net... failed: Name or service not known.
wget: unable to resolve host address `heanet.dl.sourceforge.net'
--2009-04-27 15:27:13--  http://jaist.dl.sourceforge.net/sourceforge/corefonts/andale32.exe
Resolving jaist.dl.sourceforge.net... failed: Name or service not known.
wget: unable to resolve host address `jaist.dl.sourceforge.net'
--2009-04-27 15:27:13--  http://nchc.dl.sourceforge.net/sourceforge/corefonts/andale32.exe
Resolving nchc.dl.sourceforge.net... failed: Name or service not known.
wget: unable to resolve host address `nchc.dl.sourceforge.net'
--2009-04-27 15:27:13--  http://ufpr.dl.sourceforge.net/sourceforge/corefonts/andale32.exe
Resolving ufpr.dl.sourceforge.net... failed: Name or service not known.
wget: unable to resolve host address `ufpr.dl.sourceforge.net'
--2009-04-27 15:27:13--  http://internode.dl.sourceforge.net/sourceforge/corefonts/andale32.exe
Resolving internode.dl.sourceforge.net... failed: Name or service not known.
wget: unable to resolve host address `internode.dl.sourceforge.net'
--2009-04-27 15:27:13--  http://mesh.dl.sourceforge.net/sourceforge/corefonts/andale32.exe
Resolving mesh.dl.sourceforge.net... failed: Name or service not known.
wget: unable to resolve host address `mesh.dl.sourceforge.net'
--2009-04-27 15:27:13--  http://voxel.dl.sourceforge.net/sourceforge/corefonts/andale32.exe
Resolving voxel.dl.sourceforge.net... failed: Name or service not known.
wget: unable to resolve host address `voxel.dl.sourceforge.net'
--2009-04-27 15:27:13--  http://kent.dl.sourceforge.net/sourceforge/corefonts/andale32.exe
Resolving kent.dl.sourceforge.net... failed: Name or service not known.
wget: unable to resolve host address `kent.dl.sourceforge.net'
--2009-04-27 15:27:13--  http://internap.dl.sourceforge.net/sourceforge/corefonts/andale32.exe
Resolving internap.dl.sourceforge.net... failed: Name or service not known.
wget: unable to resolve host address `internap.dl.sourceforge.net'
--2009-04-27 15:27:13--  http://switch.dl.sourceforge.net/sourceforge/corefonts/andale32.exe
Resolving switch.dl.sourceforge.net... failed: Name or service not known.
wget: unable to resolve host address `switch.dl.sourceforge.net'

In this post, I will explain why this problem is happening, and how to work around it.

Why is this Problem Happening?

The reason why the Microsoft Windows executable files have to be separately downloaded, is uncovered by a notice that is shown to you when you attempt to install the “msttcorefonts” software package:

These fonts were provided by Microsoft "in the interest of cross-
platform compatibility".  This is no longer the case, but they are
still available from third parties.

You are free to download these fonts and use them for your own use,
but you may not redistribute them in modified form, including changes
to the file name or packaging format.

The key to the problem is the phrase that “you may not redistribute them in modified form, including changes to the file name or packaging format."
In other words, since the files are distributed as “.exe” files, you are not allowed to provide them in any other format. In particular, you should not include them in a Debian (or, for that matter, an RPM) software package. You will, therefore, have to provide them, unchanged, as separate files to any software installation mechanism through which you want to make them available.

What happens to the Files after they are Downloaded?

When you install the “msttcorefonts” software package, and you let it run to completion, it takes roughly the following steps:

• It downloads the Microsoft Windows executable files from SourceForge to a temporary directory on the local computer;
• It extracts the TrueType font definition (“.ttf”) files from the downloaded executables, and saves them into an appropriate permanent location;
• It takes any further actions required to make the newly installed fonts available to the font rendering subsystem, and to mark the package as being successfully installed.

Fortunately, the “msttcorefonts” package has some basic intelligence built into it: Before it decides to download the executables, it will verify if, perhaps, the font definition (“.ttf”) files are already present in the expected permanent location; if it finds the files there, then it will not redownload or reinstall them. To avoid having to download them during the installation of the package, you should, therefore, manually copy them to the appropriate location before you actually install the package.

The remainder of this document will explain how you can copy the font files into a typical archive file, from which you can subsequently retrieve them, very easily and quickly, on any computer on which you want to install them.

Important:

Keep in mind that, according to their usage terms, you are not allowed to distribute the fonts in any form except as the original, unmodified Microsoft Windows executable files. You should not, therefore, send the archive file that you are about to create, to anyone else, but you may explain to them how they can create their own copy of the archive—just as I am doing here.

Step 1: Creating an Archive from the Font Files.

Note:

You should execute this step on a computer on which you have already installed the “Microsoft TrueType core fonts” software package.

When you install the“msttcorefonts” package, the font files will get copied to the “/usr/share/fonts/truetype/msttcorefonts” directory. To verify if they are really there, you can run the following command:

ls -l /usr/share/fonts/truetype/msttcorefonts

You should get a listing like the following:

total 5704
-rw-r--r-- 1 root root 105468 1998-11-12 07:18 Andale_Mono.ttf
lrwxrwxrwx 1 root root     15 2009-02-23 20:04 andalemo.ttf -> Andale_Mono.ttf
lrwxrwxrwx 1 root root     14 2009-02-23 20:04 arialbd.ttf -> Arial_Bold.ttf
lrwxrwxrwx 1 root root     21 2009-02-23 20:04 arialbi.ttf -> Arial_Bold_Italic.ttf
-rw-r--r-- 1 root root 117028 1998-11-10 13:52 Arial_Black.ttf
-rw-r--r-- 1 root root 224692 2000-05-11 11:45 Arial_Bold_Italic.ttf
-rw-r--r-- 1 root root 286620 2000-05-11 11:45 Arial_Bold.ttf
-rw-r--r-- 1 root root 206132 2000-05-11 11:45 Arial_Italic.ttf
lrwxrwxrwx 1 root root     16 2009-02-23 20:04 ariali.ttf -> Arial_Italic.ttf
lrwxrwxrwx 1 root root      9 2009-02-23 20:04 arial.ttf -> Arial.ttf
-rw-r--r-- 1 root root 275572 2000-05-11 11:45 Arial.ttf
lrwxrwxrwx 1 root root     15 2009-02-23 20:04 ariblk.ttf -> Arial_Black.ttf
lrwxrwxrwx 1 root root     22 2009-02-23 20:04 comicbd.ttf -> Comic_Sans_MS_Bold.ttf
-rw-r--r-- 1 root root 111476 1998-11-10 13:52 Comic_Sans_MS_Bold.ttf
-rw-r--r-- 1 root root 126364 1998-11-10 13:52 Comic_Sans_MS.ttf
lrwxrwxrwx 1 root root     17 2009-02-23 20:04 comic.ttf -> Comic_Sans_MS.ttf
lrwxrwxrwx 1 root root     20 2009-02-23 20:04 courbd.ttf -> Courier_New_Bold.ttf
lrwxrwxrwx 1 root root     27 2009-02-23 20:04 courbi.ttf -> Courier_New_Bold_Italic.ttf
-rw-r--r-- 1 root root 234788 2000-05-11 11:45 Courier_New_Bold_Italic.ttf
-rw-r--r-- 1 root root 311508 2000-05-11 11:45 Courier_New_Bold.ttf
-rw-r--r-- 1 root root 244156 2000-05-11 11:45 Courier_New_Italic.ttf
-rw-r--r-- 1 root root 302688 2000-05-11 11:45 Courier_New.ttf
lrwxrwxrwx 1 root root     22 2009-02-23 20:04 couri.ttf -> Courier_New_Italic.ttf
lrwxrwxrwx 1 root root     15 2009-02-23 20:04 cour.ttf -> Courier_New.ttf
-rw-r--r-- 1 root root 158796 1998-11-10 14:00 Georgia_Bold_Italic.ttf
-rw-r--r-- 1 root root 139584 1998-11-10 14:00 Georgia_Bold.ttf
lrwxrwxrwx 1 root root     16 2009-02-23 20:04 georgiab.ttf -> Georgia_Bold.ttf
-rw-r--r-- 1 root root 156668 1998-11-10 14:00 Georgia_Italic.ttf
lrwxrwxrwx 1 root root     18 2009-02-23 20:04 georgiai.ttf -> Georgia_Italic.ttf
lrwxrwxrwx 1 root root     11 2009-02-23 20:04 georgia.ttf -> Georgia.ttf
-rw-r--r-- 1 root root 142964 1998-11-10 13:59 Georgia.ttf
lrwxrwxrwx 1 root root     23 2009-02-23 20:04 georgiaz.ttf -> Georgia_Bold_Italic.ttf
lrwxrwxrwx 1 root root     10 2009-02-23 20:04 impact.ttf -> Impact.ttf
-rw-r--r-- 1 root root 136076 1998-11-10 13:52 Impact.ttf
lrwxrwxrwx 1 root root     24 2009-02-23 20:04 timesbd.ttf -> Times_New_Roman_Bold.ttf
lrwxrwxrwx 1 root root     31 2009-02-23 20:04 timesbi.ttf -> Times_New_Roman_Bold_Italic.ttf
lrwxrwxrwx 1 root root     26 2009-02-23 20:04 timesi.ttf -> Times_New_Roman_Italic.ttf
-rw-r--r-- 1 root root 238612 2000-05-11 11:45 Times_New_Roman_Bold_Italic.ttf
-rw-r--r-- 1 root root 333900 2000-05-11 11:45 Times_New_Roman_Bold.ttf
-rw-r--r-- 1 root root 247092 2000-05-11 11:45 Times_New_Roman_Italic.ttf
-rw-r--r-- 1 root root 330412 2000-05-11 11:45 Times_New_Roman.ttf
lrwxrwxrwx 1 root root     19 2009-02-23 20:04 times.ttf -> Times_New_Roman.ttf
lrwxrwxrwx 1 root root     21 2009-02-23 20:04 trebucbd.ttf -> Trebuchet_MS_Bold.ttf
lrwxrwxrwx 1 root root     28 2009-02-23 20:04 trebucbi.ttf -> Trebuchet_MS_Bold_Italic.ttf
-rw-r--r-- 1 root root 131188 2001-04-09 16:05 Trebuchet_MS_Bold_Italic.ttf
-rw-r--r-- 1 root root 123828 2001-04-09 16:05 Trebuchet_MS_Bold.ttf
-rw-r--r-- 1 root root 139288 2001-04-09 16:05 Trebuchet_MS_Italic.ttf
-rw-r--r-- 1 root root 126796 2001-04-09 16:05 Trebuchet_MS.ttf
lrwxrwxrwx 1 root root     23 2009-02-23 20:04 trebucit.ttf -> Trebuchet_MS_Italic.ttf
lrwxrwxrwx 1 root root     16 2009-02-23 20:04 trebuc.ttf -> Trebuchet_MS.ttf
-rw-r--r-- 1 root root 153324 1998-11-12 07:18 Verdana_Bold_Italic.ttf
-rw-r--r-- 1 root root 136032 1998-11-12 12:15 Verdana_Bold.ttf
lrwxrwxrwx 1 root root     16 2009-02-23 20:04 verdanab.ttf -> Verdana_Bold.ttf
-rw-r--r-- 1 root root 154264 1998-11-12 07:18 Verdana_Italic.ttf
lrwxrwxrwx 1 root root     18 2009-02-23 20:04 verdanai.ttf -> Verdana_Italic.ttf
lrwxrwxrwx 1 root root     11 2009-02-23 20:04 verdana.ttf -> Verdana.ttf
-rw-r--r-- 1 root root 139640 1998-11-12 07:18 Verdana.ttf
lrwxrwxrwx 1 root root     23 2009-02-23 20:04 verdanaz.ttf -> Verdana_Bold_Italic.ttf
lrwxrwxrwx 1 root root     12 2009-02-23 20:04 webdings.ttf -> Webdings.ttf
-rw-r--r-- 1 root root 118752 1998-07-10 08:47 Webdings.ttf

To store these files into a “gzipped tar” archive file, you can execute the following command:

tar --create --verbose --gzip --absolute-names --file msttcorefonts.tar.gz /usr/share/fonts/truetype/msttcorefonts

This will run the “tar” program with the following parameters:

• “--create”—Create a new archive file.
  This option may be abbreviated to “-c”.
• “--verbose”—List the files as they are processed.
  This option may be abbreviated to “-v”; without it, the program will run quietly.
• “--gzip”—Create a compressed archive, using the “gzip” utility.
  This option may be abbreviated to “-z”; without it, the archive will not be compressed—which is not recommended.
  As an alternative, you may use the “--bzip2” (or “-j”) option instead—which will generally create slightly smaller archives, but take longer to complete.
• “--absolute-names”—Record absolute path names for the stored files, including leading “/” characters.
  This option may be abbreviated to “-P” (i.e., uppercase “P”); without it, the leading “/” characters will be omitted, and the files will be stored with relative paths instead.
• “--file msttcorefonts.tar.gz”—This option specifies the name of the archive file that will be created.
  This option may be abbreviated to “-f msttcorefonts.tar.gz”.
  If you use gzip compression, then you should generally specify “.tar.gz” (or “.tgz”) as the filename extension.
  Alternatively, for bzip2 compression, “.tar.bz2” is the generally recognised extension.
• Finally, one or more paths must be given, which identify the files and/or directories that you want to archive.

Note:

The command line as shown above, uses long option names, which are, admittedly, somewhat uncommon. The following is an equivalent, abbreviated command—which you will likely encounter much more frequently:

tar -cvzPf msttcorefonts.tar.gz /usr/share/fonts/truetype/msttcorefonts

To verify if the archive file was created correctly, you can run the “tar” command with the “--list” (or “-t”) option—i.e.:

tar --list --verbose --gzip --absolute-names --file msttcorefonts.tar.gz

or, in its abbreviated form:

tar -tvzPf msttcorefonts.tar.gz

Step 2: Extracting the Font Files from the Archive.

You can now use the “msttcorefonts.tar.gz” archive file, created above, to copy the font files to their proper location onto any computer on which you want to install the “Microsoft TrueType core fonts” package. Just run the following command in order to extract the contents of the archive:

sudo tar --extract --verbose --gzip --absolute-names --file msttcorefonts.tar.gz

or, in its abbreviated form:

sudo tar -xvzPf msttcorefonts.tar.gz

Note that you will have to run this command under the all-powerful “root” user account (i.e., via “sudo”), because it will need write permission to the “/usr/share/fonts/truetype/msttcorefonts” location—which is a system directory.

Also, make sure to include the “--absolute-names” (or “-P”) option; if you omit it, then the leading “/” characters on the target path names will be ignored, and the files will be extracted into a “usr” subdirectory of whichever location happens to be your current working directory.

Step 3: Installing the “msttcorefonts” Package.

Now that the actual font files are available on the target computer, they will not be downloaded again when you install the “msttcorefonts” package, e.g., with the following command:

sudo apt-get install msttcorefonts

No data will need to be downloaded, but the following line will appear as part of the output from the installation process:

All fonts downloaded and installed.

Once the installation procedure is completed, the Microsoft TrueType core fonts will be available for use on the computer.

[Geochelone]

Hi luvr,

This section of the thread is referred: ADDENDUM: Removing Old Package Versions from your Local Repository.

I used to employ this hack and slash trick to clear the dupes from my Intrepid repo (Canonical, MediBuntu and Official). However, when I run debmirror after I cleared the dupes, it said I need to download XXX MB of packages.

I found out those XXX MB of packages are actually the dupes I deleted earlier.

*

I copy the outputs of the dpkg-scanpackages, e.g.

! Package cupsys-common (filename /home/geochelone/Desktop/Repositories/Jaunty/Official/pool/universe/c/cups/cupsys-common_1.3.9-17ubuntu2_all.deb) is repeat but newer version;
   used that one and ignored data from /home/geochelone/Desktop/Repositories/Jaunty/Official/pool/universe/c/cups/cupsys-common_1.3.9-17ubuntu1_all.deb !
! Package libcupsys2 (filename /home/geochelone/Desktop/Repositories/Jaunty/Official/pool/universe/c/cups/libcupsys2_1.3.9-17ubuntu2_all.deb) is repeat but newer version;
   used that one and ignored data from /home/geochelone/Desktop/Repositories/Jaunty/Official/pool/universe/c/cups/libcupsys2_1.3.9-17ubuntu1_all.deb !

I copied the all the ignored packages, and > them to a file.

/home/geochelone/Desktop/Repositories/Jaunty/Official/pool/universe/c/cups/cupsys-common_1.3.9-17ubuntu1_all.deb
/home/geochelone/Desktop/Repositories/Jaunty/Official/pool/universe/c/cups/libcupsys2_1.3.9-17ubuntu1_all.deb

Then, I just rm the dupes from the list inside the file.

*

Idk what's wrong.

[luvr]

I used to employ this hack and slash trick to clear the dupes from my Intrepid repo (Canonical, MediBuntu and Official). However, when I run debmirror after I cleared the dupes, it said I need to download XXX MB of packages.

I found out those XXX MB of packages are actually the dupes I deleted earlier.

Well--it looks like this is an issue that I had overlooked. I haven't used debmirror yet, so I didn't run into this problem myself.

I guess that the online repositories keep a number of old packages available for a while. Now, if you delete them from your local repository, then debmirror will notice that these old versions are available online, but that you do not have them in your local copy. Therefore, since debmirror wants to synchronise your local copy with the online repository, it will redownload these absent files.

Conversely, if a file is available locally, but is missing in the online repositories, then debmirror will assume that it is no longer available online, and that it must be deleted from the local copy.

The moral of the story, then, appears to be, that you should not manually remove files from (or add files to) a local repository that you maintain via debmirror. Instead, you should leave all maintenance of the local copy up to debmirror.

I'll add a note about this issue to my post, since it is something to be aware of.

[Geochelone]

I believe so too.

However, your tips should work very well to maintain downloaded packages from PPA.

Thanks for the tips!