the whole "echo in post_install" custom should be avoided. think of any gui - their stdout is even invisible in most cases

it's up to the Arch devs how they solve this problem - in Frugalware we use to add README.Frugalware files for packages and such infos are described there. probably such READMEs are not preferred by them since by default they remove all the docs from the packages

README can be good if it will be displayed automatically after package install. This is a job of any libalpm front-end anyway. It should be treated like .PKGINFO or .FILELIST files - I mean these README files should be used for front-end work only, and not installed anywhere. There is another thing - some packages generates some progress info during install (like ">>> Genreating initial ramdisk... done"). - this should be addressed too, maybe with something like status_message() function, or something else. By addressing this issues now we can avoid different custom "echo in post_install" things for different packages in different front-ends. I don't know much about libalpm/pacman3 internals yet, but I think that these issues can be addressed.

I think all info messages should just be passed to front-end and it is front-end's job how and when to show them. So there should be speciall function for use in .install files instead of current echo stuff. As for indicating some progress for user: when there is some lengthy operation in .install it should be prefixed and postfixed with calls to special functions so user will see a message from front end like "Generating the initial ramdisk... Please wait." and then "Done" (or green checkmark in GUI :-D ). 2006/5/28, VMiklos :

On Fri, May 26, 2006 at 04:25:39PM +0300, ????? ??????? wrote:

...

README can be good if it will be displayed automatically after package install. This is a job of any libalpm front-end anyway. It should be treated like .PKGINFO or .FILELIST files - I mean these README files should be used for front-end work only, and not installed anywhere.

.PKGINFO and such files are handled in libalpm

btw sure, this is up to the frontend, shile executing such files are dony by libalpm. that's why the post_instal scriptlet must be silent and shouldn't output any essential info

...

There is another thing - some packages generates some progress info during install (like ">>> Genreating initial ramdisk... done"). - this should be addressed too, maybe with something like status_message() function, or something else.

the behaviour is bad, but in this case just a gui user should wait (like while running ldconfig) but he/she doesn't miss any essential info

udv / greetings, VMiklos

-- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev

Wow! I don't know what this code means (I'm not started digging libalpm internals yet). What I mean is something like this in .install file: post_install() { task_start("Generating initial ramdisk...") # some code here... task_end() } instead of this old bad way: post_install() { echo "Generating initial ramdisk..." # some code here... echo " done" } And like this: post_install() { message("Attention! Please change default config file before restart!", "MTYPE_WARNING") } I'm talking about adding some predefined functions to "API" for PKGBUILDers. 2006/5/29, VMiklos :

On Mon, May 29, 2006 at 12:16:31AM +0300, ????? ??????? wrote:

...

I think all info messages should just be passed to front-end and it is front-end's job how and when to show them. So there should be speciall function for use in .install files instead of current echo stuff. As for indicating some progress for user: when there is some lengthy operation in .install it should be prefixed and postfixed with calls to special functions so user will see a message from front end like "Generating the initial ramdisk... Please wait." and then "Done" (or green checkmark in GUI :-D ).

you can do an

EVENT(trans, PM_TRANS_EVT_SCRIPTLET_START, "Generating the initial ramdisk", NULL);

then an EVENT(trans, PM_TRANS_EVT_SCRIPTLET_DONE, NULL, NULL);

but when do you call them?

a possible solution: the scriptlet is executed via popen() then you could parse the output: if it is something like "task... " then you could call PM_TRANS_EVT_SCRIPTLET_START and when it is "done." then PM_TRANS_EVT_SCRIPTLET_DONE

udv / greetings, VMiklos

-- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev

Yes, I know C. Programmed in it almost 5 years already. :-D I've got your point. Now I understand that calling from post_install in such way is impossible. Yes, using popen may be good solution. Could there be some standard pipe defined to communicate between .install script and front-end? 2006/5/29, VMiklos :

On Mon, May 29, 2006 at 01:02:44AM +0300, ????? ??????? wrote:

...

Wow! I don't know what this code means (I'm not started digging libalpm internals yet). What I mean is something like this in .install file:

post_install() { task_start("Generating initial ramdisk...") # some code here... task_end() }

instead of this old bad way:

post_install() { echo "Generating initial ramdisk..." # some code here... echo " done" }

And like this:

post_install() { message("Attention! Please change default config file before restart!", "MTYPE_WARNING") }

I'm talking about adding some predefined functions to "API" for PKGBUILDers.

i really don't want to flame, but do you know C?

when you call the scriptlet, the best what you can do is to use popen() then read something like:

START Generating initial ramdisk DONE

and then alpm can call the functions. you'll never be able to call the frontend's function from post_install()

udv / greetings, VMiklos

-- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev

...

Could there be some standard pipe defined to communicate between .install script and front-end?

that's what i've proposed :)

2 "commands": 1. START <string> 2. DONE <exit code>

comments? Judd, Aurel? what do you think about this?

Noone else wants to say something?

currently it is exam perion here, after it is over i'll try to implement it and came up with a patch - it's easier to comment if there's already an implementation Thanks! :)

On Mon, May 29, 2006 at 03:03:57AM +0200, VMiklos wrote:

...

Could there be some standard pipe defined to communicate between .install script and front-end?

that's what i've proposed :)

2 "commands": 1. START <string> 2. DONE <exit code>

comments? Judd, Aurel? what do you think about this?

It starts to sound a little convoluted, but I can't think of a better way. If each scriptlet implicitly included a helper bash script that included a task_message() function, that function could relay the strings through a fifo that libalpm listened to on the other side. libalpm could then feed the strings back to the frontend. - J

On Wed, May 31, 2006 at 01:28:34PM -0700, Jason Chu wrote:

...

If each scriptlet implicitly included a helper bash script that included a task_message() function, that function could relay the strings through a fifo that libalpm listened to on the other side. libalpm could then feed the strings back to the frontend.

Wouldn't it be better to have pacman execute a script that sets up things like task_message and then executes the install script in the same environment?

That way you could upgrade the task_message() function later, etc.

Yep, exactly. Sorry, that's what I meant by "implicitly." The scriptlets wouldn't have to manually source any helper file, pacman would set that up for them. - J