Re: [gentoo-guis] Why I don't like catapult

[René 'Necoro' Neumann]

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

Ciaran McCreesh schrieb:
>
> Sounds like you need a layered architecture. A low level catapult to
> package manager layer, and a high level package manager independent
> extras layer.
>

Currently working on transforming it ... Will post the results later on :)

>> Ok. Perhaps we can postpone this until it gets real. (And then perhaps
>> use scpvr's ;) ... like: cpan:bla-foo/SomePerlPkg-0.13)
>
> Paludis does it already.
>

So we can set it as the package format? (Though needing further
definitions.)

>>> Paludis supports multiple configurations. You can, for example,
>>> have /etc/paludis, /etc/paludis-mychroot and
>>> ~/.paludis-anotherchroot, and Paludis can operate with all of thse.
>>> Paludis can also operate on systems where there's no configuration
>>> -- for example, you shouldn't need a full config setup just to be
>>> able to run QA checks on one particular repository.
>>>
>>> Portage also sort of has some of this in a very crude way, through
>>> PORTAGE_CONFIGROOT.
>> As catapult only queries, this can be resolved _inside_ the paludis
>> provider.
>> This of course gets hairy if it comes to libcatapult to provide
>> config-file manipulation...
>
> How does Paludis know which configuration set it should be using to
> respond to queries?
>

Ok - so we need sessions ...

I see two possibilites to implement it:
- - pass it as a parameter each time to each function ... Problems:
	+ each function needs an additional parameter ...
	+ how and what to pass using DBus? - I only can think of id-strings ...
but this leads to the second possibility
- - use the unique dbus service name and store sessions internally: see
http://lists.freedesktop.org/archives/dbus/2008-March/009550.html -->
now it is back to provider logic

In other words: The provider, which needs sessions, can use an internal
hashmap with the dbus service name of the client as the key and store
the data. This service name is defined to be unique as long as the dbus
bus is running. -> No need to support sessions in the official API.

>> A "set" is a "set of packages" for me. You mention a "set of specs" -
>> don't get what kind of "specs" you are referring to here.
>
> A set isn't a set of packages. It's a set of dependency specifications
> (foo/bar or >=foo/bar-2 or whatever).
>

k - understood

>>>>> - find_packages. As find_best_match for search key. What
>>>>> disambiguation is performed upon the atom? What happens if you
>>>>> pass it something like 'git', which is ambiguous?
>>>> Return everything that fits. It should be on the users side to
>>>> translate it into something useful.
>>> That's messy.
>> Why? - It's a search function. And I guess in most cases the "return
>> everything that matches" is in case intended.
>
> Have a look at what existing tools do when given an ambiguous package
> name part. They generally error, not do everything. Coding various
> things gets tricky when you have to manually check that you've only
> been given a single package name.
>

As written above, I'm currently working on changing this.

>>>>> - get_config_path. Unportable. What if the user is using some
>>>>> other config format?
>>>> But the configs (read: package.mask, package.use etc.) have to be
>>>> at a specified unique location, don't they?
>>> For Paludis? No. NoConfigEnvironment, for example, uses no
>>> configuration directory at all.
>>>
>> This really is an issue... And what is happening if the user wants to
>> set an option (e.g. a useflag) in the "NoConfigEnvironment"? - Is a
>> config directory created and the environment switched?
>
> No. Users can't set options in NoConfigEnvironment. There is literally
> no configuration beyond the constructing parameters.

For the moment we can remove this call. But as soon as we want to have
libcatapult to provide a central place to allow config file changes, we
need a solution for this problem.

>> Nevertheless, I want to provide applications with the ability to run
>> a package manager with different option switches which follow some
>> global semantics. Or do you think, something like this is just not
>> possible and we have to look for another way of doing so?
>
> Doing this via an exec() is the wrong way to do it. If you want it to
> be sanely usable you need to do it via a proper API.
>
>> Think of the following use case: An application provides an interface
>> that allows users to select a package for installation. Now this
>> application uses catapult and wants to query for the command which has
>> to be run to get this package installed. Using get_merge_command, the
>> app could do:
>>
>> spawn(catapult.system.get_merge_command(), package_list)
>>
>> Catapult isn't the system merging here - it just provides the
>> information to actually _do_ the merge.
>
> Which is the wrong way of doing it. You might as well ask for a command
> that outputs DESCRIPTION for a given ID rather than providing an API
> call to do it directly.

That's true. But I want it for three reasons:
- - no security issues
- - safe way is more important than nice way: In case the information
catapult provided (e.g. dep tree) is not correct (for whatever reason),
I don't want it to crash the users system. Thus, it is better to let the
package manager to have the final say. - This reason gets obsolete if
the providers are maintained by the package manager teams themselves,
but this is not the case atm.
- - at least in portage I can't see a way to say "hey - portage: install
the following packages please", as the logic behind this is done in
emerge itself.

Is there any other reason to vote against this besides "isn't the nice way"?

>>>>> - split_cpv. Why the weird revision thing?
>>>> What's so weired about it?
>>> Why is the revision considered special?
>> I'm waiting what's the result of the "-r0"-thread on gentoo-dev before
>> giving an anwer ;)
>
> Doesn't make much difference either way... Why is the revision the only
> version part you treat specially?

