Listaller
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 199 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/32567 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Software developerComputerMomentumNumberMathematicsStudent's t-testCartesian coordinate systemIntegrated development environmentLecture/Conference
00:29
Electronic signatureFile viewerRepository (publishing)Distribution (mathematics)Cartesian coordinate systemComponent-based software engineeringPhysical systemSoftware development kitVideoconferencingGroup actionNatural numberService (economics)Bus (computing)DatabaseFitness functionClient (computing)CASE <Informatik>SmoothingStability theorySoftware developerDigital rights managementSystems integratorLatent heatImplementationDistribution (mathematics)Installation artDemonSoftwareComputer configurationRootScripting languageWritingInterface (computing)Cellular automatonOperating systemINTEGRALSystem callWeb portalCondensationProjective planePlug-in (computing)Process (computing)Open sourceWage labourStudent's t-testSampling (statistics)GodWordDifferent (Kate Ryan album)Physical lawComputer fileAreaCodeSolid geometrySpacetimeFile systemObject (grammar)Electric generatorUser interfaceMultiplicationBuildingAbstractionKernel (computing)Meta elementFront and back endsXML
08:06
Decision theoryMultiplicationLevel (video gaming)Distribution (mathematics)Vulnerability (computing)Repository (publishing)Order (biology)Electronic mailing listCartesian coordinate systemInstallation artComponent-based software engineeringTowerLink (knot theory)Product (business)Information securityTheory of relativityDivisorLibrary (computing)DatabaseComputer fileContext awarenessService (economics)Digital rights managementDistribution (mathematics)Computer configurationSymbol tableBus (computing)Graph (mathematics)SoftwareOpen sourceExtension (kinesiology)Mobile appProjective planeInterface (computing)Rule of inferenceWritingBinary codeGroup actionMereologyHome pageMatching (graph theory)CASE <Informatik>TrailPlanningAdditionStudent's t-testFront and back endsProcess (computing)Client (computing)Revision controlStandard deviationMultiplication signValidity (statistics)Software developerAddress spaceStreaming mediaMessage passingData structurePhysical systemMusical ensembleDescriptive statisticsInstance (computer science)OracleSystem administratorWrapper (data mining)MetadataModal logicInformationBitAbsolute valueData storage deviceGame controllerComputer iconTerm (mathematics)Software development kitResolvent formalismXML
15:42
MeasurementOrder (biology)Library (computing)Traffic reportingDifferent (Kate Ryan album)Student's t-testLink (knot theory)Right angleDigital rights managementNormal (geometry)Cartesian coordinate systemDirection (geometry)TheoryGraph (mathematics)Physical systemMessage passingPatch (Unix)Mobile appEmailMultiplication signInstallation artDirectory serviceSoftware development kitBinary codeComputer animationLecture/Conference
Transcript: English(auto-generated)
00:02
Our next speaker is a Debian developer, he is interested in upstream in packagekit developments and he made some contribution to desktop environment like KDE or GNOME. Today he will speak about ListTiller, which is a way to distribute third-party
00:22
applications based on packagekit. Let's applause Matthias. Can everyone hear me?
00:49
Is it better now? Yeah, of course. I want to introduce you to ListTiller, which is a simple and secure way to distribute third-party applications, as it was said before, or in other words it is another solution to create cross-distribution packages.
01:04
First of all, you might all know this one. I created with some others a cross-distribution packaging system, but we already have packaging systems. We have one in each distribution and we also have some who are aiming for a similar goal.
01:23
First of all, I should better answer the question, why do we need a cross-distro installation system at all? First, the main reason is that people want new software which is not available in their distributions. They have a stable base distribution and want the latest and greatest stuff to be installed and to try it out.
01:44
There are rolling release distributions, but they don't fit everyone's use cases because there are so many people who want a stable operating system which does not exchange the kernel or other components while it is running.
02:01
Also, there could be backports, but the distributor resources are usually limited and less people are interested in backporting stuff to a stable distribution, so there is a great lack of manpower and it also has some other issues when you try to backport something. There are of course third-party repositories which are called in the Ubuntu world PPAs, personal package artists,
02:26
but those are insecure and they can potentially break your system. For example, if the PPA packager introduces new packages which then get replaced by other packages from the distributor which are slightly different during an upgrade, your whole upgrade will fail and you will have a broken system
02:45
which is very difficult to recover, at least for users who don't have a technical background. Also, every packaging solution has the option to run scripts with root permission,
03:03
so if you install an application from a malicious source, you really don't know what this thing is doing unless you looked into it, but usually users don't do that before they install software because they want to see the software running and don't bother with the installation process and with reviewing a package.
03:24
Also, last but not least, PPAs are distribution-specific, there are many PPAs for new software which are only available for Ubuntu, but Fedora and Debian need different sources so it's lots of duplication, the OpenSUSE build service solves that partly,
03:42
but you still have to write lots of different spec files to package everything. Also, if you want to ship your software as a binary installer, you again have the problem that this will execute code during installation, which often happens with root permission, so it's not something we should be wanting to do.
04:01
So why is Listaller better in that regard? First of all, it was built with system integration in mind, that means that the user should never notice that Listaller is used when installing applications. Listaller applications should, when they are installed, integrate seamlessly with every existing application in the system,
04:22
so they should not look like foreign objects to the user. Also, software updates should be retrieved automatically using the same user interfaces as the system uses itself because sometimes if you are installing third-party stuff on Linux, you have another updater application
04:42
and this is really not user-friendly to do that, to have multiple sources to install software or to update your system. Of course, it should be cross-deci-compatible and it should be simple, which means that Listaller is not able to install basic system components like, for example, an init system or a toolkit or something which has reverse dependencies on itself
05:09
because Listaller was built solely for applications or so-called leaf packages and everything else which really requires integration by the distributor should be handled by the distributor
05:21
and not by the upstream project which is creating Listaller packages. Of course, it should be secure, which means that every Listaller package is usually signed. Signatures are checked against the hints database to see if it is a malicious signature or if the signature is known to be malicious and every application installed with Listaller will be sandboxed,
05:43
which will soon be possible using the KDBust stack which allows pushing large chunks of data into a sandbox using portals, but that's a different technology which is panning implementation. Listaller also provides developer tools, which means that developers get helpers to make the application run on multiple distributions
06:04
and packaging is really simple for them, which means they only need to write a small file usually and then they can get started with packaging. So after telling you all of that, you can imagine that Listaller consists of multiple tools
06:22
which can be divided into end-user applications which are, for example, as an application which sets up the sandbox and runs the application, an application to manage a database of trusted keys, lots of developer tools which handle different things from tracing dependencies to making the application relocatable,
06:43
which means that they can place it anywhere on the file system and it will still find its dependent data files. And also, of course, a generator for the Listaller packages and a tool to generate update sources and repositories to allow the creation, a theory, of Listaller packages, of Listaller repositories, which target the whole Linux market.
07:07
So you set up a repository with Listaller packages and every Linux distribution can embed it and can use it. So how does this work? Listaller is actually a packagekit plugin, which means that it runs inside packagekit.
07:20
Packagekit, for those of you who don't know what it is, is a tool which is a DBOS service which takes requests from clients via software centers, package managers, or update viewers and then performs an action on the native distribution interface, which means that packagekit has plugins which get called by the DBOS daemon running as root
07:44
and then they get asked to perform the actual action on the native distribution package management interface. So Listaller now hooks into this by creating some kind of meta backend between the native backend and the packagekit abstraction.
08:04
So if packagekit receives a request to install a Listaller package and Listaller notices that inside packagekit it will perform the installation of the new package and send all information about this new package via the packagekit's DBOS interface back to the clients.
08:22
So for the clients it doesn't matter if they install a Listaller package or a native distribution package because for them it just doesn't matter at all. If there is a native package, of course, Listaller will let it through and let the backend perform the appropriate action.
08:41
Listaller can also query the backend instance directly, which means that Listaller has the opportunity to talk directly to the native distribution package manager and resolve dependencies and install missing dependencies if necessary. Speaking about dependencies, in order to make Listaller work on multiple distributions
09:06
and to have dependencies, which is something we want at least for basic dependencies like GDK because if you link the whole toolkit statically and the distributor pushes an update which fixes a critical security hole
09:24
and you have an application running on your system which has, for example, the toolkit statically linked you won't get that security fix into production because the statically linked application will still use that old library. So it is a good idea to have at least some base level of dependencies.
09:43
And in order to resolve dependencies using the native distribution package manager on multiple distributions Listaller relies on so-called components which define the interfaces an upstream project provides which binaries, which libraries, and in which versions it does that.
10:01
Ideally it also ships a simple file so we can check if the ABI compatibility is given. Then Listaller will use this component file to actually find the right dependency in the distribution database. So it, to some extent, depends on upstream projects to write component files. But there are some workarounds, but because this is a lightning talk I can't go into detail.
10:25
So let's walk through the process and package BloatPad after reading the GNOME developer documentation our developer decides that this is a good idea to create a package for that. In order to do that we need to do a few things. First of all, write an AppData file.
10:42
AppData is part of the upstream effort to create cross-distributional software centers and if you ship an AppData file your application will be represented better in any software center because we will have more metadata to take into account. So an AppData file is just a small bit of XML which defines the project summary, a description, the name, a desktop file, a home page, etc.
11:09
and some other stuff. Listaller will take this file to present the application to the user and say yes, you're installing this thing right now and later it will also inject that data into the upstream database
11:23
so every AppStream aware software center is able to display the Listaller application just like any other application which was installed from a native distribution source. Then you need to write a few rules in how to compile your application. This can be done using AppCompile here
11:41
because AppCompile is a small wrapper which will detect your build system and build the stuff. It works with a few build systems so far but you can also add all instructions on how to build your applications manually there. Then you need a file listing. Listaller does not use any absolute file path.
12:01
Instead it uses relative file paths where you can place your application in. During installation, Listaller will then decide depending on the distribution's policy where to put the application files and therefore the distributor in the end controls how everything is installed.
12:20
You also need to write a so-called PK options file which just defines how the package creation process will be done and which version of the packaging standard you will want to use. Then you just need to generate your package which will automatically run Devscan which is a small tool to detect all dependencies your application has
12:41
and then match them with two components using the component interface definition I've shown you before. In this case we, for example, detect gtk3, glib, xorg, an icon theme and gstreamer because this thing is called loadpad. Then it will just generate the package structure and sign the package
13:01
and run Lilith which is a small tool to validate pieces of the upstream work in order to get a high quality package and to tell upstream, hey, you're doing this wrong, maybe fix it next time. By doing that we can address one of the concerns of distributors
13:20
that upstream projects might create crappy packages because Listaller won't allow doing that and if there are some minor tweaks which can be done then it will warn the upstream developer about that. So in the end you have a package. This can then be installed by the user using the native package kit package management tools
13:42
or using tools which are dedicated for installing Listaller packages but the long term plans are to get rid of these. There is an extension to package kit which will be done in a few weeks which might render the additional interface completely obsolete.
14:04
Listaller will then search for native packages which declare that they support the missing components and install them. If Listaller is unable to satisfy dependencies using the native package manager it can also fall back to get dependencies from other sources
14:21
if it is configured to be allowed to do that because the systems administrator might not want that Listaller tries to satisfy the dependency from potentially untrusted sources like third party repositories in order to satisfy the application's dependencies. Then in the end the user wants to run BloatPad
14:42
sorry, execute to run a BloatPad which will set up the sandbox and do some other crazy stuff so the application is able to find its dependencies. Then this thing right now only supports older Desofile the older Desofile standard sooner it will also support the new Dbus activated applications
15:02
which is the new way to store applications at least in the future. Developers can also create update repositories which is also pretty simple and straightforward in order to generate an App Store-like feature and in our example our user decides to remove BloatPad
15:23
so he just opens Apple on KDE the tool he is used to use to work with packages finds BloatPad there and hits the uninstall button and it's just gone without any problems. And that's it.
15:46
We have time for a quick question maybe? I see.
16:02
So if I understand you correctly you ship binaries but how do you solve the problem of installing in an arbitrary directory because you said you don't specify which directory it has to be installed but then you have a problem with libraries and they don't know where to find libraries and things like that. Well there are two approaches to that in installer
16:22
one is patch elf which will change the elf header of the binary which is really ugly so the preferred way right now is that the run app application sets the library path for the new libraries and therefore makes the application find its libraries if they are living in a different directory.
16:41
I'd be interested to talk to you about that. Hello, one quick question. I don't know if you already said it but can you use a native package management system like apt-get to install the installer packages?
17:00
No you can't because then the native package management system would have to link again to the installer in order to be able to do the same as package kit does right now. It is a theory, it's possible but I don't think the upstreams of native package managers want to do that right now at least.
17:22
Last question? Okay, Matthias will give another talk on this topic tomorrow morning this will go upstream in Insta Wars and it's at 10 o'clock.