[pacman-dev] Improving -Qi/-Si code
Allan McRae
allan at archlinux.org
Mon Dec 30 00:13:42 EST 2013
On 30/12/13 15:06, Simon Gomizelj wrote:
> We actually do not need to maintain two tables. I've merged it with
> pacman currently and I don't take that approach. I only did it with
> alpm-dump because it was quicker to just dump out statically initialized
> tables for testing. Was probably a poor choice for a demonstration.
>
> I have a table building function instead, along the lines of:
>
> void build_table(char **table, alpm_pkgfrom_t from)
> {
> memset(table, 0, sizeof(char *) * LAST_ENTRY);
>
> table[ENTRY_REPOSITORY] = _("Repository");
> table[ENTRY_NAME] = _("Name");
> table[ENTRY_VERSION] = _("Version");
> table[ENTRY_DESCRIPTION] = _("Description");
> table[ENTRY_ARCHITECTURE] = _("Architecture");
> table[ENTRY_URL] = _("URL");
> // snip
>
> if(from == ALPM_PKG_FROM_SYNCDB || config->op_s_info > 1) {
> table[ENTRY_REQUIRED] = _("Required By");
> table[ENTRY_OPTIONAL_FOR] = _("Optional For");
> }
>
> // more branches
> }
>
> So rather, the actual effective change, as far as design goes, is this
> allows us to break dump_pkg_full into two discrete steps rather than all
> at once; figure out what to print before you start printing.
>
OK - that sounds good to me.
> In fact, all this table building stuff can entirely stay inside
> package.c if we change dump_pkg_full to expect an alpm_list_t * instead
> of a alpm_pkg_t *. It doesn't need to be exposed to sync.c/query.c (I
> think, I'm not fully confident I've integrated the new system
> everywhere).
I'd have no objects provided it makes sense to always pass a list (I
would need to look at what pacman is passed in single package case).
Otherwise you could add dump_pkg_list() and call the
dump_pkg_{list,full} as needed.
I await the final patch submission.
Allan
More information about the pacman-dev
mailing list