 Well, I think it's the real clock. This is package kit. Can you hear me? Okay, right. I crack on. First of all, my name is Richard Hughes. I maintain non-power manager. I'm co-maintener of non-power manager. I co-mainten OHM and I contribute to HAL. If you're using a laptop right now, which is probably the majority of you, just check out packagekit.org and there's some screenshots and other cool stuff. What I'm basically going to tell you is the problems that we've got at the moment, the competitors, as I see them, and also a possible solution. So, we suck. We really do. Thank you. We build kick-off packaging formats like RPM, Derb, et cetera, 1995. We layer on cool depth solvers and auto-downloaders to make it a little bit simpler. And then we try to bot on a UI on top of an existing stack. Now, this just doesn't work. If you want to have updates with that password, it's just impossible. What if you want to use fast user switching? What if we have two different sessions in two different locales? It's just impossible. What if we want to have common tools when using apps, when using YAM, which is impossible? So, what should we have done? We probably should have looked at actual user interaction and designed the tools around the use cases. Seems sane enough. But we can't do that because apps is Debian, RPM is Fedora, and all the distro build tools are built around the tools. So, we can't just replace everything wholesale. So, hence why I'm giving here, giving this talk. What we actually need to achieve is actually quite limited, which needs to keep a system updated, install new software, and have sane user interactions. We need to work with GNOME, be integrated between the desktop itself, and with KDE, XFCE, or any desktop you want to use. We have to work with YAM, Canary, App to Get, Box, Zip, Emerge, and all the other backends in existence. And we probably shouldn't break all the existing package tools because a lot of people are quite keen on App to Get. Quite a lot of people like Synaptic. I'm sure everyone's different. So, what we've done in the past, we seem to have updated, done different tools per distribution, which just we can't do, we can't do that long term. Fedora, Pup, Pirate, Ubuntu, no mapping stool, update manager, Suze, we've got a GUI on top of Libzip, and there's an update thing. And basically the others, it's the same shit, different day. So, we need root passwords. Now, if I'm searching for a package, why do I need the root password? Just not necessary. What the hell's GPG? If I install the system for my mom, or someone who's not IT literate, and ask them to confirm a GPG key, that's meaningless. It's pointless just laying out. We can't do things like multiple users. And so, if we have one locale in, say, French with my girlfriend, and we have another locale in English with me, and I switch, all the errors will be in the wrong language. So, we don't stick to any of the known UI specifications, or KDE UI specifications. It's something like Pirate, something like Python. And so, we sort of take a sort of halfway ground between KDE, XFCE. It's just a bit of a bodge. We typically badly design them, because typically only one distro guy doing making the tool. And it's probably translated by the distro. And therefore, it hasn't got the full upstream sort of localisation. It lets us do really crazy things, like start installing a system, or updating a system, and pressing the power button, and it powers down. Therefore, you lose your RPMDB, reinstall, et cetera. And it also updates on the train when we're on battery power, which probably isn't a very sane thing to do. When I'm using GPRS on a train, I probably don't want to do updates. So, let's see what we're doing wrong. Don't take any of this personally, if you guys have actually done this. What on earth's that? I don't know what I'd click. I'm wanting to see what updates there are, or if there are any updates. So, what is this root password thing, and why do I need it? Some things running. Like in Fedora, I see that if I'm running a YAM updates D in the background, and I'm seeing this on the foreground. Nothing I've run is running, that's stopping the accessing information. So, we're just locking needlessly. And we have errors like that, which is really useful. And like that. So, no source on media, I guess I would click yes, but I don't know. And apparently, D0A, FFF59, et cetera, just isn't valid. Again, useless. Absolutely meaningless. So, controversial. This does it actually quite well. It works with fast user switching. It downloads using BitSys background intelligent transfer system. And so, it basically uses idle bandwidth rather than foreground bandwidth. It has a pretty same preferences pane, so we can actually see what's going to happen when. We provide really good feedback to the user, telling us what we're doing. And by default, we update. So, it stays secure. But then it does things like that. Now, I don't know what 8000 FFF is, but apparently I need help. So, I'll try again. And I also am not sure what that's all about either. So, OSX, they've done things really well. They've looked at the user interactions and looked at what the user actually wants to do. It works with fast user switching. It downloads updates in the background. It has really same preferences. I can understand an update viewer which is pretty sane. And it defaults to automatically update. And so, the system stays updated. Easy to use. Big difference. This is application rather than package. And so, on OSX, I'm installing QuickTime. Now, Linux would obviously be installing something like QuickTime-libs, QuickTime-devil, QuickTime-debug. And they all might have different dependencies which dragged in and have to be updated. So, we can't really look at it from application point of view. But I'll come back to this in a minute. Now, Ubuntu have done some really good stuff in this. Some of the stuff works really well. And the problems with it are mainly down to core design decisions. I can't really use fast user switching in different locales. We can't use luckless operations. So, if we open Synaptic, we can't open the update viewer. We don't really have an upstream preferences pane. But the update viewer is not bad. It's pretty good. It's the best of the bunch. But Synaptic's really scared my fiance. She's not got a clue what to do. And no map install. Really, it looks fantastic. Really, really good interaction. But only works with Ubuntu. It's the back-end's not particularly helpful. The update viewer, pretty good. Synaptic, not sure what that is. And up and with applications, which is good. Now, a lot of you think in package kit, if you've done a bit of research, you might think, how is it actually different from Red Carpet? Red Carpet was a few years ago. I think, in my opinion, it's well ahead of its time. Now it's being much more successful. It was a demon running all the time. And so, I'm like package kit. Package kit will only run and load the demon when it's actually required. Navel, Red Carpet was doing that all the time. It had an enterprise focus rather than a home user focus. So it wasn't particularly easy to use. It supported RPM and DEV, but it replaced the depth solver and the downloader, which was the critical floor, I think, for adoption, because the distro didn't want to relinquish control of the depth solver for the bodges and the downloader for the mirrors. And it never really reached a critical mass. So, main point of the talk, what is package kit? It's basically a system designed to make installing, updating your system really easy. It should unify the graphical tools, and so we have some sort of sane user interaction. It should really make authentication really suck a lot less. At the moment, none of the distribution has done this correctly. It's not really designed to replace anything. And so, if you want to use package kit and pirat or synaptic, they should all live happily together. And we should never replace apt-get or yum, because that's just, well, heresy. And it's system-activated. So, as I mentioned, only when you use package kit is the system-demand-activated. Other than that, after five or six minutes idle, it will exit. So, this is how it actually works. It looks really scary, but it's actually really simple. Package kit D is system context. It's running just one per system. And there's a system debug interface to the client tools in the session. These tools, you've got to bear in mind, there could be thousands of these tools as a server, and they'll probably all be in different locales. And so, you have to be very careful passing things like errors up the stack. Obviously, all three tools, however many things can access package kits simultaneously. The back-end itself is basically a way of converting the distro tool to the package kit common API. But I'll come back to that in a minute. The active queue lets you queue a running task. Now, a task might be something like search for a file that is like rated here, or update the system, or update the specific package. Now, tasks are fire and forget. So, you have a task, you fire it, and it just does it. And then the active queue takes responsibility for queuing up actions for the back-end. Now, the back-end itself might need to talk to things that are Python, or written shell, or Perl, or anything. So, there's three ways we can talk to a back-end instance. The best one's probably using a D-Bus service, a persistent or a private connection. There's also a thread, so we can talk, we can open threads and talk to something like a libzip. We can use threads, or if we haven't got any of that, we have to use Perl or something. We can use helper executables and use standard input, standard error, and standard in. So, I've hinted what a back-end is, but it's really simple. It's basically a really small, compiled subject. It provides a really, really simple interface. There's nothing complicated at all. It converts, this sounds complicated, but it basically takes the package kit task and does it. And that's the only real bit that if you wanted to convert your distro to use package kit, you'd have to write. So, if you wanted to, say, merge Canary and Canary functionality into package kit, you're at 900 lines of Python, or C, or whatever binding you've got. And you don't even have to have a complete back-end. So, if you're using something on a mobile phone, so, like, O package or something, and you only support updating the system, installing software, and searching, you only have to, you actually implement those methods. You can have incomplete a back-end. In that instance, if a back-end was incomplete, the UI elements would reflect that. So, if you can't update the package, it wouldn't give you an update button to click. So, policy kit. Most of you might have heard of policy kit before, and package kit uses heavy use of policy kit to do the user authentication. That means the demon's running as, well, root or a configured system user, and is very sensitive. We can specify fine-grained control. And what that actually means is we can say, anyone in the admin group can install anything. Anyone who is my girlfriend's logon can do updating the system without a password. I can install and remove anything. And I can say that if someone wants to do something they can't, I can ask them for their own password or the administrator's password. So, for instance, an unprivileged user in a university could probably do updating and do searching, but can't install or remove packages or installed from a local file. So, if it's a bun-two or a home distribution, we can ask the user for their own password just to confirm that they actually want to do the action. And one thing I've mentioned about policy kit is you can save the authentication per session so that when you log out, it forgets your authentication or do it per system so it actually remembers across reboots. So, internally, to package kit, we have to abstract out certain things. And one of the key things is a package ID, which is basically, like a Fedora and Nevra, a unique way to identify a package. So it's name, version, architecture, and a bit of data. Now, the data field basically means the package ID has to be unique across every single repository. So, normally, the data field, you can encode as the repository name. As I said, it must be identified. Package IDs are never shown to the user because they're way too complicated. They're just not easy to use at all. I'll show what we show and said. So, filters. Search filtering is one in the back end. Just to reduce the IPC. We can do install. Here's the package installed on the system so we can see if something's installed or available in the repository on neither. We can also see if it's a development package. So if a user doesn't care about development packages, we can say, don't filter development. We can also do GUI filters. So we can say, does this program have any GUI element? So something like Powertop wouldn't come up, but something like Abbey Word would. Do we want just free software? Do we want software that's, say, the free flash, or do we want the proprietary flash? Do we want it to be visible? Some packages might not be useful to showing the UI, and so we can give it a package kit a hint that it shouldn't show them in a UI. And is it supported? Are we installing some random RPM or are we installing some supported Fedora or Ubuntu package? Now, you don't actually have to support any of those. So your back end, if your back end's got no way of telling if it's a GUI application, you just don't support that filter, and then the back end will be, and it will reflect what you can actually do. So you're thinking if a back end is something like Ym, or Python, et cetera, you can't do debas or whatever, you can't operate it with threads, you can't do anything particularly useful. We can send it standard input and pass standard error and standard out. So we can say, we can have a little system that just communicates standard out to internal package API. And we can send the process a signal when we want to quit. Now, a lot of packaging tools don't like being controlled seed, but in some cases that might be a sane thing to do. So we've got abstraction, which lets the back end, i.e. the thing that's talking to the distro package tool, when is it sane to allow it to cancel? So if it's some downloading, that's a pretty sane time to cancel, but if I'm installing, that's a pretty insane. So on threads, we can't just kill the thread, we probably should do a nice cancel method, stick it in a loop and kill the thread safely. And also we can get malicious and do stick quit, and then after a small delay, stick kill. So, error types. This is quite controversial as well. All the daemon is in C locale, which basically means we need to enumerate the errors and other messages to set types so we can localize them in the front-end. But we also probably want a description. So if it's a snap trace or something, or a back trace, et cetera, we can have it as a description, which is free text we could put in a bugzilla or something. And that's obviously not converted. So, for instance, out of memory, not supported, package not installed, and we can add as many errors as we need because they're just enumerated types, and we can just add tons and put them into the front-end and translate them. Now, another concept is a transaction ID. Now, that's something that identifies a present, past, or future transaction. And so when you actually ask for a transaction, you do fire and forget. That's a future transaction. A transaction that's running right now would be present and past something in the past. When you remember the past transactions, so if you're using a back-end such as Canary and you want to do a rollback, you can rollback to a certain transaction where you can see what you actually did. A transaction itself, per transaction, there is many sub-transactions. And so for a typical transaction, there might be, you might download two files, you might install one of them and update a third. So there's many sub-transactions per transaction. But the transaction only ever has one roll. And so the roll might be update system, or search name, or install from local package. But it does have different statuses. And so if the status value could be something like installing, downloading, this is useful for UI elements. So for example, a transaction ID could be something like just a free text number, a bit of random text, and then a checkpoint, which could be something like, which could map directly to the Canary rollback number, for instance. So what can we actually do? Again, not all of these are supported in all back-ends. You don't actually have to support any of them. With search names, search group, search details, search file, pretty obvious ones. Remove package, get dependencies, and also resolve. Resolve lets us basically see is a package installed, is it available, and it's a single file method. We can get details about an update, get requirements on a package, get a file list, et cetera, refresh any caches, et cetera, enable repositories, set data for repositories, and do service packs. So an offline CD, et cetera. But what do we actually get from package kit? Package kits obviously got to be quite abstract, and so we've got to put things into very sort of closely defined API. So it gives you progress. I like time, how much time things are going to take, percentage, et cetera. Any errors. Actually what it's doing right now, if anything requires a restart, and so a restart type could be session, i.e. you need to log out and log back in, system, you need to shut down and boot up again, or application, so you much need to close the application down and reopen it. Packages lets us see the package ID and summary, and the other two aren't that interesting. So that's the geeky bit. How do you actually use it? Easiest way, in the command line, so I can say pkcon is the default console client for package kit, and I can get an update list. You see 0.1 seconds. That's using, I think, other the dummy or young backend. I can search for stuff. Trivially. Now the same commands work on anything with a package kit backend. So if you're running Ubuntu, you're running Foresight, you're running Fedora, exactly the same commands will do exactly the same thing. But this is the more interesting bit. Now we've got this nice common abstract interface. We can do some really cool stuff. We can say, instead of making the user go and install the clipart himself, can we not install the clipart for them? And so this is, like, I guess what, five lines of code. It should basically show you how easy it is to install clipart. So you could do something like open office. You go to the clipart page, there's no clipart. Normally you see just a blank page. But you could say, there's no clipart installed. Do you want to install it? If you've got permissions to install the software, you do it without a root password, and you can do it in a sane way across distributions. So QT. QT has a nice front-end for this, just for searching packages developed by Adrian. It's not as polished as the known ones yet, but it's working progress. We also have known tools, and they seem to work a lot better. You can see I'm searching for stuff with Poe in the name there with installed, non-development, graphical, and it doesn't matter about being free. You see I've got description, far list, dependencies and required. So you can have dependencies going both ways. And also there's groups tabs. You can actually choose things by group. The groups, again, are enumerated, and so we can just add tons of enumerated types so that translators can just do a translation once and the daemon can abstract it into a nice set type. So we've also got preferences. Now, this can be very integrated into the desktop itself. So for now, we can say this is a typical GUI, but KDE could have it as part of their control panel, because it's all completely neutral in terms of desktop. So I can say I can hook into other session things like known power manager. I can say when I'm on battery, don't install updates. And if it's my mum using this, I probably want her to just install the security updates or any high importance updates. I don't want her to install everything. And I can also dispel notifications. So because it's fire and forget, we can actually say when you close the application and you've done a fire and forget method, you can say I'll just close the application halfway through. If you're halfway through downloading something, close the application, it still runs in the background, but I probably want to be notified using LiveNotify when the application is finished. I hinted earlier with the package signal we can return more interesting things. Now, we're trying to remove MathML fonts, which I didn't think I needed, and it's come up saying that actually an abbey word needs it, so rather than displaying a package and then a version and unintelligible stuff, we can actually say to the user what actually does it. Now, this text is localised, the abbey word word processor. The localisation, if it's not supported by the repository, we can get that from the desktop file or we can get that from Spexpo, so we can get this sort of localisation offline from lots and lots of different places. We can enable repositories. Now, this is yet another policy kit rule, and so I can say no one, apart from me, is allowed to change which repository I'm downloading from. It's a very abstract way that we can say that it's common between Fedora and Ubuntu. Now, this is one of the prompts. The wording's not brilliant, so don't go mad yet, but I'm trying to change a repository parameter and enable a repository. It's asking me for either the root password or I could make that the user password by changing a config file and I can remember it permanently or just for the session. By clicking on details, I can see exactly what's wanting to be done by who, more for debugging. Now, because you've got this nice abstraction, we can do some quite nice tools and we can have overviews, pages, and all the flashy stuff that MacoX has. We just design them once, and so we fix everything in one central place rather than in Fedora, Ubuntu, Suze, and all the others. We've got quite a powerful update description, so per updates, we can get the metadata from repositories and display things like bugzillas, CVE references, so it's all quite flexible. You see also, I could just from this page here do an update system, close the window, fire and forget it just does it. One of the things that makes it more complicated is if something like apps wants to ask you a question mid-transaction, that's banned, that's completely banned. Any questions you have to ask about the transaction has to be done before it or at the end. Actually, doing it halfway through destroys the concept of fire and forget. So, if I've got security updates, I probably want to be notified straight away and so I can get a notification like this. Because it's all session-side, it's localised, I can have a session preference. If I don't want to be warned because I know what I'm doing, I can just tick a little box on the right, but if someone else is using the system, they probably do want to be told. Obviously, this won't appear if it's automatically updating. There's just no point. Yeah, because it's per session. It's a per user because Ania might be using KDE and I might be using GNOME. So I can't really say that it's a session setting. I've got to answer more questions in a minute. Development itself is, I guess, pretty mad because we went from nothing to a substantial product in maybe five or six months. All the development we do is done on a private server. It's a good server, a good connection. Thanks, Ken. Thanks, Elliot. They basically provided the server so we can have a local repository. You're thinking, why is that important? We can say to developers, push and pull on this fast server all through the day, as if they're all working together, so the Ubuntu guys, Fedora guys get together, work on the same stuff. You can push and pull 20 times a day. And the best bit, you can create accounts. It doesn't seem that important, but if we're asking a new user with a patch to come along and say, okay, I need to go through the free desktop account procedure, that could take a few weeks. So what I say to people, if you've got a patch, I'll give you a comment. Now, that's quite controversial. But usually what happens is people have one patch to say fix the build or something. And because they've got commit, they have a real sense of power. They really, they're committed to the project now. They feel part of the project. And so I've found that very few people who have a comment don't keep committing. It's a great way to get people into the project. But with that means that anyone can check in practically anything into their repository. So what we do, once a day, we download all the changes from our core Git server. One of us checks them all. Does the code review. Just basic sort of security checks. And then I'll sync up the free desktop. So for Joe Public to sort of test out and play with. So last notice. We released 0.18, like a brown paper bag release about two or three days ago. We support Canary, Yum, App Box, Alp, Smart, O-Package, that one, Zip. And we ship by default in four-site Linux, which is already tons of users. And they can now develop a kit. So we already have tons and tons of users testing this stuff almost every day. It's going to be shipped in Fedora 9. We don't know if it's going to replace the Pirate and the other one, Pup. It'll probably be shipped alongside just for 9, just as a feature preview. But there's also quite a lot of interest from Ubuntu, OpenSUSE, OpenSolaris, Mandriever, and quite a few others that we just can't mention yet. But it's more in the pipeline. So, the release structure, we have rapid development, so there's lots of code churn, lots of ABI breaks, et cetera. We do at least a minor release a month just so everyone can have the latest code. There's about 15 of us, so I guess we're working on the core development. It's all GPL2, so it's very easy to implement into a distro. So, you're thinking, that looks fantastic, but actually, why should I use it? What's the point? I've got tools that already work. Because you can free up developers. If you've got developers that are just sitting there maintaining 15-year-old, 5-year-old tools that aren't going anywhere, you can free them up. We can work together. Okay, gnome translators do the gnome bit, KDE bits do the KDE bits. We can work together as a team rather than do per distro. We can get frontends for free. So if you have a distro, like, say, four sites, and you don't want to spend any time on the UI at all, you just do a little bit of code and you get everything that just works for free. And you only really need to provide a very small amount of support because all you've really written is a 900-line back-end interface. There's a thriving developing team. So if you mail the mailing list, we'll get a response back to you really quickly. So cool stuff we can do. If we're on a train on GPRS, we probably don't want to do an update. So we can detect that. We can do system and session inhibit. What that basically means is, per session, I can message the power manager and say, I'm doing an RPM transaction. I probably don't want to hibernate or suspend right now, and so I can stop it happening. That's great if you're using your own power manager. If you're using, say, KDE or you're not logged in, it also inhibits HAL, which actually stops anything in the session invoking the shutdown method on the power-save interface. So even if we haven't got a session running, we can still do a system inhibit to stop you hosing your RPM DB. So things we haven't got quite right yet. Time remaining. We don't actually know how long something is going to take, and so if I start updating my system and I've got a lecture in an hour, do I know this update is going to be finished before I leave my lecture? At the moment what we're doing is we're relying on the percentage changed information from the back-end, as if the back-end goes 1%, 2%, 3%, 4%. We can have a pretty good guess about when 100% is going to be, and so we can extrapolate that forward. But that's on the assumption that installing takes the same amount of time as downloading, and also that packages like Kernel take the same amount of time to download as Libsexy. We also haven't really got a good way of reporting bugs in back-ends, so you can have many transactions queued up very quickly, fire and forgets, there could be a bug somewhere which causes one of the transactions to fail, and we've got no real way of reporting that to say bugzilla or to the mailing list. Do we need to work on that? I think we've been tested for it, but we don't actually know how we're going to install service packs. We might just use something like GVFS and hook into the session stuff and detect when the CD has been put in of a certain type, and then run some sort of back-end, but we don't really know. That's all up in the air at the moment. So what have I said? I've discussed all the downsides, or the biggest downsides of the tools you've got already. We've seen how other operating systems do it, OSX, Winner's Vista. I've introduced package kit and the concept of a distribution specific back-end. I've shown you the console tools, the QT tools, the GNOME tools, and how I interact with the package kit. It seems quite obvious that any of the distros that are using package kit can share all this common code and this common expertise. And from looking at the blogs and Google, et cetera, it's quite clear that there's a very strong positive momentum with package kit. So I deliberately kept the question short, so I did presentation short so I can have lots of questions. So, fire away. Where's the Isroscope for System policy configuration location so that you can have a centralized config? Sure. Do you mean policy kit? Or do you mean policy kit where you can say which user does what? Or say things like your update frequency, your default update rule, so you can do that on a system-wide basis without relying on a running applet The problem is with a system-wide update. The package kit deamon only stays alive when it's needed. So if you wanted something system-wide you'd have to have a cron job that files off, say, a debuff signal just to say update on this day at this time if it's on a server. You could do that, that's no problem at all. The other question, the authentication question, yes, policy kit is per user, but it's also stored essentially per system. So an admin can define the roles that he wants users to be able to change, if that makes sense. Does that answer the question? So you could have your cron job passing the same information as a user applet would do if you wanted to hand over your system administration completely over to package kit. Yeah, you could use the pkcon in a script or in a cron job or anything, or you can use debuff directly. Next question. Package IDs, with package kits, you're letting package names out of this closed domain which is the distribution specific package naming. How do you propose to resolve distribution separate package? Yeah, excellent question, basically how can we have different, in Ubuntu you might have openoffice-bin and in Fedori you might have openoffice-common, etc. How can you do that? Well, in the example I gave with OpenOffice, only the distro knows the name they're going to call something. It's no good for me saying you must call the package disk because it's never going to watch. It just can't happen. So what I'm suggesting is, we use the upstream name and so something like OpenOffice would say install openoffice-clipart. Now if Ubuntu changed their openoffice-clipart to openoffice-clipart-common, they can trivially patch the openoffice source code to reflect the new name. I don't think we can sort of say that their package name has to be used between different distros because that'll be just a massive failure. Does that answer the question? Sure. Desktop files are useful for translations, icons, that sort of stuff, but they're not particularly standardised and they can often be more than one desktop file per application for something like known power manager would have, known power preferences, known power manager, known power statistics, that sort of thing. So you've got to be a bit careful with any heuristics you use. That makes sense. We can talk more in a minute if us. I don't know, that's easy. Anyone else? You mentioned that you've got questions that you need to ask the user, potentially upfront or afterwards. You didn't have to show any sense. How do you do that now? Sure. At the moment, there are questions. So imagine my mum's sitting at home using the computer and she's updating the system and LibC asks her if it wants to relink the system copy of the binary. That's useless. So my argument is that we should choose to default sane option by default and not tell anyone. And then at the end of the transaction say, there are more, there is more information about this transaction in this location if you're bothered. In fact, if you run this program you can maybe change the default. So I think it should be information rather than a question. If you're bothered about something you can go and do something about it. So just to go back to the package naming problem that the gentleman over there brought up even though a distro might change a naming scheme of a certain set of packages so it's no longer following the upstream naming. When you require that the upstream also require a distro also patch say open office to use the newer name you're introducing one more point of failure that things can go wrong and while you should say that maybe a distro should stick to the upstream naming scheme I have one comment for you or one word is git and seeing how bad that's cocked up in Fedora and that actually got fixed because they screwed up upstream we screwed up downstream and that was the end of the story. So by requiring a semblance to using the upstream package naming scheme doesn't that create more points of failure when you have to actually change it which inevitably every distro is going to do at some point or another. I think the question is can we guarantee the package is going to be the correct for the distro. In which case the distro is the only person have all the stakeholders in the argument that knows the package name. So if a bunch who calls something open-office-clip-art and then in the next long-term release call it open-office-clip-art-common we can say they know that this patch only applies for this distribution we can't really guess that we can't say you have to call it this because the logic has to stop somewhere. My argument is that the distro is the only person that knows what a package is going to be called. It's very difficult to say install this package that's provided by the file. You can do that in the API but I don't know if it's a good idea for things like Firefox, Firefox, bin, etc. Does that answer the question? Not really but you're right in the sense that we don't have any better solution I'm just wondering if that's being taken into account as well that there are more points of failure I'm expecting the distros if they're picking up package kit will be aware of applications that are installing their own files I think that's important for them to recognise. If they're using the upstream name they have to make no changes but I think they have to be aware of what's actually being done automatically. Does package kit provide API for applications to include a new backend or new repositories on the fly? Does package kit provide APIs for applications to add a backend or new repositories on the fly? Like say Firefox extensions being installed for package kit, updated and so on? That's a common suggestion At the moment you can only specify the backend, you can build multiple backends but you can only run one at a time The problem being when you have more than one backend running at the same time it's very difficult to do dependency resolution because package kit doesn't do it and so you have to rely on two tools to do essentially the same thing You do the dependency resolution You know what you're doing and I'll just do the pretty bit I'll do the common interface If we have two sources we don't really want to get involved in the dependency resolution with xp, karm or something from one repository and not the other With regards to the question for Firefox Updata I think that should be handled by the distro rather than by the application Firefox application itself using the correct name from the distribution's repositories rather than going to look on mozilla.whatever.org As soon as you let applications start adding their own backends you start getting horrible, horrible dependency problems Does that answer the question? Yeah, more or less I'm thinking about applications that we want to install stuff that's not used by rpms and packages like that So if you want to install something like I'm from Fluendo that's in the user directory that's not used in a package but it would be nice if that can be handled by a nice data system I think with package kit it's important to think of things per system I think as soon as you start looking at the problem per system and per session I think the problem gets much more complicated I do think there's a use case for that but I think it could be better if the fluendo stuff could be installed per system using package kit using an existing distro package for instance or using a repository which you add yourself because then you can do the updates from it yourself as well Thanks Very short question Is there any word on valabindings? Is there any word on valabindings? I saw it was written in g-object but are there any valabindings yet? Sorry, I really can't hear you Valab, oh my word There isn't but package kit itself is really just to debuff sort of multiplexing thing, it's really not that complicated and so valabinding would literally be something like just like a g-object binding like I've done in the source trait it'd be trivial after trivial, ten minutes work I have a more user question what I really don't like about pub and correct me if I'm wrong is the simple distinction between tracking of updates that's either all or just security can you somehow just subscribe to updates for only one application Yeah you could do but the question is why would you want to if a security update is available for distribution it's probably quite important you do it straight away No it's more just it's not unsecurity and maybe one or two applications that I'm interested in but not in all of the system In that case you can use there's an update viewer application which actually lists every single update individually and you can select which updates you want to imply one by one But that's manual, it doesn't warn me if something is available or something like that I can't see a concrete use case for only updating just the one application I can see a use case for not updating certain applications and maybe we can work that into somehow a package itself You've got to think a common use case is you've got to think if you try to solve every single use case every single part of the package is a problem you'd get a system that just cannot work up Well it's just about avoiding update everything and still keeping it so just track the one that you're interested in or the view and just avoid your risk to update stuff that you don't really that interested in Sure I guess you could do an update per repository until you could only enable updates for a single repository but I'm not sure it would be possible with package kits to do it per package I don't think that's too specific a use case there's no reason you couldn't use a right tool to do that in the package kit which is a simple geobject and that's a little object and do just that I'm going to call package kit sorry Anyone else? Hi I have a developer questions I've been looking how to create plugins for package kit there are some oversamplifications in the dependency handling for example in RPM you have these providers and a provider is a vitrary string for example so a package can require some web server string and this is not provided package in the world of repositories you have but in the package kit api for example every package has when you say get dependencies you actually you get the idea of the dependent package and this cannot be available at all or in the opposite case there are a lot of packages providing this dependency all of them will match which one should you give to the user and show this package depend on all of them or known what is going to happen with these simplifications So I think the question you are really asking is if you want just a web browser installed as a dependency how does package get to side which web browser to install If I browse for example in the package selector and I I select the package and I want to see more information about it what it depends on and there are a lot of packages providing this dependency What do you have to show to the user because package kit actually is enforcing one idea of the package you have to return and this package has to belong to that world So what you are saying is package kit is forcing a hard dependency on certain things Exactly Sure That's probably just a limitation of the api If that is useful for a general use case I think that is useful in the api At the moment we haven't found a use for that in an application So I think it is quite important with package kit concentrate on the use cases or for the common case rather than trying to bloat the api out for confusing the general case If we did need that for an application I have no problems adding that to the api Does that answer your question Yeah more or less Just My question was mostly about if you have different backends and they are giving you different results For normal for really basic users it might be sufficient but other people trying to use them trying to embrace the package kit tools they can get confused when they get strange results they are not used to I'll struggle to hear that but I'll answer what I think I heard I think can you want to summarize Can you just repeat the question really quick Sorry For example if I use the native tools in suze some package depends on web server package which is provided by a lot of them I will be able to see those alternatives or if there is none I will get an error there is no package providing this you have to find actually you have to return something and if there are multiple packages providing something you have to tell the user this package depend on all of them or selecting one of them which moves the policies to package kit itself Yeah it's a valid question but is it useful so if my mum is using a computer and she wants to install some sort of application sharing and she needs htpd or any web server to hear what she's using so if we choose a sane default a canary backend we've got an algorithm that chooses a sane default I guess that's distro specific chat a minute and we'll talk about it in more detail OK well that rounds up the question so thanks very much Richard