[pacman-dev] crappy version of -Qu (query upgrades)
Dan McGee
dpmcgee at gmail.com
Mon Aug 27 10:20:13 EDT 2007
On 8/27/07, Xavier <shiningxc at gmail.com> wrote:
> > > -/* TODO reimplement this in terms of alpm_get_upgrades */
> > > -int _alpm_sync_sysupgrade(pmtrans_t *trans, pmdb_t *db_local, alpm_list_t *dbs_sync)
> > > +/** Get a list of upgradable packages on the current system
> > > + * @return a pmsyncpkg_t list of packages that are out of date
> > > + */
> > > +alpm_list_t SYMEXPORT *alpm_sync_sysupgrade(pmtrans_t *trans,
> > > + pmdb_t *db_local, alpm_list_t *dbs_sync)
> > I don't know why, but I seem reluctant to change the return type here,
> > unless we can no longer really error in this function.
> >
>
> Should I add an extra argument for the return list then, to both sysupgrade
> and find_replacements ?
> An alpm_list_t **list ?
>
> > > + syncpkgs = _alpm_find_replacements(trans, db_local, dbs_sync);
> > Same here- can _alpm_find_replacements never fail anymore?
> >
>
> Indeed, I thought about this problem. See my question above :)
That might be the best solution, and then ensure you set the error
value as necessary. Of course, if an error can be specified well
enough by simply having a NULL return instead of syncpkgs being set,
then I guess there isn't too much of a problem there. Basically I'm
indecisive.
> > > diff --git a/lib/libalpm/sync.h b/lib/libalpm/sync.h
> > > index ef094b5..0d91d25 100644
> > > --- a/lib/libalpm/sync.h
> > > +++ b/lib/libalpm/sync.h
> > > @@ -35,7 +35,6 @@ struct __pmsyncpkg_t {
> > > pmsyncpkg_t *_alpm_sync_new(int type, pmpkg_t *spkg, void *data);
> > > void _alpm_sync_free(pmsyncpkg_t *data);
> > >
> > > -int _alpm_sync_sysupgrade(pmtrans_t *trans, pmdb_t *db_local, alpm_list_t *dbs_sync);
> > Not sure why we should move something that is sync specific out of the
> > sync header.
> >
>
> I thought public functions should be in alpm.h , and private functions in
> other headers.
> Maybe I should keep _alpm_sync_sysupgrade private then, and add a public
> wrapper as alpm_sync_sysupgrade ?
Well actually ignore my original comment. Now I see it is trans.c that
has always been weird with its alpm_trans_sysupgrade function. Perhaps
that should change (probably post-3.1).
A wrapper function might be best for now, and that way we don't have
to deal with the NULL trans argument (just leave that out of the
wrapper).
-Dan
More information about the pacman-dev
mailing list