[pacman-dev] Get the version-number of libalpm
Hi! We're developing a frontend for libalpm written in Qt4, which is called Shaman. It's in alpha state for now, but it's proceeding very fast =) So, I want to ask, if someone of you can add a function to alpm.h which returns the version number of libalpm, that's needed because of our own UserAgent.. Thank you Regards Lukas
Hi! We're developing a frontend for libalpm written in Qt4, which is called Shaman. It's in alpha state for now, but it's proceeding very fast =) Wow, new GUIs are welcome;-) [But I'm a gtk fan:-P]
So, I want to ask, if someone of you can add a function to alpm.h which returns the version number of libalpm, that's needed because of our own UserAgent..
Thank you
Well, I'm not on linux machine atm, but the patch is quite trivial: to alpm.c: const char SYMEXPORT *alpm_getversion() { return(LIB_VERSION) } And modify alpm.h accordingly :-P Anyway, thx for the question, LIB_VERSION is hardcoded to the front-end now, grr... Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Fri, Feb 29, 2008 at 07:40:15PM +0100, Nagy Gabor wrote:
Well, I'm not on linux machine atm, but the patch is quite trivial: to alpm.c: const char SYMEXPORT *alpm_getversion() { return(LIB_VERSION) } And modify alpm.h accordingly :-P
Anyway, thx for the question, LIB_VERSION is hardcoded to the front-end now, grr...
Actually, it's not hardcoded. See last commit where Dan bumped it : 8efe0ecb250050e9061854476468298afb5944d2 it's defined in configure.ac. But don't ask me what to do from there :) Isn't the version in the lib filename itself (/usr/lib/libalpm.so.2.2.0)? And isn't there a standard way to get a lib version?
Idézés Xavier
On Fri, Feb 29, 2008 at 07:40:15PM +0100, Nagy Gabor wrote:
Well, I'm not on linux machine atm, but the patch is quite trivial: to alpm.c: const char SYMEXPORT *alpm_getversion() { return(LIB_VERSION) } And modify alpm.h accordingly :-P
Anyway, thx for the question, LIB_VERSION is hardcoded to the front-end now, grr...
Actually, it's not hardcoded. See last commit where Dan bumped it : 8efe0ecb250050e9061854476468298afb5944d2
it's defined in configure.ac.
But don't ask me what to do from there :)
Isn't the version in the lib filename itself (/usr/lib/libalpm.so.2.2.0)? And isn't there a standard way to get a lib version?
I meant, that the front-end used the library version he got in compile-time (see my patch on usage()); so you get the same number even if you replaced libalpm by hand. (Btw, imho that commit bumped the front-end's version number.) Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Sat, Mar 01, 2008 at 11:16:41AM +0100, Nagy Gabor wrote:
I meant, that the front-end used the library version he got in compile-time (see my patch on usage()); so you get the same number even if you replaced libalpm by hand.
Ah yes, that's right :P
(Btw, imho that commit bumped the front-end's version number.)
Yes, it did. But the backend version is just above in the same file.
Well, I'm not on linux machine atm, but the patch is quite trivial: to alpm.c: const char SYMEXPORT *alpm_getversion() { return(LIB_VERSION) } And modify alpm.h accordingly :-P
Anyway, thx for the question, LIB_VERSION is hardcoded to the front-end now, grr...
Bye
It is attached in git format. PS: Later we could use a version struct (with major, minor, micro etc. fields) to help front-end decide hether libalpm is new enough. Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Sat, Mar 01, 2008 at 11:09:56AM +0100, Nagy Gabor wrote:
Well, I'm not on linux machine atm, but the patch is quite trivial: to alpm.c: const char SYMEXPORT *alpm_getversion() { return(LIB_VERSION) } And modify alpm.h accordingly :-P
Anyway, thx for the question, LIB_VERSION is hardcoded to the front-end now, grr...
Bye
It is attached in git format.
PS: Later we could use a version struct (with major, minor, micro etc. fields) to help front-end decide hether libalpm is new enough.
Do we need to split LIB_VERSION manually for getting major, minor and micro, or is there any other way?
On Sat, Mar 1, 2008 at 5:21 AM, Xavier
On Sat, Mar 01, 2008 at 11:09:56AM +0100, Nagy Gabor wrote:
Well, I'm not on linux machine atm, but the patch is quite trivial: to alpm.c: const char SYMEXPORT *alpm_getversion() { return(LIB_VERSION) } And modify alpm.h accordingly :-P
Anyway, thx for the question, LIB_VERSION is hardcoded to the front-end now, grr...
Bye
It is attached in git format.
PS: Later we could use a version struct (with major, minor, micro etc. fields) to help front-end decide hether libalpm is new enough.
Do we need to split LIB_VERSION manually for getting major, minor and micro, or is there any other way?
We can just define them as separate defines at compile time, take a look at where LIB_VERSION gets generated in configure.ac. I like this patch, I've pushed it to master on my GIT tree with just one small change. -Dan
Hey! Thanx for all the discussion around this. Was this patch ever applied? Regards Lukas Am Samstag, 1. März 2008 02:09:56 schrieb Nagy Gabor:
Well, I'm not on linux machine atm, but the patch is quite trivial: to alpm.c: const char SYMEXPORT *alpm_getversion() { return(LIB_VERSION) } And modify alpm.h accordingly :-P
Anyway, thx for the question, LIB_VERSION is hardcoded to the front-end now, grr...
Bye
It is attached in git format.
PS: Later we could use a version struct (with major, minor, micro etc. fields) to help front-end decide hether libalpm is new enough.
Bye
---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Tue, Mar 4, 2008 at 10:43 PM, Lukas Appelhans
Hey! Thanx for all the discussion around this. Was this patch ever applied?
http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=49197b7492d61bf1f... Won't be around until pacman 3.2.0/libalpm 3 though. -Dan
http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=49197b7492d61bf1f...
Won't be around until pacman 3.2.0/libalpm 3 though.
-Dan
Why? I don't think this would break anything in 3.1.3... Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
participants (4)
-
Dan McGee
-
Lukas Appelhans
-
Nagy Gabor
-
Xavier