[packagekit] portage backends filters

Zac Medico zmedico at gentoo.org
Tue Jun 23 15:18:36 PDT 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mounir Lamouri wrote:
> Hi,
> 
> As most features of portage backend are now working, I want to go deeper
> in special case management. So, I'm in the way to choose the filters the
> backend will support.
> 
> Here is a list of filters the backend will not support:
> - development: -devel and -foo packages do not exist in Gentoo.
> - basename: same reasons
> - gui: it will be very approximative to say "this is a gui application".
> Maybe, further with a tag management.

Somewhat similar to tags, portage already supports something called
PROPERTIES. We could propose a new PROPERTIES=gui value.

> - application: same reasons
> 
> Here is a list of filters the backend will/can surely support:
> - installed: trivial
> - free: not too hard to now if a package is free

This might be another application for PROPERTIES (perhaps LICENSE
could possibly be used, but maybe it's not the best fit).

> - newest: will be harder for slots but can be done
> 
> And the interesting part it's the packages I'm not really sure about:
> - arch: according to filters doc [1], it's for multilib support (x86-64
> using x86) but it's not managed like that in Gentoo. So we can use it to
> "unmask" not keyworded files or use unstable packages. But as it's not
> really done for that.

This might be another application for PROPERTIES. We could use it to
tag packages that pull in 32-bit libraries on 64-bit hosts.
Something like PROPERTIES="amd64? ( 32-bit )"

> - visible: not really clear what it should be. I was thinking it could
> be used to unmask some packages.
> -> For these two ones, two things are difficult to get. I don't know if
> the way Gentoo can use them is really the way it should be used. I'm not
> sure using unstable packages or unmask packages in the gui is really
> good for user "security". Packagekit is probably not for people who want
> to use last unstable-in-development-highly-risky-but-so-powerfull app.

If you want to support this, you'll probably want to have the
backend call a program such as autounmask.

> - supported: i didn't get what it was for.

Gentoo does not provide paid support, but it might be useful if some
company wanted to do that. We would have to add some way for them to
tag this property in the package metadata.

> - source: Gentoo is mostly source based. There are some binary packages
> that can be installed. Some, like if it was sources (like
> mozilla-firefox-bin which is actually like mozilla-firefox but binary
> based). Others like rpm files.

Gentoo ebuilds behave like a combination of both source and binary.
Typical usage is to build the binary from the source and installed
the binary, all as a single operation. In my opinion, even things
like mozilla-firefox-bin shouldn't really be considered "pure
binary" packages, since portage already supports "pure binary" (tb2
files) packages which are an entirely different thing. It's possible
to use portage much like a binary package manager if you have
PORTAGE_BINHOST configured to download pre-built packages from a
binhost (this is not the most common usage for gentoo users).

> -> I'm not sure letting user to disable 99% of the packages (by setting
> not sources) is a good idea. In addition, binary packages is confusing
> in Gentoo as rpm-like files is easy to distinguish but binary based
> ebuilds aren't.

It's feasible to disable it if they have PORTAGE_BINHOST configured.
This is what the emerge --getbinpkgonly option is for (equivalent to
- --getbinpkg + --usepkgonly).

> - collections: they are some in Gentoo but they are somewhat done to be
> "transparent" so it's going to be difficult to manage them. I don't see
> a real need to have such filter. By the way, it's not in [1].

Maybe this is similar to meta-packages such as kde-meta or whatnot.
This might be another application for PROPERTIES.

> Finally, I don't see any special filter for Gentoo / portage which is a
> good thing ;)
> 
> For packagekit-list member, I'm sorry this message is pretty
> portage-oriented. It's much more for your information and to have some
> clarifications about some filters and have some opition. Especially Zac one.
> 
> [1] http://packagekit.org/gtk-doc/introduction-ideas-filters.html
> 
> Thanks,
> Mounir


- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkpBVLsACgkQ/ejvha5XGaNDFwCdFXvV8qdi/KIi0+hA0vRE6aXB
sD4AoNTfDa4WBK+9XiKK2hKRlKBlh7N6
=00ta
-----END PGP SIGNATURE-----



More information about the PackageKit mailing list