It just takes a moment. I tested it. I just changed one final thing. But it's working, you know. I did that in Argentina, too. You saw it before. Anyway, like I said, it was working. So yeah, that's me. This is not the first time I'm doing this talk.

I did it in Argentina already. It's just Doug was there. Yes, in Argentina, we met. Wonderful. And then I did it again in Essen. No, I was not. I'm not sure. In Germany somewhere, where we had a meeting. So it's going to be slightly different this time, because this is supposed to be across this through development

room. And I'm hoping for it not to be only Debian specific. So if there's anybody in the room who knows stuff about other distributions, and you say, oh, yeah, we have something similar in Fedora or Red Hat or SUSE, I don't know, I expect you to interrupt me and to tell me and the rest of the audience

that, yes, this particular feature is also available for that other distribution. The idea is to learn from each other, so let's do that. So I need your help for that. Thank you very much. So the first thing I would like to talk about, this is the main focus of the talk, is to see how you can improve

the use of your distribution or your use of the system if you're a power user. The first thing I would like to talk about is called update alternatives. Let's assume you have something in a distribution that many packages provide. For instance, an ex-terminal application. There's ex-terminal, there's URXVT, there's RXVT,

there's console, there's gnome-terminal, there's hundreds of, well, probably not hundreds, but a lot of packages that provide similar things. And if you depend on one of those, as a package, you don't really care which one is being used in the end. It's the user who cares most.

And the distribution may provide default, but you may want to update those defaults at some point. And that's what update alternatives is for. How do we do this in the ex-terminal example? By calling this command as root, we can just say on a system-specific level, we wish to change the default, and then rather than ex-terminal,

which I believe is a default, I'm not entirely sure, you could say, I prefer URXVT instead. And then whenever a package calls URXVT from a menu, sorry, wishes to call an ex-terminal emulator from a menu or something, then URXVT is called rather than ex-terminal. So that's a very easy way in Debian to modify it.

I don't know, maybe somebody can tell me whether something similar exists in all distributions. Wonderful, look, I didn't even know that. Like I said, I'm a Debian guy, so I really don't know all the distributions all that well. More documentation, of course, in the main page.

It's not very difficult to use. This is just one to start. Something more interesting is the package stat override. Let's imagine you wish to limit access to writing CDs to just a group of users because you've got a multi-user system that 500 people can SSH into,

and you have a CD burner there because sometimes you need to write files. And you don't want some random joker to start updating or start writing to your CD drive just because he's got an account. Well, what you could do, the easiest way is to do something like this where you just revoke, execute permissions

from the others group, and then create some CD writers group and make sure that only the people who are actually allowed to write are in that group. That's probably a reasonable way to do this. The only problem with that, of course, is that once you do an upgrade of your package, the packaging system will say, oh, the permissions here are wrong, so let's just fix that.

And then everybody can write to your CD drive again. So you don't want to do that. Instead, what you can do is you use the package stat override in this way. So you just say, we wish to overwrite. That just update is just the way to say, if you have something created,

change it if you don't create it. Then we have add and then we say, root CD writers, sorry, my mistake. That means also sync with the file system, my mistake, sorry. So add means add it to the database, update means update the actual file on the file system. Then we say the permissions which we wish to create

and then the file which we wish to modify. Now every time we have an upgrade, the package will see the stat override database and will actually update the file as it is specifying the database rather than what it thinks is the best. Again, does anybody have something to add here? Nothing exists in all the distributions? Oh, wow.

So of course, more information on that is in the package stat override. It's also fairly easy to use. Of course, you can abuse it to the extent that, for instance, you could revoke roots, the ability to start bash and then everything starts breaking, but you do not wish to do that, of course.

Right, next chapter. Every distribution, of course, has a way to search for packages. And the most well-known way is to do just app cache search and presumably author distributions have similar things. The idea here is that you give a few keywords

and then the packaging system does a full text search on maintainer names, package names, descriptions, whatever. It works, but there's a limitation. For instance, Enrico Zini used to brag about his, well, not brag, but used to tell us that, well, if you search for image and editor,

you get all kinds of things, but what you don't get is GIMP, because it says picture and stuff like that. So you don't get the GIMP as an image editor, which is fairly problematic, because if you're looking for an image editor, the GIMP really is what you're looking for. So you can also have a very complex search,

which would give you a lot of results. Again, Enrico, who, by the way, wrote dev tags, likes to say that if you have so many results, once you get beyond 15 or 20 or something, your brain goes banana, because it just can't keep up with all the results. So the idea of dev tags is to structure that a bit more.

