libyab.so

[bbjimmy]

I have recently noticed an .hpkg file offered by BeSly.de ... http://www.software.besly.de/ for libyab.so.

This may be the way we want to go, however this will require us to version the lib. As it works now, one would package his yab program with the libyab.so that was used to make it, or specify the minimum yab version used as a package requirement. If we break out the library into its own package, we must require a minimum version of the lib ( just as we required a minimum version of yab ) to insure that we are using a version that works with the program.

If we do this, we get into the whole libyab,.so.1 ... libyab.so.1.1 etc mess. It can be done this way, but I think requiring the proper yab version or simply adding a lib folder with libyab.so is simpler.

What are your thoughts?

[clasqm]

Keep it simple.

required {
yab >= 1.blablabla
}

Of course ensuring that yab and libyab.so maintain backwards compatibility is now ... your problem. But I don't want to end up with twenty versions of libyab.so on my system. One day we may need to go to yab2 and libyab2.so. But not for a while, I hope.

[lelldorin]

I have recently noticed an .hpkg file offered by BeSly.de ... http://www.software.besly.de/ for libyab.so.
... but I think requiring the proper yab version or simply adding a lib folder with libyab.so is simpler.

This is not the right way. If i add the library into my hpkg file i hae the same size for the program as before. This does not make any sense. If i have the gatget to make yab apps smaler i need to install yablib.so as requiroment or over a reposerver as single installfile. If i add every time the library i can make a selfexecuting yab file with bound yab and source file as before too. Thats the same.

We add the library for programs ported from haiku 4.1 to pm by lorglas, because he used the latest yab version with splitted yab and program file. So he need to add this library on our repository to make his programs runable.

