debian

debian repository

I needed this for installing my own packages with ansible scripts, and just using apt greatly eases that process. So this is without signing or any other fuss.

creating the packages

Since apt/dpkg installs absolute paths, i decided to put all code under /usr/share/klopt rather than /home/kees/... . So i created ~/projects/package :

mkdir ~/projects/package cd ~/projects/package mkdir -p usr/share/klopt

Now to populate these directories, we don't need all sources, so :

cp -r ~/home usr/share/klopt/home rm -rf /usr/share/klopt/home/.git

I like a separate package/deb for home, and the klopt code, so let's take this for now. We use the effing package manager fpm for this :

gem install fpm fpm -s dir -t deb -n "klopt-home" -v 1.0 -a all usr

This stands for (-s) source type (dir) directory, (-t)target type (deb)debian package (-n)name (klopt-home) -(a)architecture (all), -(v)version (1.0) and last is the directories(s) to add (usr)

It creates : klopt-home_1.0_all.deb in ~/projects/package which is the source we use in the next chapter :

setting up the debian repository :

We do this the simplest way, on a running apache server in the root /var/www/html/repo, so this requires no real setup if /repo is unused. The next step assumes the packages are built on the same machine. Of course if not, you need to copy them there.

mkdir -p /var/www/html/repo/klopt cp ~/projects/packages/*.deb /var/www/html/repo/klopt
dpkg-scanpackages /var/www/html/repo/klopt

This last command will generate a Packages.gz file containing the metadata needed for apt* commands.

Now setup your apt with a file called :

/etc/apt/sources.list.d/klopt.list

Containing :

/etc/apt/sources.list.d/klopt.list

deb [visit](http:///repo/) /

In my case, it was a (vagrant) local VM so :

actual content

deb [visit](http://192.168.50.10/repo/) klopt/

apt-get update will tell you if that works all right

signed repository and packages

Todo. Problems with gpg --gen-key (hanging forever) made me do this without signing, but the base for these chapters : visit does contain directions to fix that.

see klopt/repository for a complete example anno 2020

the uninstall problem

Well i decided that it would be the last time i watch gnome to be uninstalled before my eyes and then reinstalling it again....

The whole problem is with metapackages and autoremove.

aptitude keep-all

This marks everything in the system as a manually installed package. This defeats the "autoremove" process entirely and may cause your system to contain unnecessary packages over time.

But for more in-depth information, some gems i found on the interwebz :

this

telemachus

This is a well-known issue. In a nutshell, you installed Gnome via a metapackage. Metapackages are wrappers that help you to install and update a huge collection of items easily. The price you pay is that each of the individual packages is required in order for aptitude to keep all the rest. Therefore, if you remove even a small, apparently inconsequential piece of Gnome (which you probably did inadvertently), aptitude will cheerfully tell you "Ok, Gnome's got to go."

There are a couple of options to handle this: Don't install the metapackage to begin with. Install all the individual items you want one by one. (Pros: no metapackage problem; no bloat of items you really don't want. Con: no metapackage convenience.) Install the metapackage, but if you need to remove one bit, do it in a special way: CODE: SELECT ALL apt-get remove aptitude keep-all

Apt-get can surgically remove one item, and then if you tell aptitude keep-all, it won't later try to remove all your other Gnome stuff. For you now, you can either run the aptitude keep-all command or let aptitude remove it all and then reinstall what you really want yourself. (As a start, you will almost certainly want gnome-core, which is itself a meta-package, but much smaller and more reasonable than gnome or gnome-desktop-environment.) The first method is quicker, but I prefer the second (cleaner, lighter, I'm more in control). It's up to you, though.

As a more general rule (a lot of people have learned this recently in testing), do not simply trust aptitude (or apt-get or any other computer program) to "do the right thing." Check the output carefully, and if you're not sure, say no and post a question somewhere.

bugsbunny

like the auto-remove features and hate running keep-all, since I think it turns of the auto-installed status on all those packages. What I rather do is find a key package, or 2, or 3, that all those other packages rdepend on and then turn of the auto-install just for those packages. You can do that from within aptitude when it asks if you want to continue (y,n,?). If you enter ? you'll see your options, but basically entering &m at that prompt will mark the package as manually installed, preventing the removal of that package and anything in it's dependency list. aptitude will then give you the same prompt, after changing it's list, giving you another opportunity to mark another package as manually installed, proceed, or stop etc.

I very rarely use keep-all But it's a good feature when you need/want it. You can also completely turn off auto-remove, or turn it off for certain packages etc. (which is why kernel images are never auto-removed. See /etc/apt/apt.conf.d/01autoremove for why that is.

The aptitude manual is definitely worth a read through to become familiar with the options, or at least the sections related to how you use it (eg I don't bother with the ncurses interface parts).

apt-mark

Watch the apt-mark command to toggle if a package was auto or manual, this for instance would be a very welcome command :

sudo apt-mark unmarkauto gnome-desktop 

It will prevent gnome-desktop from being torn down. You can see which packages are mark manual or auto with :

apt-mark showauto
apt-mark showmanual

You could mark everything manual, but i doubt it is a good idea :

apt-mark showmanual | xargs sudo apt-mark manual

simulate

There is a simulate option to apt-get that might be handy

apt-get autoremove --simulate

setting up a new workstation

Not complete !!, but there are number of bad decision made by distro makers and this is the place to set thing right.

delete in nautilus

You can now only delete files whit the ctrl and delete key in nautilus, horrible decision. But there is a number of steps needed to get it correct again.

First:

Start dconf-editor (NOT) gconf-editor. And set org.gnome.desktop.interface.can_change_accels on.

dconf-editor

Now restart nautilus, and place your mouse over edit : move to trash, hit delete, which will probably delete the old setting, so hit delete again. Your delete key works again.

old version :

Ok this does not work anymore, but on old systems it might :

sudo apt-get install gconf-editor
gconf-editor

Yes that last one edits YOUR setting so don't do it as root ! Then search for can_change_accels (desktop.gnome.interface) , and alter it to on Now you can alter a key like above.

proxy apt-get

Create, or add this line to /etc/apt/apt.conf :

Acquire::http::Proxy "http://yourproxyaddress:proxyport";

creating a ramdisk

The reason for this was to lay off the new SSD disk while developing tsp. Every single alteration means a new run with a new (big) log file and that just feels bad for the solid state drive.

And you can do it even faster on a memory disk. It all boils down to this entry in the /etc/fstab file :

tmpfs           /media/ramdisk tmpfs   nodev,nosuid,nodiratime,size=8192M   0 0
# of course you also need to :
mkdir /media/ramdisk
mount -a 

I have plenty of memory (32G) so a dedicated 1/4 to this. Now you can just work on /media/ramdisk but be sure to save your work a lot ! ;)

unattended upgrade

Warning

Don't use this, you are bound to get stuck while you want to install a package and the system is doing the upgrade. Just regularly do it by hand !!

You can install this as a service, which will start it at around 6:00 am. However sometimes it seems to hang. You notice it when aptitude says dpkg is locked by another program. With top you can see if it is unattended-upgrades or just a forgotten aptitude.

Or.. and this will be the final solution :

while pgrep unattended; do sleep 10; done;

If this prints pid's every 10 seconds unattended is still busy. In my case i though it was hanging but it just finished after some time !

If you still want more proof, you can see what's going on with :

tail -f /var/log/unattended-upgrades/unattended-upgrades.log

The upgrade can be done by hand with :

systemctl status unattended-upgrades
systemctl start unattended-upgrades
while pgrep unattended; do sleep 10; done;

If you need to alter the timers, they are in :

/lib/systemd/system/apt-daily.timer # for downloads
/lib/systemd/system/apt-daily-upgrade.timer # for upgrades

See for more info : visit