HAKILO (ex HUPE) + HakiPKG by s40in

[s40in]

Update Downloads

1. hakilo_installer4anyboot-1.0.3.zip for make your installation boot image (included HakiPKG)
2. HakiPKG 1.0.3 - main scripts for packet management

What’s new

• The first public version of the scripts HakiPKG

[waddlesplash]

@s40in

The delete list is even bigger, it just did not fit!

Yes, this is because the haiku package depends on it. We probably should add some check in the package manager that blocks the haiku package from being uninstalled.

[waddlesplash]

@Diver

I also wonder why noto_sans_cjk_jp is a hard dependecy on haiku package and not just a supplement which is installed by default but still can be removed.

Indeed, we should probably do this.

[s40in]

Downloading and installing packages from the online repository. If someone was waiting for it, then it will be soon.

[alpopa]

@s40in

There is no check for package versions yet. Files are overwritten during installation if they exist.

I would like to know what happens in the following 2 situations:

1. Two different packages, foo and bar, depend on the same functionality lib (same version) offered by some other package. During the installation of foo its depency lib is also installed. During the installation of bar package its dependency lib (same as above) is installed again. But then I want to remove foo. Will foo be removed with its dependency lib or not? If yes, it means bar cannot be run and needs “re-installation”. If yes, it means that when both foo and bar are uninstalled their common dependence lib (not explicitly installed) remains installed.
2. Two different packages, foo and bar, depend on the same functionality lib (different versions) offered by packages lib1 and lib2. During the installation of foo its dependency lib1 is also installed. During the installation of bar its dependency lib2 is also installed, but overrides lib1. Is it true? In this case bar can run, but foo cannot. If foo is “reinstalled” with its dependency lib1, it will override lib2 necessary for bar. In this case foo can be run, bar cannot.

Are these situations handled somehow?

[bullfrog]

@alpopa

Are these situations handled somehow?

@alpopa

Are these situations handled somehow?

Could the first situation be handled by having a dependency_for attribute, where all installed packages that depend on a particular lib are listed? As packages that depend on it are installed, that package gets a listing in the attribute. As packages that depend on it are removed, those packages are also removed from that lib’s dependency_for attribute. A lib would remain installed as long as there are packages that depend on it. After there are no more packages depending on it, the dependency_for attribute could be checked, and that lib could safely be removed.

This could potentially be done either with an actual file or an attribute to the lib’s package or an attribute somewhere in the package system. I like attributes because they are easily queryable and natively done.

[waddlesplash]

I am confused. You said:

@s40in

If I wanted a completely different package system, I could port deb, rpm, etc. But it seems to me that this is not necessary.

I do not need Haiku as “other linux”.

And yet, you are reinventing Linux’s file-based package management system exactly, only in a less robust way than any of the Linux package managers. You already have adopted the “installed files database” it seems, you have now added remote repository download support, and you are adding some kind of dependency management that you claimed above to dislike so much.

So … what is the point of this? We already spent quite a lot of time engineering a package manager, why throw it all away because you “don’t like package managers” only to reinvent it?

[bullfrog]

@waddlesplash

So … what is the point of this? We already spent quite a lot of time engineering a package manager, why throw it all away because you “don’t like package managers” only to reinvent it?

I think the point is that one of the nice things about opensource software is the ability to modify it as you see fit. I think the major qualm here with Haiku’s package management is the packagefs. There are two camps regarding this. Those who think it is a good idea. And those who think it is a bad idea. I think both camps are right.

I don’t see this as throwing anything away. The package management as Haiku does it is still here. And the community now has the option of Haiku without packagefs. To paraphrase Thomas Jefferson, one taper is lit at another, increasing the light of both without darkening either.

Haiku can continue to support packagefs and Hakilo can support a non-packagefs system. I see this as a non-issue, and a win-win for all.

[waddlesplash]

@bullfrog

I think the major qualm here with Haiku’s package management is the packagefs. There are two camps regarding this. Those who think it is a good idea. And those who think it is a bad idea. I think both camps are right.

That’s not how “right” works. Certainly there are pros and cons to each approach, and one may have a personal preference for one or the other, but ultimately for the Haiku project and its philosophies and goals, one is better than the other, I think.

@bullfrog

And the community now has the option of Haiku without packagefs. To paraphrase Thomas Jefferson, one taper is lit at another, increasing the light of both without darkening either.

That’s the Linux way; to give users as many options as possible and let them pick whatever one they like best.

But we aren’t Linux, and it has been one of our most consistent philosophies that down Linux’s road lies madness. Fragmenting the community in this way will not result in anything good.

[bullfrog]

@waddlesplash

That’s not how “right” works. Certainly there are pros and cons to each approach, and one may have a personal preference for one or the other, but ultimately for the Haiku project and its philosophies and goals, one is better than the other, I think.

I see packagefs as right for Haiku. I see Hakilo’s way as right for Haikilo. I personally like Haiku’s way for my own usage. If I really want to dive that far into the system directory, I’ll mess with the source and recompile. Some folks like to mess directly with the system files. Hakilo is for those folk.