You have a bit more fine-grained searching, where every package gets a tag, or multiple tags, actually. You can have tags about what languages it's implemented in, what user interface it's using, what kind of package it is, what it tries to do, and stuff like that. On average, packages usually have about 10 to 15 tags, so there's lots of properties you can search for.

Then there's something that, well, you can actually do dev tag search, so you enter that command, and then you get a list of things. You enter a number of properties, and you get the list of packages.

I was going to demonstrate it, but unfortunately, my laptop decided to have its, if somebody, let me show what the problem is. Now, if there's anybody who can tell me why this totally useless error message is supposed to end up here,

and tell me what is wrong, and I would really appreciate it, but it means I cannot install dev tags, because I haven't installed it this morning, and there's no networking for me here, so I can't demonstrate anything, which I was supposed to do. But yeah, you can do dev tag search, or dev tag stack search, which allows you to search for tags, then you do dev tag search with a list of tags,

and it gives you a number of packages that tells you which packages, sorry, you get a list of packages that are in those tags. And yeah, the final example was Go Play. Go Play is an application that lists all packages

that are actually games based on dev tags. It solves them, and it gives you a screen interface. Would also be nice to give you a demo on that, but unfortunately, that's not gonna happen. Anyway, is there something similar, again, in other distributions? Nobody knows? This is not turning. Yeah, sorry?

Yeah, something fine grained searching, or maybe something related to searching, I don't know, like I said, what I thought was at most distribution to do, yes, over there?

I'll just repeat the question. So your question was that if you created a Debian package, whether it is necessary to enter the dev tag yourself in there. Well, you can do that. In the Debian control file, you can add tags, and then they will work, but you don't have to do that. It's not required for policy currently. For packages in the official Debian archive,

Enrico has set up a website where you can manually add dev tags, where users can add dev tags. So of course, these are verified so that we don't get crap in there, but basically, it's mostly a separate process for now. But for instance, in Aptitude,

you can also search on dev tags since about, I think that's a new feature in Lenny, I'm not sure. Yeah? Don't you think that initiative could be used across distribution? Because in fact, all the stuff you're doing here is putting some metadata around the upstream application. Absolutely. Which could be shared across a large number of distribution, and each could implement or not

a way to search through those tags. That is absolutely true. Just for one thing, to make my point clear, I did not write dev tags. I'm just mentioning it, Enrico wrote it. It's absolutely true, and Enrico did indeed write dev tags in not just the distribution-independent way, but also independent of packaging as a whole. It's just a system to tag.

It's lib tags, I believe he calls it. And you can apply it to anything. So it's just a library, and absolutely, all the distributions could use it, provided that you would use the library. It's fairly generic. It's just a system to, I think you have a hierarchy of tags, and things can have one or more tags applied, and you can search for them.

That's basically all the library gives you. So yeah, absolutely no problem. Okay. So the project website is dev tags, Ali of Debian Org. You will find all the information on the tags on that website. Yeah, the package dev tags, and the package Go Play in Debian will allow you to look for what dev tags actually can do.

Creb-available is another tool to search. This is useful if you know some things about a package. For instance, you know who made it, or you know that it's, what source package it was built from. Creb-available will go to the index file that app downloads, which is called the available file in Debian,

list of all available packages rather than just the installed packages, and it will just grab through it, which is possible because it's just a plain text file in Debian. Of course, there's a bit more, because if you find a match, then it will get the entire block of information, and you can get some useful information from that.

So you can search by control fields, and you can get some information. This is just a very simple example. If you run this on a Debian system, it will give you a list of all the packages that I wrote, or that I maintain. What do we do here? We say, Creb-available, on the field called maintainer,

with that data, which is my Debian.org email address, and then you just show the package, as for show the package. So that's very easy. Slightly more complex example. We wish to find all kernel images on this system, that are from the 2.6 source. So we do, Creb-available, field, the source package.

Source is just the control field for which source package we're from. The name we're searching for is Linux-2.6. But we also, is just a boolean operator, and field package, must contain the word image, because we're looking for a kernel image. We're not looking for modules, packages, we're not looking for firmware that might have,

or might not have been split away. We're looking for kernel images. So, image, and then we show the package name. And that will give you a list. I can do this, that's not a problem. I think I have Creb-available installed. A very little question. Sure, go ahead. Does it also search in installed packages? Yes, I don't know where you are, sorry.

