[pacman-dev] Frugalware changes merged.

Aaron Griffin

16 Oct 2006 16 Oct '06

3:25 p.m.

So as of yesterday I checked in all frugalware changes I received. I also added the file-conflict progress bar (talk to ya'll on #frugalware). Now, the CVS may be a tad messy right now - and the docs still have some "frugal" instances in there, but the functionality is there. A few changes I made while testing this out: alpm_parse_config additional parameter for the current section. This allows for sections to be declared before include files (this is the way the arch configs currently work). I actually like this more, and it doesn't break anything. I moved the <repo>/<group>/<pkgname> <version> output to look like on of: <repo>/<pkgname> <version> (<group>) or <repo>/<pkgname> <version> This is because, unlike frugalware packages, not all arch packages are grouped, so there was alot of "current/(null)/foobar" output. Also, I think the fake pathing could potentially be confusing for some users. We could probably find a common solution to this here... lemme know if you guys have any suggestions that fit with both arch and frugalware. I also moved the ftplib progress info to the front of the bar, so that the progress bar aligns with the other progressbars. Other than those, I think the functionality is all there. There's some code cleanup I want to do too, but that's unimportant right now. Next on the list is doc cleanup.

Show replies by date

Roman Kyrylych

16 Oct 16 Oct

3:33 p.m.

2006/10/16, Aaron Griffin :

...

So as of yesterday I checked in all frugalware changes I received. I also added the file-conflict progress bar (talk to ya'll on #frugalware).

Now, the CVS may be a tad messy right now - and the docs still have some "frugal" instances in there, but the functionality is there.

...

Next on the list is doc cleanup.

Wow! That's amazing! Thanks! :-) -- Roman Kyrylych (Роман Кирилич)

Douglas Andrade

6:35 p.m.

On 10/16/06, Roman Kyrylych wrote:

...

2006/10/16, Aaron Griffin :

...
So as of yesterday I checked in all frugalware changes I received. I also added the file-conflict progress bar (talk to ya'll on #frugalware).

Now, the CVS may be a tad messy right now - and the docs still have some "frugal" instances in there, but the functionality is there.

...
Next on the list is doc cleanup.

Wow! That's amazing! Thanks! :-)

Hooray !! --

...

Roman Kyrylych (Роман Кирилич) _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev

Roman Kyrylych

7:23 p.m.

2006/10/16, Douglas Andrade :

...

On 10/16/06, Roman Kyrylych wrote:

...
2006/10/16, Aaron Griffin :

...
So as of yesterday I checked in all frugalware changes I received. I also added the file-conflict progress bar (talk to ya'll on #frugalware).

Now, the CVS may be a tad messy right now - and the docs still have some "frugal" instances in there, but the functionality is there.

...
Next on the list is doc cleanup.

Wow! That's amazing! Thanks! :-)

Hooray !!

BTW, phrakture, there are plenty of pacman/makepkg/abs-related bug reports & feature requests in Flyspray. Maybe you can find some time later to close those that are resolved in pacman3 already? Some of them are even reportef by VMiklos and contains his patches, so I'm sure they are implemented now. And there are some very small fixes for abs and makepkg, which IMHO can be implemented now (if they are not fixed already). -- Roman Kyrylych (Роман Кирилич)

Roman Kyrylych

8:34 p.m.

2006/10/16, Aaron Griffin :

...

So as of yesterday I checked in all frugalware changes I received. I also added the file-conflict progress bar (talk to ya'll on #frugalware).

Hmm.. I just did cvs checkout and pacman is 3.4.0. But Frugalware has 3.4.2 already + some changes after 3.4.2. I'm curious will pacman3 development be in sync now? -- Roman Kyrylych (Роман Кирилич)

VMiklos

9:20 p.m.

On Mon, Oct 16, 2006 at 11:34:42PM +0300, Roman Kyrylych wrote:

...

Hmm.. I just did cvs checkout and pacman is 3.4.0. But Frugalware has 3.4.2 already + some changes after 3.4.2. I'm curious will pacman3 development be in sync now?

yes, the target is to minimize the difference between the two branches udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Roman Kyrylych

9:25 p.m.

2006/10/17, VMiklos :

...

On Mon, Oct 16, 2006 at 11:34:42PM +0300, Roman Kyrylych wrote:

...
Hmm.. I just did cvs checkout and pacman is 3.4.0. But Frugalware has 3.4.2 already + some changes after 3.4.2. I'm curious will pacman3 development be in sync now?

yes, the target is to minimize the difference between the two branches

OK, I feel much better now. :-D BTW, 12 Oct.: makepkg: drop md5 support - but Arch Linux doesn't switch to sha1 yet, though there was a discussion about md5 vs. sha1 vs. md5+sha1 here. :-? -- Roman Kyrylych (Роман Кирилич)

Aaron Griffin

9:25 p.m.

On 10/16/06, VMiklos wrote:

...

On Mon, Oct 16, 2006 at 11:34:42PM +0300, Roman Kyrylych wrote:

...
Hmm.. I just did cvs checkout and pacman is 3.4.0. But Frugalware has 3.4.2 already + some changes after 3.4.2. I'm curious will pacman3 development be in sync now?

yes, the target is to minimize the difference between the two branches

That's just version numbering anyway. I haven't touched that... I'm not really sure how to tackle it anyway... we've never released a pacman 3 here, and it seems silly to start off with a pacman 3.4.X release.... confusing confusing

Roman Kyrylych

9:27 p.m.

2006/10/17, Aaron Griffin :

...

On 10/16/06, VMiklos wrote:

...
On Mon, Oct 16, 2006 at 11:34:42PM +0300, Roman Kyrylych wrote:

...
Hmm.. I just did cvs checkout and pacman is 3.4.0. But Frugalware has 3.4.2 already + some changes after 3.4.2. I'm curious will pacman3 development be in sync now?

yes, the target is to minimize the difference between the two branches

That's just version numbering anyway. I haven't touched that... I'm not really sure how to tackle it anyway... we've never released a pacman 3 here, and it seems silly to start off with a pacman 3.4.X release.... confusing confusing

yeah, there was a question about why 3.4.x in #archlinux few hours ago. BTW, yankees26 tried to compile pacman-lib but failed. Does it compile, or not yet? -- Roman Kyrylych (Роман Кирилич)

Aaron Griffin

9:33 p.m.

On 10/16/06, Roman Kyrylych wrote:

...

yeah, there was a question about why 3.4.x in #archlinux few hours ago. BTW, yankees26 tried to compile pacman-lib but failed. Does it compile, or not yet?

Sure it does. If you don't have po4a or doxygen installed, you probably want to --disable-po4a --disable-doxygen

Cameron Daniel

11:29 p.m.

On Tue, 17 Oct 2006 00:27:55 +0300 "Roman Kyrylych" wrote:

...

yeah, there was a question about why 3.4.x in #archlinux few hours ago. BTW, yankees26 tried to compile pacman-lib but failed. Does it compile, or not yet?

Not sure if the Arch package has been changed yet or not but pacman3 wouldn't compile against the stock libarchive, it needs to be rebuilt. Use ABS to rebuild without the libtool-slay at the end of libarchive, rebuild and then pacman-lib should compile.

Aaron Griffin

11:24 p.m.

On 10/16/06, Cameron Daniel wrote:

...

On Tue, 17 Oct 2006 00:27:55 +0300 "Roman Kyrylych" wrote:

...
yeah, there was a question about why 3.4.x in #archlinux few hours ago. BTW, yankees26 tried to compile pacman-lib but failed. Does it compile, or not yet?

Not sure if the Arch package has been changed yet or not but pacman3 wouldn't compile against the stock libarchive, it needs to be rebuilt. Use ABS to rebuild without the libtool-slay at the end of libarchive, rebuild and then pacman-lib should compile.

Actually, it's only pacman-static that fails - the rest builds fine... at some point I want to libtool-slay pacman too 8)

Cameron Daniel

11:36 p.m.

On Mon, 16 Oct 2006 18:24:58 -0500 "Aaron Griffin" wrote:

...

Actually, it's only pacman-static that fails - the rest builds fine... at some point I want to libtool-slay pacman too 8)

Yeah but for someone who may not know what they're looking at, the build process fails and they may not look any further. Sound very motivated there, go team :D

VMiklos

19 Oct 19 Oct

1:17 p.m.

On Mon, Oct 16, 2006 at 10:25:50AM -0500, Aaron Griffin wrote:

...

So as of yesterday I checked in all frugalware changes I received.

thanks for doing it. a few comments (correct me if at some point i'm wrong): 1) po4a detection is added 3 times to configure.ac 2) you forgot to cvs add the bindings directory, while you added the bindings part to configure.ac 3) po4a support as been added to doc/Makefile.am, but the translations in /doc/po/ are missing 4) you left several NoUpgrade files in pacman.conf while that directive should not be used by default (it is something for users) see http://www.archlinux.org/pipermail/pacman-dev/2006-May/000321.html 5) libalpm/add.c: search for "Cleaning up", added 2 times 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? 7) in alpm.c: - * @return a void* on success (the value), NULL on error + * @return a char* on success (the value), NULL on error */ void *alpm_conflict_getinfo(pmconflict_t *conflict, unsigned char parm) is this a typo? :) 8) i think you've reverted judd's following change: 2006-07-04 19:48 judd * lib/libalpm/deps.c: bugfix: when looking at provides, defer to the new, to-be-installed package's provisios instead of the the existing package's 9) what is the benefit of this change in Makefile.am? - cd pactest; python pactest.py --test=tests/*.py -p ../src/pacman/pacman --debug=-1 + cd pactest; python pactest.py --test=tests/*.py -p ../src/pacman/pacman --debug=1 it seems to be that this will disable all logging except debug. why is this good? 10) i think you forgot to cvs add the /pactest/tests/ directory 11) i think you forgot to add the relevant copyright lines to scripts/makepkg 12) you haven't removed src/pacman/db.[ch] while noone uses the functions provided by them also (as i promised earlier) i've corrected the copyright lines in our tree according to the current state of the cvs udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Aaron Griffin

3:22 p.m.

On 10/19/06, VMiklos wrote:

...

1) po4a detection is added 3 times to configure.ac

Fixed. I've noticed one or two other instances of triple-insertions...

...

2) you forgot to cvs add the bindings directory, while you added the bindings part to configure.ac

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.

...

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

...

5) libalpm/add.c: search for "Cleaning up", added 2 times

Fixed in CVS.

...

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.

...

7) in alpm.c:

- * @return a void* on success (the value), NULL on error + * @return a char* on success (the value), NULL on error */ void *alpm_conflict_getinfo(pmconflict_t *conflict, unsigned char parm)

is this a typo? :)

I didn't touch those comments... fixed in CVS though

...

8) i think you've reverted judd's following change: 2006-07-04 19:48 judd