@waddlesplash

That’s the Linux way; to give users as many options as possible and let them pick whatever one they like best.

Eh, almost, not quite. The Linux way is to let the user choose which kernel version to use, the bootloader, the init system, the shell, display manager, windowing system, desktop environment, package manager, etc. Haiku vs Hakilo is simply a choice between how packages are stored and managed. To compare this to the Linux way is a bit unfair.

@waddlesplash

Fragmenting the community in this way will not result in anything good.

I don’t think this will really fragment the community in any meaningful way. I actually think it may serve to entice back some of those we lost over the PM fiasco. This may well serve to help reunite the community.

[waddlesplash]

@bullfrog

If I really want to dive that far into the system directory, I’ll mess with the source and recompile. Some folks like to mess directly with the system files. Hakilo is for those folk.

Huh? Us developers mess with system files all the time without doing full recompiles. That’s what non-packaged is for. I don’t know why Hakilo makes any significant difference here.

@bullfrog

I actually think it may serve to entice back some of those we lost over the PM fiasco. This may well serve to help reunite the community.

Well, they wouldn’t be using “Haiku”, but “Hakilo”. Seeing as reverting to this “no package manager” state is rather trivial to do, they could have done it then, but didn’t want to spend the 5 minutes or whatever to do it. So I doubt they’ll be back just for this.

[bullfrog]

@waddlesplash

Huh? Us developers mess with system files all the time without doing full recompiles. That’s what non-packaged is for. I don’t know why Hakilo makes any significant difference here.

I mean messing with the system tree. Not using non-packaged in the home tree. Unless you have some developer knowledge way of unlocking the system tree. I’ve seen some potential users claim the locked system directory as a deal breaker for them. Some control freaks can’t deal with a system that appears to lock them out of total control of the system.

Also, packagefs, was a point of contention. Some seem to think it’s a bottleneck. Hakilo might be a way of either proving or dispelling this.

@waddlesplash

So I doubt they’ll be back just for this.

I’ll let time be the test of this. I personally love the work that Haiku has done with package management. Sure, it could use some work on optimization. As it stands, I love it. Do I want Haiku to drop pkgman and packagefs? Absolutely not! I see it as a step forward. That doesn’t mean everyone does. I think Haiku’s target audience would largely agree with me. Nobody is asking for Haiku to change for the sake of those who would use Hakilo. I think all that anyone is asking here is for Hakilo to be accepted as an alternative for those who wish to do things a bit different. I’ll keep using Haiku as-is. It works great for me.

[PulkoMandy]

@bullfrog

I mean messing with the system tree. Not using non-packaged in the home tree. Unless you have some developer knowledge way of unlocking the system tree. I’ve seen some potential users claim the locked system directory as a deal breaker for them. Some control freaks can’t deal with a system that appears to lock them out of total control of the system.

High tech wiwardry indeed:

cp myfile /system/non-packaged/bin/

This directory is in the PATH before the main (packaged) one. Likewise for libs, add-ons, drivers, etc. In the worst case, you can use the blacklist file to hide files from the system packages. As mentionned, the great thing is that this is always reversible, so if you mess up your system, it’s super easy to fix.

And an unrelated note on fonts: at some point Haiku dependend on no fonts, and people complained that the font package were uninstalled and everything looked like crap. So we made it depend on the font. And there is no reason to make it depend only on the font needed for latin characters. Why privilege latin fonts over japanese ones?

Being able to display CJK characters out of the box is part of the “it just works” experience.

[extrowerk]

@bullfrog

I’ve seen some potential users claim the locked system directory as a deal breaker for them.

I have only seen some guys raging about non-installable BeOS programs, but everytime somebody called them to give a bugreport or a list, they just went MIA.
And while it is still true that some old BeOS programs have problems with not able to write the filesystem like there is no morning, i cant really see, how is it a problem.

I would like to propose to create an own page for this project, because the possible users could get mixed ideas what this stuff is.

[bullfrog]

I am all for having a separate forum for this.

[apgreimann]

Well, maybe not a separate forum, but a separate section at least, as it’s filed under the Development category right now.

[s40in]

Most likely meant a different web site. This topic, for some reason, painful and not desirable here

[s40in]

Are these situations handled somehow

Now, of course not. For now, this is only the beginning of simple scripts. Just a demonstration of the fact that it works.

Now the user himself must make a decision.

[s40in]

@waddlesplash

So … what is the point of this? We already spent quite a lot of time engineering a package manager, why throw it all away because you “don’t like package managers” only to reinvent it?

You did an excellent job. And this is not a joke and not sarcasm. But this is not how I would like to use the Haiku.

Now it is not clear which libraries are system and which are not. All in one heap.
If the libraries have been updated in the repository, then you need to rebuild the program with them, since there is no certainty that everything will work.

This is a pure linux way.

[extrowerk]

Only if the lib breaks ABI, but then it should be clear because the soname change, so it wont be uncertain, as runtime_loader would complain about missing lib.

If i understand you correctly, that’s should happen.