Right there, oh sorry. Yeah, it does search for installed packages as well. The available file contains all available packages. There's also an installed, which is a separate file, which contains all the installed packages, but there are duplicates of the available. So, yeah, absolutely. What it, I'm not entirely sure whether it will also search for packages that are no longer available

to be installed newly, but are still installed in the system, aka our data packages. But the package that contains this program also contains other Creb tools to search in those files. Creb-available is just a default one. Slightly more complex version. We can also ask you to give information about the version

just by adding extra fields. The difference in output here will be, if you do this, you just get a list of package names. If you do this, you get a list of package names and versions where every line is presented by the field name,

and then you get the empty lines in between. So the formatting is slightly different because you've got more fields and you need to know which fields is which. That's all. So the package is the control tools and yeah, there's Creb-available man-page if you need to. Can we compare this against something in other distributions?

Yeah? Can we have a microphone? Sorry. Don't kill people. About two years ago or so, I created a client server system for NetBSD and the package source that also have field to be searching

and a list of search strategies. All this is based on dictionary-based protocol. Maybe you'll listen about it. So the question is, what do you think in general about client-server approach?

I don't know actually, to be honest. I think it might be a good idea. So if I understand you right, you say that there is a addict server for packages in NetBSD or did I get that wrong? Package source is cross-platform, so. Oh right, right, right, right, right.

Well, it might be useful. It might not be useful. It depends on what you want to do with that, I guess. This is just one way to search on the index files that are available on your system. The upside of doing this is that it allows you

to search for only those packages that are relevant for the installed system, whereas the downside is that if there is something in the unstable archive and you're running stable, and you might want to know about that. Of course, for a source-based distribution, the requirements are different because you can just install the next version. My system, PKG online.

Main search in so-called source summary and binary summary. Binary summary is something like Debian repository. So actually it may be adapted for Debian easily. Okay, well, sounds cool, thanks.

Thanks for sharing. Right, the next thing is about, well, there are ways to fool a Debian package system. Of course, I should not have to remind anyone that if you start messing with a packaging system and the stuff breaks, that you should be prepared to unbreak it yourself.

If it breaks, you get to keep both pieces, let's put it that way, right? But anyway, you can do lots of cool stuff with it. Let's say you have a laptop with an ugly NVIDIA screendriver, and you still want to see something. So you want to install the binary module

from nvidia.com. Now, of course, if you do that, it wants to install a libgl. And you may be running some free game from Debian, which also needs libgl. So it depends on the mesa-gl library that's in Debian. So it also wants to install libgl.

Which is fine, you just install the mesa-gl first, and then you install nvidia, and it overwrites the GL library, and everything's fine until you do the upgrade. And then, well, hmm. Now, suddenly, you've got the Debian GL again. Now, of course, there is an nvidia package in all the free Debian, which you can install,

which will nicely avoid that issue. But let's say it's not recent enough or something. Then we're still at this problem. So what we can do instead, excuse me, what we can do instead is to just use dpackage-divert to tell dpackage that we, yes, we know there's a file here,

but we actually want it on a different location. So what we do here is we tell dpackage that whenever it finds this file name in one of the packages, rather than installing it at that location, we wish for dpackage to install it at this location, which is libgl.so.dabian. The dynamic link will not find that file.

Nothing else will, actually. But by doing this, we make sure that no package upgrade will override the libgl from nvidia. So a vine-only driver still works. Of course, it has some issues. For instance, if some other package then needs to depend on at least a specific version of libgl, then, well, this will still break.

But you will not have the problem where upgrading the package removes you by a new version. So that can be useful, right? It is important, of course, that when you do this, you first dpackage-divert everything away, and then you then install the nvidia binary module.

Otherwise, this file will be the nvidia version rather than the Debian version. Right, yeah? If I have my own package that override, I want to override the binary, what could I do?

I can use the pkg-divert in my post-install scripts. Yes, you can. But there are specific things you should be aware of. They're mentioned in Debian policy. I don't think it's the right place to go into right here. But you can, yeah.

Yes, of course. I mean, without creating a conflict. Yeah, right. You can do that. It's allowed to do this. But of course, if you divert the file away from another package, then you should make sure that the interface is the same, because other people will start filing bugs against the original package, and then this maintainer will yell at you with good calls.

