[Harbour] double postinst call?
Viktor, latest svn code calls both postinst.prg and postinst.cmd ! 'hbxbp' library skipped ./bin/os2/gcc/hbrun.exe --hb:gtcgi ./bin/postinst.prg ! Making e:\harbour\bin\hbmk.cfg... .\bin\postinst.cmd Is this something I'm seeing because of OS/2 use, or is it a general issue? Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] double postinst call?
On Mon, 05 Oct 2009, Maurilio Longo wrote: Hi, latest svn code calls both postinst.prg and postinst.cmd ! 'hbxbp' library skipped ./bin/os2/gcc/hbrun.exe --hb:gtcgi ./bin/postinst.prg ! Making e:\harbour\bin\hbmk.cfg... .\bin\postinst.cmd Is this something I'm seeing because of OS/2 use, or is it a general issue? There are also other problems with postinst.prg. It makes HB_BUILD_PARTS=compiler unusable because to compile hbrun it's necessary to recompile whole core code. Now it simply does not work. Additionally in some package compilation which can be done using non real directories but for final system wide installation (i.e. RPMs) hbrun is linked with shared harbour library but cannot be executed from the temporary build time directories. In summary I'm not sure it's good idea to use it. Instead of making things simpler it introduce additional dependencies. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] double postinst call?
Hi Maurilio, latest svn code calls both postinst.prg and postinst.cmd ! 'hbxbp' library skipped ./bin/os2/gcc/hbrun.exe --hb:gtcgi ./bin/postinst.prg ! Making e:\harbour\bin\hbmk.cfg... .\bin\postinst.cmd Is this something I'm seeing because of OS/2 use, or is it a general issue? I've left support for shell native postinst files intentionally. They might be useful for some local uses, Przemek asked for them, plus some tasks still need it. Anyhow it should only be executed if present, and ignored if not found. Latter should be the case for OS/2. If not there, yet it tries to be executed, it's a bug. BTW thanks for the dehacking of gcc.mak. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] double postinst call?
latest svn code calls both postinst.prg and postinst.cmd ! 'hbxbp' library skipped ./bin/os2/gcc/hbrun.exe --hb:gtcgi ./bin/postinst.prg ! Making e:\harbour\bin\hbmk.cfg... .\bin\postinst.cmd Is this something I'm seeing because of OS/2 use, or is it a general issue? There are also other problems with postinst.prg. It makes HB_BUILD_PARTS=compiler unusable because to compile hbrun it's necessary to recompile whole core code. Now it simply does not work. Additionally in some package compilation which can be done using non real directories but for final system wide installation (i.e. RPMs) hbrun is linked with shared harbour library but cannot be executed from the temporary build time directories. In summary I'm not sure it's good idea to use it. Instead of making things simpler it introduce additional dependencies. That's why I was asking about it before making any move. Well maybe the shared vs non-shared issues should be solved for all occasions in some ways. I see some benefit in this setup because we do have to eat our own dog food. Plus of course it allows to create a shell independent postinst in a language which is well understood by everyone. So so far I like it despite the extra issues you mention. I believe these can be solved in some ways. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] double postinst call?
On Mon, 05 Oct 2009, Szak�ts Viktor wrote: Hi Viktor, There are also other problems with postinst.prg. It makes HB_BUILD_PARTS=compiler unusable because to compile hbrun it's necessary to recompile whole core code. Now it simply does not work. Additionally in some package compilation which can be done using non real directories but for final system wide installation (i.e. RPMs) hbrun is linked with shared harbour library but cannot be executed from the temporary build time directories. In summary I'm not sure it's good idea to use it. Instead of making things simpler it introduce additional dependencies. That's why I was asking about it before making any move. Well maybe the shared vs non-shared issues should be solved for all occasions in some ways. But what we should with HB_BUILD_PARTS=compiler? Now this option is unusable. To create native hbrun binaries it's necessary to recompile whole core code. The second very important problem is support for installation in some temporary directory tree for some packages like RPM or mpkg_tgz.sh. We have to introduce sth like: HB_INSTALL_PREFIXTMP (or any other name you may preffer) which will be used as prefix in all places where HB_*_INSTALL envvars are used. This is important to restore long time existing functionality which is broken now. I see some benefit in this setup because we do have to eat our own dog food. Plus of course it allows to create a shell independent postinst in a language which is well understood by everyone. So so far I like it despite the extra issues you mention. I believe these can be solved in some ways. I do not see any easy way to eliminate OS shell scripts. Please also note that we do not have in core code any platform dependent extensions and if you want to continue using .prg file to finish installation phase then we will have to introduce wrappers for POSIX functions like umask(), chmod(), chowm(), chgrp() getuid(), getgid(), getpwnam(), getpwuid(), getpwent(), ... to set user permission, owner, groups, makes conversions between numeric and literal user/group names, etc. Now all such things are available as simple shell instruction and we do not have to build them yourself using .prg wrappers to low level C functions. I really think it will be much more work then updating simple script. In real life it will not be using .prg code but it will be adding to core Harbour code .prg wrappers for platform specific functions when sth new will have to be set in installation phase. BTW do you know what we may need in VMS? For DOS/WIN/OS2 the installation code is nearly the same and can be quite easy moved to .mk files. We can use it for all platforms to copy or create config files and then we can execute native scripts to make operations which are strongly platform specific. In practice we talk here only about other systems. For DOS/WIN/OS2 such files can be empty. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] double postinst call?
Hi Przemek, On 2009 Oct 5, at 22:59, Przemyslaw Czerpak wrote: On Mon, 05 Oct 2009, Szak�ts Viktor wrote: Hi Viktor, There are also other problems with postinst.prg. It makes HB_BUILD_PARTS=compiler unusable because to compile hbrun it's necessary to recompile whole core code. Now it simply does not work. Additionally in some package compilation which can be done using non real directories but for final system wide installation (i.e. RPMs) hbrun is linked with shared harbour library but cannot be executed from the temporary build time directories. In summary I'm not sure it's good idea to use it. Instead of making things simpler it introduce additional dependencies. That's why I was asking about it before making any move. Well maybe the shared vs non-shared issues should be solved for all occasions in some ways. But what we should with HB_BUILD_PARTS=compiler? Now this option is unusable. To create native hbrun binaries it's necessary to recompile whole core code. Honestly I don't find this a huge problem, since HB_BUILD_PARTS seems really just an optimization option. [ possible that I'm still missing something here. ]. In the future we may also need hbmk2 to build some Harbour components (like contribs), plus hbmk2 is already used in postinst phase for non-*nix shells (and unfortunately since it's shell dependent, these things aren't done equally in cross-build scenarios). So to me it looks like building these Harbour tools is rather unavoidable sooner or later. So it's better to make them work. HB_BUILD_PARTS still stays a suitable build optimization switch as it can turn off some time consuming parts. The second very important problem is support for installation in some temporary directory tree for some packages like RPM or mpkg_tgz.sh. We have to introduce sth like: HB_INSTALL_PREFIXTMP (or any other name you may preffer) which will be used as prefix in all places where HB_*_INSTALL envvars are used. This is important to restore long time existing functionality which is broken now. I'm using subdirs inside 'pkg' dir for similar purpose on non-*nix packaging. Could this work also in this scenario? If this isn't good we can add a new dir. I'll be able to tell a better name if I understand the exact purpose. I see some benefit in this setup because we do have to eat our own dog food. Plus of course it allows to create a shell independent postinst in a language which is well understood by everyone. So so far I like it despite the extra issues you mention. I believe these can be solved in some ways. I do not see any easy way to eliminate OS shell scripts. Please also note that we do not have in core code any platform dependent extensions and if you want to continue using .prg file to finish installation phase then we will have to introduce wrappers for POSIX functions like umask(), chmod(), chowm(), chgrp() getuid(), getgid(), getpwnam(), getpwuid(), getpwent(), ... to set user permission, owner, groups, makes conversions between numeric and literal user/group names, etc. This is not necessary, as these functions can be called from .prg code using hb_run() or similar method. Now all such things are available as simple shell instruction and we do not have to build them yourself using .prg wrappers to low level C functions. I really think it will be much more work then updating simple script. In real life it will not be using .prg code but it will be adding to core Harbour code .prg wrappers for platform specific functions when sth new will have to be set in installation phase. BTW do you know what we may need in VMS? Hm, not really, all I know it has a totally different shell than anything else, different cmd names for everything, so it looks a 3rd world next to win/dos/os2 and *nix. For DOS/WIN/OS2 the installation code is nearly the same and can be quite easy moved to .mk files. We can use it for all platforms to copy or create config files and then we can execute native scripts to make operations which are strongly platform specific. In practice we talk here only about other systems. For DOS/WIN/OS2 such files can be empty. Moving DOS/WIN/OS2 logic to make is absolutely great and definitely better than any sort of postinst solution. What I don't know is how to eliminate most of the still significant amount of .sh code, plus special pkg creation logic currently used. F.e. we've been talking about creating .spec file on the fly, but writing this in .sh doesn't seem to enhance much, since we'd just swap one proprietary solution to another, and the resulting .sh code would be quite cryptic for most ppl. If we could move it to .prg code though, it would certainly be more maintainable / digestable. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] double postinst call?
On Tue, 06 Oct 2009, Szak�ts Viktor wrote: Hi, I'm using subdirs inside 'pkg' dir for similar purpose on non-*nix packaging. Could this work also in this scenario? I have no idea what it does. In general I ask about sth what allows to set HB_*_INSTALL envvars so they will be stored in any configuration files and but real file copy will be done in some different prefixed place. Just simply make mpkg_tgz.sh working from normal user account in any *nix system. I do not see any easy way to eliminate OS shell scripts. Please also note that we do not have in core code any platform dependent extensions and if you want to continue using .prg file to finish installation phase then we will have to introduce wrappers for POSIX functions like umask(), chmod(), chowm(), chgrp() getuid(), getgid(), getpwnam(), getpwuid(), getpwent(), ... to set user permission, owner, groups, makes conversions between numeric and literal user/group names, etc. This is not necessary, as these functions can be called from .prg code using hb_run() or similar method. Sorry but now I'm really confused. What is the reason thay you want to replace shell scrpits by .prg code which calls shell commands? What I don't know is how to eliminate most of the still significant amount of .sh code, plus special pkg creation logic currently used. Why you want to eliminate it? What is wrong with shell scripts? F.e. we've been talking about creating .spec file on the fly, but writing this in .sh doesn't seem to enhance much, since we'd just swap one proprietary solution to another, and the resulting .sh code would be quite cryptic for most ppl. If we could move it to .prg code though, it would certainly be more maintainable / digestable. We was talking about generating spec files as workaround for integration with current make system but for me it was never goal itself but rather temporary hack. Please make it in the way you prefer but I would like to ask you to restore functionality which is broken now: RPMs and TGZ packages. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] double postinst call?
I'm using subdirs inside 'pkg' dir for similar purpose on non-*nix packaging. Could this work also in this scenario? I have no idea what it does. In general I ask about sth what allows to set HB_*_INSTALL envvars so they will be stored in any configuration files and but real file copy will be done in some different prefixed place. Just simply make mpkg_tgz.sh working from normal user account in any *nix system. 'pkg' dir inside the source tree, serves just this purpose. It's a temp location where final package layout is built and the dir packaged. I do not see any easy way to eliminate OS shell scripts. Please also note that we do not have in core code any platform dependent extensions and if you want to continue using .prg file to finish installation phase then we will have to introduce wrappers for POSIX functions like umask(), chmod(), chowm(), chgrp() getuid(), getgid(), getpwnam(), getpwuid(), getpwent(), ... to set user permission, owner, groups, makes conversions between numeric and literal user/group names, etc. This is not necessary, as these functions can be called from .prg code using hb_run() or similar method. Sorry but now I'm really confused. What is the reason thay you want to replace shell scrpits by .prg code which calls shell commands? .prg code may still contain shell-specific parts if there is no better solution. If there is a portable way, of course it should be used instead. [ Even if such shell specific parts are used, the code is one common code with simple branches, instead of duplicate code written in different shell languages. ] What I don't know is how to eliminate most of the still significant amount of .sh code, plus special pkg creation logic currently used. Why you want to eliminate it? What is wrong with shell scripts? They aren't portable across shells and they contain lots of duplicated and redundant logic, which very few developers (you) can keep updated. F.e. we've been talking about creating .spec file on the fly, but writing this in .sh doesn't seem to enhance much, since we'd just swap one proprietary solution to another, and the resulting .sh code would be quite cryptic for most ppl. If we could move it to .prg code though, it would certainly be more maintainable / digestable. We was talking about generating spec files as workaround for integration with current make system but for me it was never goal itself but rather temporary hack. Please make it in the way you prefer but I would like to ask you to restore functionality which is broken now: RPMs and TGZ packages. And here comes the problem: I have no idea how to do this. Given that I had never installed Harbour with sudo and I will never do, plus I don't have an .rpm based distro, this is a flight in the dark for me. Your help would be needed. Or, I'll try to reimplement it in .prg (at least the .tgz part, which I can test). Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] double postinst call?
On Tue, 06 Oct 2009, Szak�ts Viktor wrote: Hi, Please make it in the way you prefer but I would like to ask you to restore functionality which is broken now: RPMs and TGZ packages. And here comes the problem: I have no idea how to do this. Given that I had never installed Harbour with sudo and I will never do, plus I don't have an .rpm based distro, this is a flight in the dark for me. Your help would be needed. Or, I'll try to reimplement it in .prg (at least the .tgz part, which I can test). Your recent modification forced using sudo for simple mpkg_tgz.sh. I want to restore previous functionality which didn't need any special user rights to create Harbour binaries using mpkg_tgz.sh. So I'm asking about restoring pure shell script functionality here. No sudo and no RPM at all. I want to be able to execute mpkg_tgz.sh without sudo as it was possible in the past. In the last months I was updating .spec files after your modifications but I do not think it was good idea because each time after few days you used to change sth and they stop to work again. Last time it was not even 24 hours. I updated them: 2009-09-23 22:05 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) and your modifications: 2009-09-24 17:42 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) made my fixes unusable. You have to begin to control it yourself or at least you should not commit modifications which break some builds. If you can restore mpkg_tgz.sh functionality then I can try to adopt your solution to RPMs and once again hack .spec files and build script to work with current make system. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] double postinst call?
Your recent modification forced using sudo for simple mpkg_tgz.sh. I want to restore previous functionality which didn't need any special user rights to create Harbour binaries using mpkg_tgz.sh. So I'm asking about restoring pure shell script functionality here. No sudo and no RPM at all. I want to be able to execute mpkg_tgz.sh without sudo as it was possible in the past. In the last months I was updating .spec files after your modifications but I do not think it was good idea because each time after few days you used to change sth and they stop to work again. Last time it was not even 24 hours. I updated them: 2009-09-23 22:05 UTC+0200 Przemyslaw Czerpak (druzus/at/ priv.onet.pl) and your modifications: 2009-09-24 17:42 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) made my fixes unusable. You have to begin to control it yourself or at least you should not commit modifications which break some builds. If you can restore mpkg_tgz.sh functionality then I can try to adopt your solution to RPMs and once again hack .spec files and build script to work with current make system. You probably know my goal, and in order to reach it, we must go through these iterations. I can do no better than pull other parts this way. And many times even if I want I can't update these parts. Believe me I don't want to intentionally break these features. The main problem is that conceptually .spec and lots of .sh files are simply wrong now. They are on the wrong end of the process, so they are duplicating make logic, and they need to be synced permanently with every little change. For me most of time it's difficult to detect any connection, since different setting names are used and logic connections are difficult to detect. This also means there is no clear interface between these parts and other parts of the make system. They are doing duplicate detection, they are expecting some later automatically set variables to be set manually etc etc. [ I understand some of these may exist by technical properties/limitations of pkg creator tools. ] It should be cleanup up, but it's difficult to do it alone. Maybe above sounds harsh, but for sure there are quite a few 'no-no's in this area. [ BTW, another goal is/was to eliminate as much .bat code from Harbour build process as possible, and this one is almost reached now, postinst.bat will disappear sooner or later and only hb-mkimp.bat remains, which is quite an independent part and could even be converted to .prg. ] Few areas which would need improvements: - mpkg_src.sh is something we'd need for other shells as well, so it would be better to solve in a shell independent way. - I still don't understand why we have mpkg_rpm_from_svn.sh - mpkg_deb.sh seems redundant and replaceable with debian/rules. - mpkg_rpm.sh/mpkg_rpm_wce.sh/mpkg_rpm_win.sh should IMO be merged into one .sh and an extra HB_PLATFORM parameter. - All packages related files be moved inside /package dir. (*spec, mpkg*.*, debian/ if possible) Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