A other problem with requiroments is that if you remove for exaple yab with included yablib.so, alls programs who required thispackage are deinstalled too :-(. Stupid workaround

[bbjimmy]

This is not the right way. If i add the library into my hpkg file i hae the same size for the program as before. This does not make any sense. If i have the gatget to make yab apps smaler i need to install yablib.so as requiroment or over a reposerver as single installfile. If i add every time the library i can make a selfexecuting yab file with bound yab and source file as before too. Thats the same.

We add the library for programs ported from haiku 4.1 to pm by lorglas, because he used the latest yab version with splitted yab and program file. So he need to add this library on our repository to make his programs runable.

A other problem with requiroments is that if you remove for exaple yab with included yablib.so, alls programs who required thispackage are deinstalled too :-(. Stupid workaround

The problem with a libyab.so package is that newer yab programs may not find the new features / fixes in this lib, and there would be no way for the user to know why some yab programs run and others don't.

By uesing:

requires {
yab >= 1.7.5
}


instead of

requires {
libyab.so
}

One can insure that the program will run.


note: the 1.7.5 will change in later versions of yab, libyab.so for say 1.8 will work for a program built with 1.7.5, not the other way around.


If we package programs requiring libyab.so we open the door to users installing a program built with a later version of yab than the libyab.so that is already installed, this causing the new program not to run.

if he has yab1.7.5 installed and a new hpkg needs yab1.8.0, the new version of yab is installed and both the new and old programs will continue to run properly.

[lelldorin]

This is not the right way. If i add the library into my hpkg file i hae the same size for the program as before. This does not make any sense. If i have the gatget to make yab apps smaler i need to install yablib.so as requiroment or over a reposerver as single installfile. If i add every time the library i can make a selfexecuting yab file with bound yab and source file as before too. Thats the same.

We add the library for programs ported from haiku 4.1 to pm by lorglas, because he used the latest yab version with splitted yab and program file. So he need to add this library on our repository to make his programs runable.

A other problem with requiroments is that if you remove for exaple yab with included yablib.so, alls programs who required thispackage are deinstalled too :-(. Stupid workaround

The problem with a libyab.so package is that newer yab programs may not find the new features / fixes in this lib, and there would be no way for the user to know why some yab programs run and others don't.

By uesing:

requires {
yab >= 1.7.5
}


instead of

requires {
libyab.so
}

One can insure that the program will run.


note: the 1.7.5 will change in later versions of yab, libyab.so for say 1.8 will work for a program built with 1.7.5, not the other way around.


If we package programs requiring libyab.so we open the door to users installing a program built with a later version of yab than the libyab.so that is already installed, this causing the new program not to run.

if he has yab1.7.5 installed and a new hpkg needs yab1.8.0, the new version of yab is installed and both the new and old programs will continue to run properly.

there is the problem? we need to solve this like all other libs too. every lib version need to be the version nummer included the filename and every lib version need a own package. so you can have more tgen one yablib ibstalled and all yab apps are running

[lorglas]

Hello bbjimmy,
First of all thanks for the bug fixes.

What I found not so good that you do not write the solution to my problem on the Beusergroup on Beusergroup but have only set link . Furthermore, you had to write me and ask why a well is on the Besly libyab.so package.

Now times a problem.
It is currently not possible as libyab.so individually specify the required package, since it in Haiku Depot is not available separately, but only with yab together. That's why I've tried, if I can call as repo libyab.so the dependence of my and hence can install.
This currently is not and it took about a half a day for a solution to look for me.

Thus yab for me is currently unusable because my programs are to be given out as a standalone solution. The User should not unnecessarily yab install. You do not really need.

The background:
Lelldorin and I have time jan64 long annoyed until he has made us Yab, which has its programs as stand alone programs without yab to install. first time was the bind function, however, he had to improve this even more, because you could look in the source code at the time. We did not want. Therefore, then, he has adapted the Build Factory for us again.

At the libyab.so.
If I have understood correctly, there is a minimal yab. Can anyone guarantee that the later programs are displayed correctly me. Button in the right size etc. or do I have but my program after an update yab adapt because something does not fit.

While it saves a few KB, but what does it cost today space or traffic during download? It does not cost much, and the programs are not really big although yab is tied with the program.

With the current version of yab I can not give out programs, because I do not want to set as a function yab.

There are three possible solutions.
1. offering libyab.so individually, so you can put this as a dependency, or
2. Build rebuild the factory, the yab is again packed directly to the program.
3. One could build the factory with a switch fitted (eg Standalone specify) so that you have both versions. Small Binary with dependence libyab.so or slightly larger than Binary standalone.

it was first

lorglas

[clasqm]

I actually like lorglas' solution #3, but it does not remove the problem of library versioning. Does the packaging system allow the following?

requires {
lib:libyab.so >=1.7.5
}

I haven't actually seen that combination.

[bbjimmy]

I actually like lorglas' solution #3, but it does not remove the problem of library versioning. Does the packaging system allow the following?

requires {
lib:libyab.so >=1.7.5
}

I haven't actually seen that combination.

I'm looking into how this will work, but this is what I expect it will look like.

Building yab1.xxx wil build a libyab.so.1.xxx

I will add a libyab .hpoackage that only packages libyab.so.1.xxx for those who do not have yab installed. seems like a lot of work for little gain.

requires {
lib:libyab.so >=1.7.5
}

versus

requires {
yab >=1.7.5
}

Doesn't save much disk space.

The yab package has the yab sources and the yab binary as well as libyab.so, but does not include the files for yab-IDE or the BuildFactory.

When this change was originally done, We, Jessicah and me, thought at the yab package would be used to insure libyab.so is installed on the system since libyab,so would be backward compatible with older versions on yab and this would mean one less required .hpkg file for the yab language.

[lorglas]

requires {
lib:libyab.so >=1.7.5

Building yab1.xxx wil build a libyab.so.1.xxx

I will add a libyab .hpoackage that only packages libyab.so.1.xxx for those who do not have yab installed. seems like a lot of work for little gain.

requires {
lib:libyab.so >=1.7.5
}

versus

requires {
yab >=1.7.5
}

Doesn't save much disk space.

The yab package has the yab sources and the yab binary as well as libyab.so, but does not include the files for yab-IDE or the BuildFactory.

When this change was originally done, We, Jessicah and me, thought at the yab package would be used to insure libyab.so is installed on the system since libyab,so would be backward compatible with older versions on yab and this would mean one less required .hpkg file for the yab language.

When I understand it right.
For each yab version, we need a libyab.so.
So i think we doesn't save disk space. And you could not write
Require libyab.so >=1.7.5 , because if we have Major changes in yab, so that the yab Program you write needs a rebuild (eg. Windows open has change and so on), the Program didn't work correctly.
My Favorite is solution 2

you need only write in hpkg file
requires {
libyab.so
}

but the libyab.so must be available in HaikuDepot as standalone lib package.

[lelldorin]

requires {
lib:libyab.so >=1.7.5

Building yab1.xxx wil build a libyab.so.1.xxx

I will add a libyab .hpoackage that only packages libyab.so.1.xxx for those who do not have yab installed. seems like a lot of work for little gain.

requires {
lib:libyab.so >=1.7.5
}

versus

requires {
yab >=1.7.5
}

Doesn't save much disk space.

The yab package has the yab sources and the yab binary as well as libyab.so, but does not include the files for yab-IDE or the BuildFactory.

When this change was originally done, We, Jessicah and me, thought at the yab package would be used to insure libyab.so is installed on the system since libyab,so would be backward compatible with older versions on yab and this would mean one less required .hpkg file for the yab language.

When I understand it right.
For each yab version, we need a libyab.so.
So i think we doesn't save disk space. And you could not write
Require libyab.so >=1.7.5 , because if we have Major changes in yab, so that the yab Program you write needs a rebuild (eg. Windows open has change and so on), the Program didn't work correctly.
My Favorite is solution 2

you need only write in hpkg file
requires {
libyab.so
}

but the libyab.so must be available in HaikuDepot as standalone lib package.

sorry this sucks, i does not have fun to rebuild every time some one makes a new yab version with new features my app again. My solution with the yablib with included version in the name, like other libraries will be here a good way.