There are certain things to look out for, but yes, it can be done, and it is done in certain cases, yeah. Okay, thank you. Again, yeah, one final thing. You cannot use this for configuration files, because configuration files have a totally different mechanism of ensuring that changes are not overwritten,

and they conflict. So do not try this. If you do that, then everything will break. Having said that, are there any similar things in Red Hat-based machines? Microphone. Sorry? Question about the divert. Can you revert? So that means you don't want any more?

Oh yeah, absolutely. I think it's the package that I've heard, that's just remove or something. It's just a standard, I don't know, by heart, let me check that one. That's just remove, yeah, absolutely, no problem. Thanks. Yeah, it would be silly not to be able to do that.

You said I should not use this for configuration files? That's right. Well, my colleague does it, I will say to him, but I use update alternatives for configuration files. Is that a better way, or is there a third way that's recommended? That.

Alternatives are installed by the package themselves, always. Well, you can install local alternatives, but that's not what it's meant for. And if you do that, what you have then basically is at the place where the configurations file is, then you get a symlink, rather than the file itself. And the symlink points to it actually,

all the symlink, it's the alternatives, which is managed by the alternative system, and that second symlink then points to the file you're actually modifying. So it is clear from the start that the alternative system, if you have that file there, that you have an alternative. And no package would be able to install a regular file.

It would have to install an alternative and get it done that way. If you use the package divert, what you do there, it's actually a bit of a hack. What you have is, there's a file there, and it's supposed to be there, and it's not an alternative, the file is just there. But we tell the package that, yes, we know the file is there, but push it away. Do I push it away, and I get to be first.

With the alternative system, you as a system administrator will be able to modify that. With the diversion system, not so much. So that's the main issue with it, it's less flexible. What usually happens with configuration files,

if you have local changes, local modifications, and you have an upgrade, I think everybody who uses Debian has seen this once or twice, at least, the package will tell you, I've got differences here, what do you want to do with, do you want to update the file, do you want to keep the changes, do you want to postpone this.

So there's basically a protection for modified files, it contains checks and everything. So that is an entirely different thing, and that's what's usually used for configuration files. If you want to change that there, then use that. There's also a way to do this for generated files, which I will not go into now, because that will be a bit of an out of scope talk. But in any case, the important thing to remember

is that deep packages really is not meant for configuration files, and that would break, and we're running out of time already, so I'll go on a bit. All right, any more questions? Because this talk was originally done in Argentina in about an hour, and now I have 45 minutes, and I wish to have more input from you guys, so I'm expecting not to be able to finish.

So, right, more information is in the deep package divertment page, which you've seen a few moments ago. But right, deep package repack is also a bit of a package system. I've got an example here, but I'll give you another example afterwards.

Let's say you've got some game for Linux, which the game writer company packaged for you, and you don't have to install it manually or anything. Wonderful, it doesn't happen all that often. It's not a free game, there's no source for it, but you like it and you like playing it. I mean, we all do sometimes, right?

But then the bad thing happens. You lose, you see the ROM, it gets scratched. I don't know, somebody steals it, and the company you wrote the game goes bankrupt and you can't find the replacement. Sorry? Oh yeah, yeah, Loki, you're right, yeah, gotcha. Well, it can happen, things like that happen, right?

Now you buy a new computer, and you wish to install that game there too. Well, you don't have the original installation media anymore. You can't buy a new one anymore. What you could do is you could say, I copied all the files there, but then you're back to what you didn't want to do, which was great because you had this package here.

Now what you could do instead is use deep package repack on the system where the package is installed. Deep package repack, the name of the package, and it will regenerate the Debian package for you so that you can install it somewhere else, which is nice, right?

That's a very good question, and that leads me directly to my next example, which is not here. Indeed, if you do that, then the updated configuration will go in the package, and this can be a good thing if you have 20,000 systems and you wish to install them with pre-configured stuff.

What you could do then is you use deep package repack after you configured one system to update, to create modified packages, all the packages you have installed on that system, and then you can install them on the other systems, which could be an interesting way to maintain a large number of systems. Thank you for that question.

If you're deliberately modifying a package, would you not want to add a changelog entry and bump the version? Does deep package repack have that option? I don't think so. I haven't checked that. Yes, maybe you would want to do that. This is more of an example of something where,

yeah, it's a bit of a quick and dirty solution, sure, yeah. It's not, if you really want to do this well, then you would probably just download the source and modify it in the source itself. This is a quick and dirty solution, absolutely, yeah, definitely. Does it also work with the original package

