[pacman-dev] Frugalware changes merged.

[Aaron Griffin]

Out of order:

On 10/19/06, VMiklos <vmiklos at frugalware.org> wrote:
> > Bindings are here:
> > http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/bindings/?cvsroot=Pacman
> > What do you mean?

> > > 3) po4a support as been added to doc/Makefile.am, but the translations
> > > in /doc/po/ are missing
> >
> > Not sure what you mean - the only translations I have from the patch
> > are hungarian.

> > > 10) i think you forgot to cvs add the /pactest/tests/ directory
> > They show up for me:
> > http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/pactest/tests/?search=None&hideattic=1&cvsroot=Pacman&only_with_tag=HEAD
>
> hmm. maybe this is a cvs bug - or God knows, this is the 3rd missing
> directory after cvs update

Can anyone else reproduce this? It's possible I'm just cvs-inept and
missed something important - but they show up in viewcvs....

> > > 4) you left several NoUpgrade files in pacman.conf while that directive
> > > should not be used by default (it is something for users)
> >
> > According to CVS, NoUpgrade was never removed. This is the latest:
> > http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/etc/Attic/pacman.conf?rev=HEAD&search=None&hideattic=1&cvsroot=Pacman&only_with_tag=HEAD&content-type=text/vnd.viewcvs-markup
>
> yes, but those files should be marked as backup in the relevant packages
> instead of simply specifying them as noupgrade. i mean, since the
> following change:
>
> 2006-01-22 03:30  judd
>
>         * lib/libalpm/add.c: changed behaviour with
>           original=X,current=Y,new=Z backup scenario -- install new file as
>           .pacnew and keep old one in place
>
> there is no good reason to list config files both in backup() and in
> the noupgrade list. noupgrade is for users to mark files which are not
> in the packages' backup()

Right, all I was saying has to do with the "left" portion of what you
said.  I didn't really leave anything as I was never aware that they
needed to be removed... I will look into it, as I don't *yet) have all
the details of this change.


> > > 6) you've added a new callback parameter to alpm_db_register() which is
> > > totally useless imho. the callback is called with the treename (which is
> > > a parameter, too) and the database pointer, which is returned. so what's
> > > the point of it?
> >
> > The point is that I changed this function to return the existing DB in
> > an attempt to reregister, in place of returning null.  It seems stupid
> > to let this fail:
> >
> > [current]
> > Server = a
> > [current]
> > Server = b
> >
> > Every config file parser I've seen for sectioned configs ([section
> > name]) parses this as if they were all one section.  As such, the
> > change requires the callback because only db_register knows when the
> > database is new or old.  It's a rather trivial change, and not
> > "totally useless", as it allows for more valid config file handling.
>
> hm. but still, now alpm_db_update() requires a second parameter that
> will be always NULL in all frontends. what about adding an
> _alpm_db_update() function with the callback so that alpm_db_update()
> could be still called without specifying a callback?

On a personal note, I don't have a problem with "mostly null"
parameters - many ANSI C and POSIX functions are invoked this way.
This would be much easier if it were C++ (note: I'm being snarky, I
prefer C++ by leaps and bounds over C - C++ would shrik libalpm nearly
in half... but that's not my decision, heh). 8)

I guess having two functions is not a huge deal.... I can add that.