- Debugger: Getting mixed signals
- 'Packaging Infrastructure' Contract Weekly Report #4
- Haiku monthly activity report - 06/2015
- 'Packaging Infrastructure' Contract Weekly Report #3
- 'Packaging Infrastructure' Contract Weekly Report #2
- GCI 2014 winners trip report (mentor side)
- TeX Live and LyX; Changes to the boot code
- 'Packaging Infrastructure' Contract Weekly Report #1
- Beginning of 'Packaging Infrastructure' Contract
- Haiku monthly activity report - 05/2015
All is well
Even though I had some private issues this week, all is going well with the PackageInstall. In its current form it is able to properly install all 3 test BeOS packages I tried on it, creating files and directories along with their data and attributes without flaw. So, what's left to do right now?
- The package installer GUI right now is implemented using the traditional way - with font sensitivity in mind. Ryan proposed that this might be a good chance to start using the Haiku layout API to get things done better and more readable.
- Package and file collisions. What to do when a package is already installed or a file from the package already exists in the given path? This was given some discussion a while back, but it's still not clear whether any complicated form of operations is needed. Would the standard 'Should I replace XYZ?' suffice?
- Testing. I need to test the package installer on various different packages, whether attributes are inflated and added as they should and all the similar. With this, I will also try to clean up the code a bit, since there are places that could use some rewriting.
- Writing missing support for some features. During the writing of the parser there were a few tags I ignored because of their low significance (e.g. the Plat tag, showing the platforms on which the package can be installed). Nothing that is not completely useless shouldn't be ignored.
After finishing more or less these four steps, I think PackageInstall would be very much ready for public testing. Hell; it's ready for such tests from the moment it 'worked', but it's better for me to first fix all issues I know about and only then let everyone search for all the bugs I left behind.
PackageUninstaller simple concept sketchAlso, I have already started implementing the user interface of the package uninstaller. There was a discussion about what design should be chosen at the Usability Team mailing list a while back, after which we came (more or less) to a satisfactory consensus. The same as before the chosen layout is simple, usable and very 'Haiku'.
The sketch of the design in mind can be seen to the right. Of course, since the work on the application has not started full time yet, it's not final and can be changed. In fact, there was also another very nice proposition (made by Jonas) for the package uninstaller to look like most BeOS preference applications, meaning having the list of installed applications at the left border of the window. But as Stephan said - the layout is not as important right now, since we can easily change this later on. No one would like this to become the typical "bikeshed" argument ;-)
That's how the situation looks like. I will probably be busy during the nearest week, so I don't think some great progress will be made during that time. But as always - stay tuned.
- Sil2100's blog
- Login or register to post comments