uses RPM or some other? No, this is Debian-specific, right. Maybe there exists something for Debian, if somebody can tell me. I don't know. For Red Hat, I mean, excuse me, for RPM packages, no?

Okay, what it does is it fetches the metadata information from the deep package database. It fetches the files that according to the metadata information are owned by this particular package, and then just builds that package with that information. It takes the posting scripts and the pre-inscripts

and everything. I remember about one project that make Debian up to salaries, books, and other packages from a list of files. So get a list of files, and the next step is to create a package.

It could be in, do you know the name of this project? Do you know, for the benefit of the people, what is the name of this project? Check install? Check install? No. That's something else, actually. There's another. Yeah. Okay. It exists, let's keep it there. Right, I thought I'd pull this out.

I apparently haven't. EPM. Sorry? EPM. EPM? EPM. Okay, EPM. Wonderful. Excuse me? There's a question over there, sorry. Question about Debian repack. If you repack a package and there is an update available, then you lose your changes. So if you have changes in the config file,

then the configuration file protection will kick in. No, it won't actually, sorry. No, yeah, then you lose your changes. So do you need to be careful then not to upgrade from standard Debian sources so that you needed something you need to worry about?

Thank you for that question. So, equips. Equips basically is a way to quickly build a package. I have an example of why this could be useful. So you've got some mail transport agents that's not packaged in Debian and you wish to install it and then you install cron

and that also pulls in a mail transport agent. So what we do is we install a package that claims it provides a mail transport agent so your source-based installation actually works. Of course, you could just build a Debian package the regular way, the hard way by writing all the files. What equips does for you is it generates a template

that you can modify and based on that template, it just fills in all the missing bits and pieces based on what, yeah, on defaults. So you don't have to worry about them. It's, if you use equips to build, to upload something to the Debian archive, then this will be poorly rejected because you've got boilerplate defaults in there.

But if you just want to do something like this here, then it really doesn't matter. It's just a simple tool to quickly build a package. It's in this package and if you read equips build is the package that will actually build the package

based on the template and equips control will generate the actual template that you can build off that gives you enough information. Now I'm quite sure, yeah? Maybe give the mic, yeah, sorry. I don't think it exists for Ratat or Fedora.

It's quite easy to build, I think, but I'm wondering is it only for provides or can you also use it for require so that you say? You can, and I believe, actually Enrico, whom I told about earlier, gave me an example of what he was using. He's got a package that he built with equips called Enrico Sanity, which conflicts with all the packages he hates.

So whenever some package is installed, then Enrico Sanity gets removed and that's a very good explanation. So yes, you can do that. Right, how much time do I have left? About 10 minutes, I guess. Yeah, slightly less anyway. Yeah, let's see if you have installed a number of packages.

Right, and you need to update it. You're running Debian Stable and you have package that often tends to go to boom and whatever, and you wish to make sure that you don't blow up your entire system every time you upgrade, then this could be useful.

AppLizBucks is the first of these, so this is actually a hopelessly, you install it, then before the package is even downloaded, AppLizBucks is called as part of a hooking app, which will go to the Debian bug tracking system and give you all the release critical bugs on this particular package.

So you can review that and then decide whether or not you wish to download the package because if you see that there's one release critical bug that says this package will eat my mother-in-law, then you may choose, may choose to go on anyway, but oh, you may choose not to go anyway, to go on.

So yeah, if you choose to go on, then the package, or add, get, or aptitude, whichever you're using, will go on and download the package, and then AppLizChanges is called, which will give you the changelog item and or, if you have that, if the package has that,

and use old Debian file, and use old Debian, sorry, AppLizChanges is installed by default in Lenny, in such a mode that it will only give you the new installed Debian entries, which is only entered when something important changes, but you can reconfigure it, so it will also give you changelog entries.

Every new package upgrade has a changelog entry. So you can review which changes were there, which changes were made in this particular package version, and you can choose to decline installing. It's been downloaded, but you can say, I don't really need these changes, I'll keep it as it is, thank you.

But if you choose to install them, package gets installed as regular. So this is a very good way to work with Debian Stable while not blowing your system every time things get upgraded. And I have five minutes left. Do you have something similar? Yes, Herman. I can say, I use Fedora at work,

and I can tell you that the Fedora updates the update program, I don't even know what it's called, will this change? Will this change? Okay, so this exists in Fedora as well. Then presumably in other RPM distributions too, or is this Fedora only?