We could also return "" instead "-r0" if no revision is given. Does not
make a difference.

>> We have the following cases:
>> 1.) "DEPEND" is a fixed catapult term/constant. Then the provider has
>> to map to "DEPENDENCIES" if it encounters the term and EAPI2 is used.
>
> Not doable. DEPENDENCIES can't map to DEPEND. DEPEND isn't powerful
> enough syntactically.

Now I see, why you want the user to know of the EAPI... Do you think it
would be enough to allow to query the EAPI value of a package? Then
(taking this example) the client can decide whether to ask for "DEPEND"
or "DEPENDENCIES" depending on the EAPI.
If for some reason, he asks for "DEPEND" and the package uses EAPI2 an
EAPIError or something similar is being thrown.

>>>>> And what's the return value? What about when || is in operation?
>>>> WWPMD (what would the package manager do): Simplified: Pass the
>>>> dep-string to the package manager and see what he does with it. The
>>>> result is returned.
>>> The package manager has to have special handling for || throughout.
>>> The behaviour of || blocks is rather tricky.
>> I guess it is a major problem if the package manager isn't able to
>> handle "||", right? - So I can't see your point here.
>
> The package manager handles || on a case by case basis. Anything
> containing || cannot be flattened to a simple list.

When installing the the package the package manager is taking one of the
choices of "||", based on certain information. A similar approach should
be used here too.

>>>>> - get_iuse_flags. What does this do for IUSE defaults? For
>>>>> installed packages, all flags are forced.
>>>> defaults are returned verbatim. I used to define "forced flags" as:
>>>> "The flags the user can't change." (like userland_GNU or
>>>> use.mask'ed flags)
>>> The user can't change any flags for installed packages.
>> True. But he can re-install it using the changed flags. (Though he
>> isn't using the flags of the installed packages here, but the ones of
>> the uninstalled and overwriting the installed one.)
>> In other words: For this use case, the useflags of installed packages
>> are not seen as "forced flags" per se.
>
> They are forced for the installed ID. They aren't necessarily forced
> for other different IDs that can be installed to replace the currently
> installed ID.
>
> The foo/bar-2.0 that you have installed is a completely different ID to
> any foo/bar-2.0 you happen to have in a repository somewhere.

Postponing this ... have to think about it.

>>>>> - get_masking_reason. Is the return value supposed to be used by
>>>>>   anything other than a human?
>>>> I doubt it.
>>> Specify that.
>> I guess I'm again missing something ;). But I can't see, why it
>> matters if it is intended for human readers or not :). And if there
>> _is_ a difference, there should be no problem in adding a
>> "for_humans" boolean argument to this call. :)
>> Though I don't know, what the masking reason should look like for
>> non-human targets.
>
> If it's intended to be machine usable, the format has to be fixed.

So let's decide to have it human readable only.

>>>>> - get_overlay_path. What if it's in an overlay with no on-disk
>>>>> location? What if it's in some format the end tool doesn't
>>>>> recognise?
>>>> The end tool's problem I'd say.
>>> You're providing API calls that make this sort of thing difficult.
>>> Not an ideal situation...
>> Just return some kind of an URL. The end tool has to deal with it.
>
> Then the name needs changing, and it needs to be documented that the
> return value is entirely meaningless.

Name change ok - perhaps s/path/url/ ?

"entirely meaningless" - I would use "might be meaningless" instead.

>>>>> How does the whole privs thing work? Should anyone who can talk by
>>>>> DBus be allowed to perform privileged operations? Should anyone
>>>>> who can't perform privileged operations be allowed to do
>>>>> unprivileged operations?
>>>> I thought of having Catapult being a passive thing. So there is no
>>>> way of doing privileged actions.
>>> Things like querying an uncached package are privileged.
>> Yes? - Why? Any user can open an ebuild and have a look at the
>> internals.
>
> But they can't write to cache on disk. Remember that Portage needs you
> to be in the 'portage' group to do anything, and anyone in the
> 'portage' group can easily obtain root on the box.

Nope - you can query even if you are not in the portage group.

Despite the current open issues (btw: I tried to collect them on a wiki
page: http://catapult.origo.ethz.ch/wiki/current_issues ), do you think
that the whole system can be brought to something useful in the end?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH8kJ+4UOg/zhYFuARAjGOAJ9P4D5kZBJPu5FgS7ONmXw7T7E6kACaA0IU
YNS2iJrPw7gxB8dJy8U/mEY=
=UAQ9
-----END PGP SIGNATURE-----
-- 
gentoo-guis@l.g.o mailing list