* lib/libalpm/deps.c: bugfix: when looking at provides, defer to the new, to-be-installed package's provisios instead of the the existing package's

Ah crap... didn't notice that one, I assumed your patches took this into account. I will fix this later, as it's a shade more complicated than editing a few lines.

...

9) what is the benefit of this change in Makefile.am?

- cd pactest; python pactest.py --test=tests/*.py -p ../src/pacman/pacman --debug=-1 + cd pactest; python pactest.py --test=tests/*.py -p ../src/pacman/pacman --debug=1

That was a mistake on my part that shouldn't have been checked in. I was not getting debug output, so messed with the param.... later I found the 2>&1 > logfile redirection and therefore added the nolog parameter. Fixed in CVS.

...

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

...

11) i think you forgot to add the relevant copyright lines to scripts/makepkg

Ah, I didn't change mackepkg so didn't check that - fixed in CVS

...

12) you haven't removed src/pacman/db.[ch] while noone uses the functions provided by them

Done. Thanks alot.

VMiklos

9:17 p.m.

hi, first, thanks for your fast reply :) On Thu, Oct 19, 2006 at 10:22:27AM -0500, Aaron Griffin wrote:

...

Bindings are here: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/bindings/?cvsroot=Pacman What do you mean?

vmiklos@vmobile:~/scm/cvs/pacman-lib$ cvs update cvs update: Updating . cvs update: Updating doc cvs update: Updating etc cvs update: Updating lib cvs update: Updating lib/libalpm cvs update: Updating lib/libalpm/po cvs update: Updating lib/libftp cvs update: Updating pactest cvs update: Updating scripts cvs update: Updating src cvs update: Updating src/pacman cvs update: Updating src/pacman/po cvs update: Updating src/util vmiklos@vmobile:~/scm/cvs/pacman-lib$ ls AUTHORS autogen.sh* configure.ac CVS/ etc/ Makefile.am pactest/ scripts/ TODO autoclean.sh* ChangeLog.bak COPYING doc/ lib/ NEWS README src/ TODO.autoconf strange.

...

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

vmiklos@vmobile:~/scm/cvs/pacman-lib$ ls doc/po /usr/bin/ls: doc/po: No such file or directory vmiklos@vmobile:~/darcs/pacman$ ls doc/po hu.po hu.po~ pacman.pot

...

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

...

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

...

...
8) i think you've reverted judd's following change: 2006-07-04 19:48 judd

* lib/libalpm/deps.c: bugfix: when looking at provides, defer to the new, to-be-installed package's provisios instead of the the existing package's

Ah crap... didn't notice that one, I assumed your patches took this into account. I will fix this later, as it's a shade more complicated than editing a few lines.

i just did a new diff to merge your changes and noticed that the diff would revert judd's change in our tree :)

...

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

vmiklos@vmobile:~/scm/cvs/pacman-lib$ ls pactest/ COPYING ChangeLog TODO pmdb.py* pmfile.py* pmrule.py* util.py* CVS/ README pactest.py* pmenv.py* pmpkg.py* pmtest.py* hmm. maybe this is a cvs bug - or God knows, this is the 3rd missing directory after cvs update udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Travis Willard

10:05 p.m.

On Thu, 19 Oct 2006 23:17:14 +0200 VMiklos wrote:

...

hmm. maybe this is a cvs bug - or God knows, this is the 3rd missing directory after cvs update

Just a quick note in case you were forgetting it - to get new directories, use cvs update -d Instead of just cvs update -- Travis

VMiklos

10:08 p.m.

On Thu, Oct 19, 2006 at 06:05:51PM -0400, Travis Willard wrote:

...

Just a quick note in case you were forgetting it - to get new directories, use

cvs update -d

Instead of just cvs update

thanks, i learned something new again :) /me hists himself with the big red cvs book.. udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

VMiklos

10:07 p.m.

On Thu, Oct 19, 2006 at 11:17:14PM +0200, VMiklos wrote:

...

vmiklos@vmobile:~/scm/cvs/pacman-lib$ cvs update cvs update: Updating . cvs update: Updating doc cvs update: Updating etc cvs update: Updating lib cvs update: Updating lib/libalpm cvs update: Updating lib/libalpm/po cvs update: Updating lib/libftp cvs update: Updating pactest cvs update: Updating scripts cvs update: Updating src cvs update: Updating src/pacman cvs update: Updating src/pacman/po cvs update: Updating src/util vmiklos@vmobile:~/scm/cvs/pacman-lib$ ls AUTHORS autogen.sh* configure.ac CVS/ etc/ Makefile.am pactest/ scripts/ TODO autoclean.sh* ChangeLog.bak COPYING doc/ lib/ NEWS README src/ TODO.autoconf

strange.

oh, nevermind. rm -rf pacman-lib, cvs co from scratch solved the issue yet another reason to switch from cvs to darcs :) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Aaron Griffin

10:11 p.m.

Out of order: On 10/19/06, VMiklos 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.

VMiklos

10:19 p.m.

On Thu, Oct 19, 2006 at 05:11:54PM -0500, Aaron Griffin wrote:

...

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)

my argument here is having an extra parameter for a public function that is used only internally. a logical problem

...

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

then please do it. thanks in advance :) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Aaron Griffin

20 Oct 20 Oct

6:27 a.m.

On 10/19/06, VMiklos wrote:

...

On Thu, Oct 19, 2006 at 05:11:54PM -0500, Aaron Griffin wrote:

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

my argument here is having an extra parameter for a public function that is used only internally. a logical problem

It appears that pacman only ever uses db_register to register the local db. This seems like something which should be handled internally... regardless, I added the function.

VMiklos

12:14 p.m.

On Fri, Oct 20, 2006 at 01:27:16AM -0500, Aaron Griffin wrote:

...

It appears that pacman only ever uses db_register to register the local db. This seems like something which should be handled internally...

in some cases using just db_register() is useful. at least we us it in our testsuite (when we find dependency problems in the package database) and in the iso generator (when you have to put packages to several cds sorted by deps)

...

regardless, I added the function.

thanks :) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

VMiklos

21 Oct 21 Oct

1:35 p.m.

On Thu, Oct 19, 2006 at 03:17:06PM +0200, VMiklos wrote:

...

thanks for doing it. a few comments (correct me if at some point i'm wrong):

a few more: 1) in alpm.i: -%pointer_cast(void *, long, void_to_long); +%pointer_cast(char *, long *, void_to_long); is this change a typo? 2) the _generated_ manpages are now under version control in /doc/man3. i think they should be cvs removed 3) in alpm.c: * @param level if true, then forces the update, otherwise update only in case - * the database isn't up to date * @param db pointer to the package database to update i think this is by accident, too 4) in alpm.c, too: -/** @defgroup alpm_conflict File Conflicts Functions +/** @defgroup alpm_dep File Conflicts Functions wtf? :) 5) alpm.h: - PM_ERR_MEMORY = 1, + PM_ERR_MEMORY = 2, i think this is just a workaround for the functions returning 1 instead of -1 on error. what about reverting this change, since as far as i see you've already fixed those problematic functions? 6) in alpm/db.c: if(db->path == NULL) { _alpm_log(PM_LOG_ERROR, _("malloc failed: could not allocate %d bytes"), - strlen(root)+strlen(dbpath)+strlen(treename)+2); + strlen(root)+strlen(dbpath)+strlen(treename)+2); FREE(db); RET_ERR(PM_ERR_MEMORY, NULL); } a) when i break a long line to shorter ones, then i indent the !=1st ones with 1 tab. vim automatically adds 2 ones. but why chaning the 2 tabs to 3 ones? b) please use tabs instead of 2 spaces (there are more than one example for this problem) 7) still in db.c: match = 1; + } else { } why adding such empty statements? (Judd's provides-related bugfix is still reverted) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Aaron Griffin

7:20 p.m.

I didn't touch any of alpm.i or the doxygen comments at all... so I have no idea where these changes come from. On 10/21/06, VMiklos wrote:

...

1) in alpm.i: Fixed

...

2) the _generated_ manpages are now under version control in /doc/man3. i think they should be cvs removed Fixed

...

3) in alpm.c: 4) in alpm.c, too: Fixed

...

5) alpm.h:

- PM_ERR_MEMORY = 1, + PM_ERR_MEMORY = 2,

i think this is just a workaround for the functions returning 1 instead of -1 on error. what about reverting this change, since as far as i see you've already fixed those problematic functions?

Hmmm, I'd still like to keep this just in case there are dangling 1 returns. There should be no harm in changing this value at all. There is nowhere where it should ever be used, and no one should ever care about these values... I mean, does anyone know the value of EDEADLK?

...

6) in alpm/db.c: if(db->path == NULL) { _alpm_log(PM_LOG_ERROR, _("malloc failed: could not allocate %d bytes"), - strlen(root)+strlen(dbpath)+strlen(treename)+2); + strlen(root)+strlen(dbpath)+strlen(treename)+2); FREE(db); RET_ERR(PM_ERR_MEMORY, NULL); }

a) when i break a long line to shorter ones, then i indent the !=1st ones with 1 tab. vim automatically adds 2 ones. but why chaning the 2 tabs to 3 ones?

:set cinoptions+=(0 This aligns new lines with an unclosed ( on the previous line. It is the way I prefer this.

...

b) please use tabs instead of 2 spaces

noet should be set on all source files, inserting tabs instead of spaces. If noet is not set, please let me know.

...

(there are more than one example for this problem)

Formatting has not been discussed anywhere beyond the modelines in each file, which vim always respects. I don't think calling this a "problem" is correct.

...

7) still in db.c: Fixed.

...

(Judd's provides-related bugfix is still reverted) Yes I'm aware, I never said it was fixed - I said i was going to do it when I had the time.

VMiklos

8:48 p.m.

On Sat, Oct 21, 2006 at 02:20:18PM -0500, Aaron Griffin wrote:

...

...
5) alpm.h:

- PM_ERR_MEMORY = 1, + PM_ERR_MEMORY = 2,

i think this is just a workaround for the functions returning 1 instead of -1 on error. what about reverting this change, since as far as i see you've already fixed those problematic functions?

Hmmm, I'd still like to keep this just in case there are dangling 1 returns. There should be no harm in changing this value at all. There is nowhere where it should ever be used, and no one should ever care about these values... I mean, does anyone know the value of EDEADLK?

35. to be honest the problem is that this is an api change and we use already alpm in many places. an unnecessary recompile of all the packages should be avoided if possible. yes, i know that the answer now will be "we always said pacman3 is not yet ready, we said don't use it yet - now see, why can't you guys wait?" :) so it's up to you. currently such an api change for you is not a problem, for us it is

...

This aligns new lines with an unclosed ( on the previous line. It is the way I prefer this.

...
b) please use tabs instead of 2 spaces

noet should be set on all source files, inserting tabs instead of spaces. If noet is not set, please let me know.

...
(there are more than one example for this problem)

Formatting has not been discussed anywhere beyond the modelines in each file, which vim always respects. I don't think calling this a "problem" is correct.

my first opensource project where i started hacking was MPlayer and there any patch that contained whitespace changes was rejected with a short "whitespace changes mixed with functional changes, rejected" message, so i'm used to do things this way. i'll try to stop blaming you because of your cosmetics ;)

...

Yes I'm aware, I never said it was fixed - I said i was going to do it when I had the time.

ok and thank you for your fixes udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Aaron Griffin

9:32 p.m.

On 10/21/06, VMiklos wrote:

...

35. to be honest the problem is that this is an api change and we use already alpm in many places. an unnecessary recompile of all the packages should be avoided if possible. yes, i know that the answer now will be "we always said pacman3 is not yet ready, we said don't use it yet - now see, why can't you guys wait?" :)

so it's up to you. currently such an api change for you is not a problem, for us it is

Ok, so here's what we'll do. I'll revert to using 1, for now... at a later date I'd like to switch it to a higher number, just to prevent some random conflicts... it's rather unimportant, but it's worthwhile. Fixed in cvs.

...

my first opensource project where i started hacking was MPlayer and there any patch that contained whitespace changes was rejected with a short "whitespace changes mixed with functional changes, rejected" message, so i'm used to do things this way. i'll try to stop blaming you because of your cosmetics ;)

Yeah, I've contributed to projects which said tabs were equally as dumb. i.e. vim's scripts require :set et ts=8 sw=8:. In 99% of cases it's up to the author. In this case, I'll let judd do a "coding format" writeup and we can all use that. On a personal note, I prefer :set et ts=4 sw=4: - I hate tabs, but that's a holy war I don't really care to get into. Personally, I could care less about whitespace, because i use vim. If the modelines are proper, gg=G fixes any whitespace issues...

...

...
Yes I'm aware, I never said it was fixed - I said i was going to do it when I had the time.

ok and thank you for your fixes

Should be fixed now... at least it compiles and succeeds with all pactests, and runs fine... I didn't really test it because I need to head out in like 10 minutes, but it should be in CVS. I'll work on this some when I get home in 5 hours or so...

6408

Age (days ago)

6413

Last active (days ago)

List overview

Download

26 comments

6 participants

participants (6)

Aaron Griffin
Cameron Daniel
Douglas Andrade
Roman Kyrylych
Travis Willard
VMiklos