I don't know. Right, right, okay, okay. So this is not something that's been specific, maybe the bugs thing is, but I don't know. Okay, I should have removed these then. Okay, thanks for that information. I've learned something, wow.

Maybe one more, and then we're finished. I'll skip it, I mean, the new thing that's not very interesting anyway. So, okay, let's say you have some game. I don't know if we've tried playing this game, but if you're into real-time strategy, it's pretty fun. It's a free game. It was non-free 10 years ago,

but then they decided to GPL it. So let's say you install that and you want to try it, and you actually don't like it, but the game pulls in several libraries. And you don't like it, and you remove it again. But by just removing this package, the libraries are still there. So what do you do with those?

Well, you can manually try to track them down and see, do I need to remove this? Oh no, that still uses it. And then you remove the other end. Actually, no, I still need that. And then you forget three or four because you didn't even know they were in there. So what do you do there? And that's where these three applications come in. DevFoster or Aptitude will track

which packages you manually installed and which packages were installed as part of a dependency chain so that when you remove Warzone 2100 afterwards, then Aptitude will see, or DevFoster will see, yeah, I've also installed these five other libraries as part of whatever, and now they're not actually needed anymore,

so I can safely remove them. DevFoster is somewhat more explicit than that in that it keeps, in DevFoster package, it can have three states. One is it was installed, yes, and we want it. The other is, no, we do not want this. It can be removed. And the third is, we don't know. And whenever DevFoster finds a leaf package

that it doesn't know anything about, it will ask and it will tell you, and then you can say, yes, I want it or no, I don't want it. So final one is DevBolfam. It uses some heuristics on libraries and tries to guess which one you may want or you may not want. It can be useful if you've never used

one of those before to get a starting point to clean up some old stuff. But of course, since it needs to guess, it's probably going to be wrong at some point, so you may want to be careful there. Same question. Yes, diagnose, ah, wonderful. And, you do know as well.

First of all, I use apt-get on CentOS and Red Hat, so the first thing will work, but even Yum has the ability to remove packages that it depends on that are not dependent on it. And also, there's a Yum utils package that has actually just tools to do queries

on your metadata, which also does the orphan packages and stuff like that. Good. And for Mount Rivers, they have a URPMI option to analyze orphans and to delete them, so they'll also maintain in the database the package you install manually, and they know when you remove them

if all the dependency can be removed or not. All right, okay. So that's actually basically what apt-get does well. Maybe taken from Debian, by the way. Could be. All the other way around, I don't know. Right. Other distribution, oh, somebody over there, right? 3VSD has a package LM leaves,

which gives you an mcurses interface. Which shows all the leaf packages that have no dependencies, and then you just tick box all the packages that you want to remove. All right. You say, okay, it removes all the packages, and then it goes in a loop where it shows you the same mcurses interface again.

Because you know you have to use it, please. It shows the new dependencies, the new packages without dependencies. You can very quickly clean up your whole system. Okay, good. So, somebody over there. There's a mic on the way.

It's actually, yeah, I should have added it. It's also available in Debian. You were mentioning apt-get auto-remove. Yes, that's true. When I originally created, sorry about that. When I originally created this talk, that was 2008, and then apt-get auto-remove didn't exist yet. But yes, indeed, since then, apt-get has received the ability

to store that kind of information as well. And now with apt-get auto-remove, you can remove those packages. Thank you for reminding me. I forgot. So yeah, Deb Foster, Deb Wolfen, and of course, oh yeah, sure. It's not clear for me why Deb Wolfen needs to guess. In the package source system,

every package is marked as manually installed or installed as a dependency. So not a question. No, yeah, it is with aptitude and with recent apt-get, that is true. But if you install something manually with apt-get

before the version that actually had auto-remove support, then that information was not available. So in that case, it had to guess because there was no information on that. And yes, basically, Deb Wolfen is slightly outdated now. But if you're using a somewhat older version of something that'd been based, then this could still be useful. Dak, yeah? I also should add that Fedora has a package database,

which is not the metadata only, but also all the other information who's helping with the package and stuff like that. And the orphan is also metadata that is not part of the package, but part of the package database, which is found online. Presumably, an orphan in that case, in that sense, is a package

that is not really maintained anymore. That is something entirely different than this. Okay, but, sorry. Are there any more questions? Because, no, no. Because I'm afraid we've run out of time now. I'll skip the final item. Thank you for your attention. I've learned some things too. I hope you all have, and see you next time.

Thank you. Thank you.