Comments
Re: All is well
Nice progress, Łukasz!
:back-patting:
Excellent!
Re: All is well
Hi,
your package installer sounds very promising :-)
Since you wrote the design can still be changed, I just wanted to suggest you put in a spot where a screen shot of the application goes. If no screen shot is available it should take the icon.
The point is, that the uninstalling program, as it is shown above, can uninstall more than one program. It's usually a lot easier to remember a picture than a name, especially when you're not into computers too much or didn't install a program yourself. Think of all the people who think OpenOffice is Word ;-)
It won't hurt to show that picture in the installer as well, that way it might be easier to decide if one wants to install the software from Haikuware or not. I'm thinking of a folder with 20 programs someone downloaded some time ago. Maybe that person forgot what program is behind the names. A screensho would help here. Another advantage is, if the Icon would be shown, it might be easier for some people to find the newly installed program.
I think the screen shot view was something that made the Zeta installation unique and was a very great feature. It is a giant downside of Linux installation programs that you have a list with 200000 programs but it's hard to find the right one. This is a thing Haiku could do a lot better.
Best regards,
Thomas
Re: All is well
Sorry for the wait.
Since you wrote the design can still be changed, I just wanted to suggest you put in a spot where a screen shot of the application goes. If no screen shot is available it should take the icon.
The point is, that the uninstalling program, as it is shown above, can uninstall more than one program. It's usually a lot easier to remember a picture than a name, especially when you're not into computers too much or didn't install a program yourself. Think of all the people who think OpenOffice is Word ;-)
It won't hurt to show that picture in the installer as well, that way it might be easier to decide if one wants to install the software from Haikuware or not. I'm thinking of a folder with 20 programs someone downloaded some time ago. Maybe that person forgot what program is behind the names. A screensho would help here. Another advantage is, if the Icon would be shown, it might be easier for some people to find the newly installed program.
I think the screen shot view was something that made the Zeta installation unique and was a very great feature. It is a giant downside of Linux installation programs that you have a list with 200000 programs but it's hard to find the right one. This is a thing Haiku could do a lot better.
An interesting idea, but the main problem lies within the actual package format. From what I know, the original BeOS .pkg format didn't have any means to store such screenshots other than as a splash screen. Since all actually existing packages didn't include such application screenshots, such an addition would be quite meaningless. Showing the icon of the application might be more possible, but the same problem arises, since there might be more than one executables with an icon included in the package (and how should the packaging software know which one to use?).
Please remember that this is a legacy BeOS .pkg installer. Only the functions that are supported by the old format can be used.
Bye the way how can I create a pkg? Are there also some pkg creating program planed?
No, there is none planned at the moment. The reason is the same as above - the .pkg format is a obsolete format, which should only be used for compatibility with BeOS. This means that the installer is only a means for installing old BeOS applications which were distributed in the .pkg format. Haiku will probably use a different packaging system for all new, Haiku-built applications.
Re: All is well
Hi, thanks for the answer :-)
I didn't realize your installer was ment to be replaced sometime. You're probably right that old packages won't support the picture. On the other hand I'm still hoping for a gcc 4.x version of Haiku. If I get it right, programs will have to be recompiled to work. It wouldn't be much of a problem to add a picture to the new package that will have to be created if a package has to be built anyways. It might be a dirty hack, but the splash screen is quite useless and its space could be used for the screenshot. All it would take is show the picture somewhere else.
Anyway you have a valid point here, if you have to keep the old package format. Too bad, I would have loved to see a preview picture in packages :-(
Best regards,
Thomas
Re: All is well
On the other hand I'm still hoping for a gcc 4.x version of Haiku. If I get it right, programs will have to be recompiled to work.
There has been some talk about having a compatibility layer that can be loaded to provide backward-binary-compatibility with programs compiled with GCC 2.x - but of course someone would have to actually build it :)
Re: All is well
Im new to all this but I will work on building a package manager prototype for Haiku on my own based upon what I know, may I ask which system you are building apps in though because BeOS max does not allow me to compile any apps it returns the error that _start is not defined in a library header file, im retrying with R3 instead of R4 but If I could know the package the devs are using it would be alot more helpful as I could probably build a linear unpacker/packer quite easily then palm it off to you guys for further development.
Found The Problem I needed an Application within The Project Before Starting a Window Should have a working Example by Monday
There are 10 choices in this world to Be™ or not to Be™
Re: All is well
Im new to all this but I will work on building a package manager prototype for Haiku on my own based upon what I know, may I ask which system you are building apps in though because BeOS max does not allow me to compile any apps it returns the error that _start is not defined in a library header file, im retrying with R3 instead of R4 but If I could know the package the devs are using it would be alot more helpful as I could probably build a linear unpacker/packer quite easily then palm it off to you guys for further development.
Please do, you're most welcome! Good to hear you solved the problem yourself.
If it goes for the package installer, I'm building on the linux cross-compiler environment so that I can test right away whether everything works on Haiku as it should. Another reason for this is that I currently don't have a working BeOS platform (other than a qemu environment) at home.
Did you have any previous experience with the BeAPI?
Anyway, since it's not too clear to me right now, you want to write a package manager for the BeOS .pkg packages? Do you also mean by this a installer/uninstaller? If yes, I think this would be unnecessary code doubling, since most of the installer is already finished. It would be better to cover places that still need to be done or simply help expand the existing installer.
Re: All is well
Oh no im more working on a whole filetype / functional demo of a new package manager so Haiku can be compatible with the .pkg format from your end my end has an idea of what i think the future should be, im running into a few problems at the moment tho with the whole need to hack extend certain API components due to a vast lack of in-built functions etc, thanx for the swift reply tho dude and i hope the .pkg thing works out
There are 10 choices in this world to Be™ or not to Be™
Re: All is well
Bye the way how can I create a pkg? Are there also some pkg creating program planed?