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

[Ciaran McCreesh]

On Sun, 30 Mar 2008 19:30:24 +0200
René 'Necoro' Neumann <lists@××××××.eu> wrote:
> Ciaran McCreesh schrieb:
> > * use of cpv throughout. cpv isn't enough to uniquely identify an
> > ID, especially if there're overlays. cpvr is closer, but still
> > doesn't work if you need to deal with virtuals directly (rather
> > than the thing provided by the virtual)
>
> CPVR sounds reasonable ... and what about using virtual/* for
> virtuals? Btw: There was the idea of providing a "get_virtuals"
> function....

The issue with virtuals is that all the package managers do them a bit
differently. For Paludis, if you have two different providers of the
same virtual installed with the same version and slot, you'll get two
IDs that have the same cpvr and that are only distinguished by the
package for which they are a virtual. This isn't an issue for us since
we use a different PackageID instance for each, but if instead you're
using a string to identify things (eww) you're in trouble.

> > * use of regexes throughout. Every language defines its own,
> > different regex dialect. There's no portability between languages.
>
> True - I thought of using some kind of globbing - thus only allowing
> "*" and "?" (and perhaps "^" and "$")

Why support it at all? That's not something that should be in at the
package manager level.

> > * No mention of EAPI anywhere.
>
> Why would this be needed? This is only true if "catapult API" ==
> "EAPI".

Well no. When doing pretty much anything with IDs, you have to be aware
of the EAPI. Client programs mustn't attempt to do anything with IDs
whose EAPI they don't recognise.

> > * Generally lots of hard-coded ebuildy things that don't map well
> > onto future EAPIs or handling of non-ebuilds (e.g. native CRAN
> > support).
>
> For me - gentoo package management is all about ebuilds. So I can't
> see, what should changed there.

Future-direction-wise, a lot of people are wanting to handle things
like CPAN, CRAN, Gems etc natively in the package manager rather than
by writing wrapper ebuilds.

> > * It's tied onto a single user configuration setup, and has no sane
> > way of handling multiple configurations or unconfigured operation.
>
> I don't understand this ...

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.

> > * sets don't map on to package manager sets.
>
> This can easily be changed. But nevertheless, some catapult-wide sets
> should be defined, that map onto the specific ones in the package
> managers (e.g. catapult.SET_ALL should be replaced by the specific set
> in the different managers)

I'm not really sure that your concept of sets is right...

> > - find_best. What does this do if you give it foo/bar-1 foo/baz-1?
> Undefined atm.
> >   What's the point of having this function at all?
> See very first remark.

Sure, but you should still define your API in such a way that it's
easily generalisable and maps well onto the underlying data.

> > What if only_installed is false? Does this mean we
> >   want both not installed and installed stuff?
> Yes. - But perhaps, instead of the "only_installed" flag used here and
> there, a set-name should be provided. (Which then can be "installed",
> "uninstalled" or whatever).

Again, set confusion. Are you viewing set as a collection of IDs or a
collection of specs? (It's the latter.)

> > - 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.

> > - 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.

> > - get_deep_option. Deep's a mess; making package managers emulate
> > it via a command line switch is silly.
> If you don't have an equivalent: Return "".

It shouldn't be in the API at all though.

> > - get_merge_command. There's no nice way of using whatever this
> > returns. And it's pointless -- why not just ask the package manager
> > to do the merge?
> Because catapult should be passive: I.E. only provide information and
> does not do anything that could be harmful.

Then it shouldn't even try to provide a way to do the merge stuff. It
needs to either do this properly or not at all.

> > - get_newuse_option. Again, unportable and messy.
> >
> > - get_oneshot_option. Again, unportable and messy.
> Why unportable? - See the remarks to "--deep".

Neither maps on exactly to the Paludis resolver. The Paludis resolver
is quite a bit more flexible option-wise than what Portage offers, but
there's no exact correspondence between options.

> > - split_cpv. Why the weird revision thing?
> What's so weired about it?

Why is the revision considered special?

> > - What do all of these do on unknown EAPI?
> Again: Why does the API have to care about EAPI? - It's the providers
> job to care about it.

If you perform an API call that works on an ID with an unknown EAPI,
what's supposed to happen? What about if you perform an API call that
works upon an ID with an EAPI known to the package manager but not to
the tool?

(One example: what happens if we go with DEPENDENCIES for EAPI 2, and if
you ask for DEPEND on an EAPI 2 package?)

> > - compare_version. But it takes packages. What's the ordering on
> >   foo/bar-1 vs bar/baz-1?
> Currently it would return: ("bar-1", "baz-1") as bar < baz. But this
> can easily specified different. And a good point to think about error
> handling again.

Why the ordering on PN rather than CATEGORY/PN?

> > 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.

> > - 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.

> > - get_masking_reason. Is the return value supposed to be used by
> >   anything other than a human?
> I doubt it.

Specify that.

> > - 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...

> > or when expanded keys aren't known.
> When should that happen?

Installed packages. USE_EXPAND wasn't (and still isn't by some package
managers iirc) saved to VDB.

> > What's the point in using DBus? What does it add over a simplified
> > library with bindings?
>
> Library bindings have several disadvantages:
> - - Providers have to be coded in C.
> - - How to access portage internals from C-Code? Yes: You can
> implement python-calls in C... but I think this is messy.

You can do the translation either way.

> > 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.

> > What about persistence? What's classed as a session? Why force it
> > down to a single session at once?
> Easier to implement. But it isn't forced. If the provider implements
> sessions (e.g. using the Dbus-sending-adress as a key) w/o extending
> API, I can't see a problem.

But without well-defined session management, you're stuck when it comes
to multiple configurations and the like.

-- 
Ciaran McCreesh