From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Jflrw-00039b-FR for garchives@archives.gentoo.org; Sun, 30 Mar 2008 00:57:56 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4F23BE04FB; Sun, 30 Mar 2008 00:57:55 +0000 (UTC) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.228]) by pigeon.gentoo.org (Postfix) with ESMTP id E8959E04FB for ; Sun, 30 Mar 2008 00:57:54 +0000 (UTC) Received: by hu-out-0506.google.com with SMTP id 23so3103550huc.1 for ; Sat, 29 Mar 2008 17:57:54 -0700 (PDT) Received: by 10.67.24.18 with SMTP id b18mr999543ugj.65.1206838673976; Sat, 29 Mar 2008 17:57:53 -0700 (PDT) Received: from snowcone ( [213.121.151.206]) by mx.google.com with ESMTPS id s8sm907588uge.3.2008.03.29.17.57.52 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 29 Mar 2008 17:57:53 -0700 (PDT) Date: Sun, 30 Mar 2008 00:57:41 +0000 From: Ciaran McCreesh To: gentoo-guis@lists.gentoo.org Subject: [gentoo-guis] Why I don't like catapult Message-ID: <20080330005741.48243ed8@snowcone> X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Graphical User Interfaces Project X-BeenThere: gentoo-guis@lists.gentoo.org Reply-To: gentoo-guis@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/FPFv9RMD=GNhnNLkZw9FNiw"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 67b462c3-f70a-4514-a873-00edee68f38c X-Archives-Hash: 05789f7c42f85c698453da9e5ac26f5a --Sig_/FPFv9RMD=GNhnNLkZw9FNiw Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Since all catapult discussion appears to be happening here, and I don't feel like registering from some forum that may or may not be read... Catapult, as it stands, probably isn't sanely usable in general and definitely isn't usable for Paludis. Here's why. The API is Broken ----------------- * 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) * use of regexes throughout. Every language defines its own, different regex dialect. There's no portability between languages. * No mention of EAPI anywhere. * No mention of error handling anywhere. * 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). * Essentially an abstraction of Portage internals, rather than an abstraction of a general package manager. * It's not clear how much of the API would be useful, or that the API provides enough to do something useful. * It's tied onto a single user configuration setup, and has no sane way of handling multiple configurations or unconfigured operation. * sets don't map on to package manager sets. * Administration: - version. But no name? * System: - find_best. What does this do if you give it foo/bar-1 foo/baz-1? What's the point of having this function at all? - find_best_match. What's a search key? If it's a spec, it needs an associated EAPI. What if only_installed is false? Does this mean we want both not installed and installed stuff? - 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? Regular expressions at this level is silly -- which of the zillion regex flavours do we use? Does it operate on installed, not installed or what? - get_config_path. Unportable. What if the user is using some other config format? - get_deep_option. Deep's a mess; making package managers emulate it via a command line switch is silly. - get_environment. In no way portable. - get_global_key. Again, unportable -- Paludis has no notion of global configuration. - 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? And what about package managers that require an explicit --install? When you ask for --sync or whatever, off what do you base the command? - get_newuse_option. Again, unportable and messy. - get_oneshot_option. Again, unportable and messy. - get_pretend_option. Again, unportable and messy. And probably useless -- what would you do with this? - get_sync_command. What's the point? Why not just ask the package manager to do the sync? - get_unmerge_option. Same. - get_update_option. Same as for get_deep_option. - get_updated_packages. Highly unclear what this really does. - get_use_desc. package should be a cpvr. - get_world_file_path. Unportable. - list_categories. String or regex? - sort_package_list. You don't want stuff sorted the way it's sorted by Paludis. You might want a well defined sort. - split_cpv. Why the weird revision thing? - update_world. Huh? In some ways pointlessly specific, in some ways way too vague. And what's this use flag stuff? We finally just about got people away from setting use flags in places other than config files, and for good reason. * Package - What do all of these do on unknown EAPI? - compare_version. But it takes packages. What's the ordering on foo/bar-1 vs bar/baz-1? - get_actual_use_flags. What's the point of this? - get_dep_packages. Hardcoding three dep classes is icky and doesn't work nicely with future EAPIs. And what's the return value? What about when || is in operation? - get_global_settings. No such thing as a global setting. - get_iuse_flags. What does this do for IUSE defaults? For installed packages, all flags are forced. - get_installed_use_flags. Empty list? Seriously? - get_masking_reason. Is the return value supposed to be used by anything other than a human? - get_matched_dep_packages. Huh? - 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? - get_package_path. Ditto. - get_package_settings. What do you mean by everything? Just metadata? And what about EAPI? Some things don't make sense for some EAPIs or some package formats. - get_use_flags. Bad. No legit use. - is_in_system. System is a bad name. - is_testing. How does package.keywords alter whether a package is testing? - use_expanded. Not clear how this works when things aren't really expanded or when expanded keys aren't known. Why DBus? --------- What's the point in using DBus? What does it add over a simplified library with bindings? 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? What about persistence? What's classed as a session? Why force it down to a single session at once? --=20 Ciaran McCreesh --Sig_/FPFv9RMD=GNhnNLkZw9FNiw Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFH7uWM96zL6DUtXhERAvLIAKCE82h+VzBn8YJqp5wtGaEKkNi9jwCdH5C7 hdbJZ4C5VwFDBoF7baLo+90= =KyPy -----END PGP SIGNATURE----- --Sig_/FPFv9RMD=GNhnNLkZw9FNiw-- -- gentoo-guis@lists.gentoo.org mailing list