Reasons against a linux-like package manager?

21

[quote=halo]I can think of several problems with Linux-style package managers that make them a poor fit with Haiku:

How do you find good software? Linux package managers make this remarkably difficult, since you’re not given a screenshot, not given reviews, and barely given any indication of its popularity. By giving all developers the same opportunities, you are drowned in a sea of half-baked and poor software. PageRank will often be a better solution at finding good software with well-designed websites, and it provides the opportunity for outside websites to fulfil this role - decentralisation can lead to innovation.[/quote]

I strongly agree with everything in the above post.

Finding any given type of software on a site like BeBits was a wonderful experience. Ratings, number of downloads, and reviews made selection simple.

Linux “Software Centers” present a sea of unranked, user-hostile-named choices. In addition, the few times I’ve attempted to install software in Linux(Ubuntu), the software I want either isn’t in the Software Center, or the version listed is horribly outdated, and I have to go to the developer’s site to download it anyway. Even then, there is no binary to be installed, but instead uncompiled source code, incomplete instructions, and a vague list of required dependencies. A many-houred adventure digging through countless mailing lists and hair-pulling command line trial and error awaits! (Code::Blocks, Mono, Sheepshaver)

For the love of all things good, PLEASE keep this mess away from Haiku.

22

Most of those things are non issues… Haiku is THE distrobution so … program developers will target it with binaries instead of just saying have at it with the source code as happens on Linux.

Ubuntu has package ranks I believe also I believe program screenshots are in the works on the debian end so you are kinda calling them out on unfinished features that just aren’t ready.

23

I like the idea that programs are compiled native to Haiku and do not run using packaged toolkits coming in from GTK, QT etc. The idea for Haiku was to have a rich API so why do you need a package manager. Isn’t the point of having a rich API to provide everything you need to write programs for the OS. Consider writing a music DAW for Haiku; everything you need is provided by the API including a midi and media toolkit. The OS provides everything that is needed, no additional packages are required. The selling point and niche of Haiku is media applications; music, film, graphics etc. The emphasis should be firmly placed on nailing this aspect of the OS or it will just turn into yet another Linuxean mess. Desktop media applications is what ultimately sets Haiku apart; use it’s API!

24

Well, calling Linux a mess, would have to be on you. Or maybe the distro you used. - But, my system is clean, efficient, and I haven’t needed to compile an app that I needed for everyday use. (Not trying to single you out, sorry)

The package management is something I hope for. And if not included in the release, I’ll find some other means of getting one.

Use of the Haiku API, as the main, is great, (I don’t like using QT apps on my GTK desktop and vice versa. [That doesn’t take functionality away, only the “looks”]) but what about different libraries, what if I want just one library, what if I want a whole assortment? Would I need to go from site… to site…to … site… to find them. That’s what I would consider a dependency hell.

If Haiku is getting one, very nice. But if it will only download one file, that includes everything…
I’ll avoid that for many reasons: Size, bug in the app that would make me need to redownload the whole one file, some apps use a library not included in the Haiku release and the same library would be downloaded/installed, multiple times, redundancy is great, but not w/ apps, etc…
“Hey Bob, I have 3 installs of >insert web browser here< on my system!” - Why not just open it three times?.. “…”

I like Haiku, and I like Linux.
Why not focus on what Haiku can use, instead of bashing something that is time tested, and works.
(If it didn’t work for you, and yet it worked for the other thousand people, it’s probably you)
Edit:Wording

25

Well, I actually like the package manager on Ubuntu.
But I like the tranparancy that Beos offered much more: on Beos I knew exactly what programs where installed on which location.

I would like to see some kind of mix between the two:

  • selfcontaining apps.
  • system managed libs.

All libs are managed and updated by the OS from a central repository, while each application is installed by the user in its own folder.
The libs that an application requires are just symlinked into the applications lib directory.
Off course the library should be able to hold different versions of each library, organised into a hierarchial structure.

26

[quote=TeDiouS]Use of the Haiku API, as the main, is great, (I don’t like using QT apps on my GTK desktop and vice versa. [That doesn’t take functionality away, only the “looks”]) but what about different libraries, what if I want just one library, what if I want a whole assortment? Would I need to go from site… to site…to … site… to find them. That’s what I would consider a dependency hell.

If Haiku is getting one, very nice. But if it will only download one file, that includes everything…
I’ll avoid that for many reasons: Size, bug in the app that would make me need to redownload the whole one file, some apps use a library not included in the Haiku release and the same library would be downloaded/installed, multiple times, redundancy is great, but not w/ apps, etc…
“Hey Bob, I have 3 installs of >insert web browser here< on my system!” - Why not just open it three times?.. “…”[/quote]
It seems that some who are commenting here don’t know (Or because of Linux-zealotist ideals don’t want to know) how an ideal application for BeOS/Haiku is actually distributed when it comes to libraries and such. An application for BeOS/Haiku should always come with a lib/ folder with all needed libraries, inside the respective application’s own directory. With this model there is no dependency hell, no searching for libraries on the internet, no “mess”. So don’t use these bogus arguments, and try to stick to real issues, please.

With this model, an application works out-of-the-box, it’s organized, it doesn’t pollute the system, and it’s portable. I think this model should be kept. Now, I do know that some applications go against the rule, though, and there should be ways to enforce the right way of distributing applications. The only real issue here is the file size, but I don’t think that outweighs everything else. Nobody has a 20 GB hard-drive these days anyway (And how big can an application be? This isn’t Windows with its several hundreds of MB’s big apps)…

27

[quote=Denise Purple]
It seems that some who are commenting here don’t know (Or because of Linux-zealotist ideals don’t want to know) how an ideal application for BeOS/Haiku is actually distributed when it comes to libraries and such. An application for BeOS/Haiku should always come with a lib/ folder with all needed libraries, inside the respective application’s own directory. With this model there is no dependency hell, no searching for libraries on the internet, no “mess”. So don’t use these bogus arguments, and try to stick to real issues, please.[/quote]

Actually what you’ve described as “ideal” was previously considered exactly the opposite. Michael Phipps, for example, promoted the idea that Haiku would include “all” the libraries in a release. Programs which needed libraries that weren’t in say Haiku R1, just wouldn’t be made available until Haiku R2. That idea seems to have been rejected since he left the project. If there’s consensus that you’re right (I doubt there’s any consensus at all) it should be in a policy document like the trademark policy so that independent developers know the “rules of the game”.

In any case the major Linux distributions reject bundling (the approach you’re calling for) because it puts many hidden security flaws into systems. With libraries like the IJG’s libjpeg we see a pattern where a security bug is detected, the OS vendors provide a fix, and then months or even years later users are attacked via an application which bundled an obsolete library.

It does also cost you COW duplicate page optimisation for your libraries. In Linux this needn’t be so bad (Linux now has a way to coalesce pages of memory via hashing, although if the same library was compiled by different compilers the binaries won’t match) but in Haiku it would mean the same software needs much more RAM to run than before.

28

Seems like someone in this thread has been sipping the Linux Kool-Aid. I’ve been using Linux since 2001 and I like it as much as the next geek, but if you’re making an operating system for personal computing the absolute last thing you want to do is feature a Linux-style package management system. It might seem nice to only pull in the libraries and resources needed for the applications that are desired, but the only reason Linux has to do that is because there are so many. Developers from all over are creating this stuff and Linux package management is not so much as system as it is an accident. It’s an adequate solution for a problem which is unique to Linux: users needing to run programs that depend on a variety of frameworks and libraries. This situation arose due to the diversity inherent in a system with such an open development process. Like I said, it’s adequate for it’s application in Linux but it’s subpar compared to the offerings from OS X and Windows (personal computing operating systems). An app store is one thing but adopting the whole package management system is a huge mistake.

Not to mention Linux-syle package management (even in the glorious Ubuntu) has system-breaking flaws in the long-term. As a recent example, see this launchpad page: https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/431091

Among the many complaints was this:
This breaks the Tax application virtually every Swiss citizen has to use

And the answer?
We arent going to re-introduce ancient gcc versions.

This is not unique to libstdc or Ubuntu, but pretty much any library and any distribution can and does cause these issues. If you introduce this system into Haiku you might as well be purposefully sabotaging it. What Linux is using is tailored specifically for the unique situation that created Linux, and bringing that to Haiku would be shameful, incompetent, and a huge mistake.

29

Well you certainly seem to loathe linux package management as if it ate your children in front of you. I do think that it has its uses, maybe not the exact system linux uses but the idea has some interesting qualities, for example you have a reasonably central repository for programs and you can get them easily, you don’t have several million different installation programs that all do things differently, you have one place where you can remove the things you no longer want or need without having to search for the particular uninstaller program. I think while it has it’s flaws there are also benefits to be had from a package management system, if you are reinventing it from the beginning in a way then you can change some aspects to help avoid some of the flaws too.

30

A linux-like package manager should not be used for Haiku. As was stated before by a few others, package managers were created to as a solution to software management on the *nix systems due to their design. The package manager system in NOT as simple a solution as a bundle/folder-based system. The package managers themselves are bloated frameworks that can eat up memory/disk space–YAST is an example of this.

A central repository is not necessarily a good idea either. It requires a drastic increase in resources across the board and is something better suited for package manager systems. There are websites dedicated to BeOS and Haiku software. Once Haiku goes stable it could simply point users to these sites from the main page. This will allow the core Haiku devs to focus solely on the Haiku system itself, which would actually help it evolve faster.

There is also the problem of software interdependency. I have seen a library upgrade break an entire system before simply because all of the bugs were not worked out. This is a problem that ALL linux distros have had to deal with before. I have seen people who could not upgrade their systems(Fedora, Ubuntu and Debian to name a few) simply because upgrading a few libs would render many programs–sometimes vital ones–useless. Not to mention virtually every package manager has a tendency to leave pieces of software/libs behind once a program is uninstalled–and NONE of them are perfect. A bundle/folder method would be a more stable solution.

Now on to libraries and bundles. Bundles in Haiku WOULD NOT(and SHOULD NOT) be anywhere near as large as bundles in linux. Linux is a kernel. The other *nix-like systems are command-line based OSes. Graphical systems, audio systems and all the frameworks to use/interact with these systems are added on(Linux just more so). As a result, numerous options were created to fill in these gaps and provide the desired functionality. Unfortunately, this leads to a LOT of wheel reinventing. On top of this, there are no TRUE standards because not everyone follows the existing attempts(nor do they HAVE TO due to all the options). A developer writing a program is practically forced to design the software to allow compatibility with a wide range of software just to suit wide variety of tastes.

Haiku does not suffer from that problem. It has an integrated GUI and sound system. It has standards that need to be adhered to in order to write programs for it. It does NOT use X-Windows. It does NOT require QT, GTK, FLTK, OSS, ALSA, ESD, ARTS, Pulseaudio or ANY window manager/desktop including(but not limited to) all the various incarnations of software/libs related to them(e.g. ALSA-ESD, ALSA-OSS, OSS-ALSA, etc.). As you can imagine, as you trim of each of these pieces of software, the actual size of the program itself will shrink noticeably.

As for running duplicate libs from multiple programs. The only remaining libs remaining(after all of the above is chopped off) of any actual size would be the programming languages. If these were included in the OS itself(if the devs feel that is a good idea) this would be a non-issue. Disk space and memory are pretty cheap nowadays. You can get netbooks with at least 1GB ram and a 250GB Hard drive. On top of that, with Haiku being a desktop-oriented OS, chances are it will not be pushed to it’s limit on a day-to-day basis by its users. Especially if we’re talking about the everyday average user.

When someone says “Haiku is not Linux”, they are not saying that as an attempt to wave someone away. They are saying it BECAUSE Haiku is nothing like Linux. If you want QT apps installed by a package manager with the software stored across your system according to functionality…then stick with Linux(or one of the other *nix-based systems). Trying to bring over/incorporate *nix solutions to *nix problems into Haiku is a very bad idea and a very poor choice. Please remember what Haiku is all about and keep that in mind.

31

[quote=Denise Purple][quote=TeDiouS]Use of the Haiku API, as the main, is great, (I don’t like using QT apps on my GTK desktop and vice versa. [That doesn’t take functionality away, only the “looks”]) but what about different libraries, what if I want just one library, what if I want a whole assortment? Would I need to go from site… to site…to … site… to find them. That’s what I would consider a dependency hell.

If Haiku is getting one, very nice. But if it will only download one file, that includes everything…
I’ll avoid that for many reasons: Size, bug in the app that would make me need to redownload the whole one file, some apps use a library not included in the Haiku release and the same library would be downloaded/installed, multiple times, redundancy is great, but not w/ apps, etc…
“Hey Bob, I have 3 installs of >insert web browser here< on my system!” - Why not just open it three times?.. “…”[/quote]
It seems that some who are commenting here don’t know (Or because of Linux-zealotist ideals don’t want to know) how an ideal application for BeOS/Haiku is actually distributed when it comes to libraries and such. An application for BeOS/Haiku should always come with a lib/ folder with all needed libraries, inside the respective application’s own directory. With this model there is no dependency hell, no searching for libraries on the internet, no “mess”. So don’t use these bogus arguments, and try to stick to real issues, please.

With this model, an application works out-of-the-box, it’s organized, it doesn’t pollute the system, and it’s portable. I think this model should be kept. Now, I do know that some applications go against the rule, though, and there should be ways to enforce the right way of distributing applications…[/quote]

My ideals are quite simple really: Get what I need/want to do, done. And with a GNU/Linux system I can do that. Not everyone can, and good news… I’m not everyone.

That’s not even close to what I had meant… If there was a BUG (Get that? To the left of this. Yea, there <–), or some other thing, in the lib bundled, and it had some /“issues”/. I would not want that on my System, even though it might be “clean” b/c it’s in it’s own directory… Some people like it, some don’t. I… don’t prefer it. Hence why if I /really/ needed to use the app, or /really/ wanted to. I would download the updated library. And if I can’t find it? Tough **** for me, eh? People are different. Not everyone will want that. Or not want it. Good thing this project is F/LOSS…

[quote=Denise Purple]
The only real issue here is the file size, but I don’t think that outweighs everything else. Nobody has a 20 GB hard-drive these days anyway (And how big can an application be? This isn’t Windows with its several hundreds of MB’s big apps)…[/quote]

How ignorant. What if someone, yes, someone, as in not you, only had a 20GiB HDD? What if they had a 15GiB. What if, etc. - Think of future use. Say: lib001, was in app001. And lib001, was in app002. And a new version of lib001, was in app003. The process continues. If it’s a “popular”, it might be in the main release, might not as well. lib001 could range from, I don’t know… 300k-4MiB. Doesn’t matter, having multiple libs that are the same, isn’t “clean”. It’s a waste of space.

Not trying to push for apt/yum/etc for Haiku. And these two OS’(I know what Linux is, and what the userland is on some… please don’t try to use this as a reason of comment…) are quite different. But if there is a way to add/remove/upgrade/downgrade packages, libraries, applications, etc. That would benefit myself and others (I don’t mean everyone). I won’t try to “force” a Linux-like package manager, it would be nice to have, but if not included in release, I’m sure I can find some other means. I really do like what the devs and community have done with Haiku so far, and can’t wait for more.

Could there be a way of libs/files included in certain apps to have a version check, that compares w/ an online repository/mirror/dl-link/Something that won’t bring more of an argument? Hopes that calms the fire

32

If this is more about the “nice to have” factor, then I don’t see why we’re having this discussion in the first place. You can download a Linux-like package manager like box (Included with TiltOS) and install all those great libraries like x11 etc if you want. Also, if you don’t want the application package you downloaded to contain any libraries, you’re free to delete the lib directory and manually install libraries onto the OS itself if you want (Yes, most apps will work if you do that as well). About the 20 GB hard-drive… I don’t see why you would even use a computer with such a small hard-drive today (Especially if you’re coming from Linux), or even 6 years ago, but whatever you say, I guess. I’m giving up on this topic, have fun.

33

Such a bad delay, sorry about that.

Having things, are /nice to have/. And something that updates files w/o micro-management, seems like a plus. Especially for security reasons.

[quote=Denise Purple]
You can download a Linux-like package manager like box (Included with TiltOS) and install all those great libraries like x11 etc if you want.[/quote]
It seems you’ve mistaken my point, I don’t want to have *nix made applications installable, per se. But in a similar fashion of how the updating works. Or how installation is.

Yea, I’ll go right ahead and do that. Thanks for the insight.

[quote=Denise Purple]
About the 20 GB hard-drive… I don’t see why you would even use a computer with such a small hard-drive today (Especially if you’re coming from Linux), or even 6 years ago,[…][/quote]
Does it boggle the mind that not everyone can afford large HDD’s? Or that not everyone wants to upgrade their computer they’ve had for a while. Could be a personal preference, if you disagree, ask someone who isn’t biased. And the “coming from Linux” remark was poorly thought out… I use/install GNU/Linux in many machines, ranging from current year hardware, PentiumIII era, K6, etc, I hope you get the picture.

[quote=Denise Purple]
[…]but whatever you say, I guess. I’m giving up on this topic, have fun.[/quote]
Ok, thanks.

34

Hello, I’m new with Haiku, but about this topic, there is a solution:
http://haikuware.com/directory/view-details/development/app-installation/synthetic-package-manager-pro
In the Youtube videos looks great!!!
Buy the way, If you want see more of Haiku using Virtualbox:
http://haikuware.com/directory/view-details/development/app-installation/senryu-personal-edition-vmware-image-monthly
Great Os, fast, and works with little resources, please better documentation for the rookies (newcomers).

35

[quote=cb88]You act as if Linux can’t install 3rd party apps… when in fact i can download a .deb and click on it and as long as you don’t have some ancient package it should work just fine.
[/quote]

Wait! You mean that an RPM-based system can run DEB files without me having to find a tarball–I mean without me having to find some source code to compile in order for it to run?!? O.o How?!

36

Well you’ve gravedug an already annoying thread which really wasn’t anything but a flamewar between people with no control over the matter (like myself) and also likely to have narrow minded views.

But anyway… a deb is in fact a compressed tarball with the deb extension just rename it and extract it.

Sure you are throwing away most of the convinience but most likely it would work… and has many times in my experience.

Funny though rpms are quite a bit more complex format wise than debs so you have have some alien package installer to extract those I believe.

37

It seems this discussion/argument arises every few months!

I am happy that haiku is going with a “linux” style package manager (you will see that macosx and windows are going down the same path - Software Update, App Store etc).

If haiku is going to gain ground against other more established open-source and commercial operating systems it is important to have a community driven software repository. That way people in the community can rally around a single point (such as http://aur.archlinux.org) and port software from other platforms to haiku. Its also important to remember that its not always the developer of the software that makes it work on a secondary operating system.

A common theme throughout computing history is the most compatible wins. So its important to make it easy for software to be ported and maintained. Placing this responsiblity on the developers is to ensure the death of haiku.

A factor that will also arise quickly once haiku gains traction is security. Having a central software repository for haiku will allow the core/community software maintainers to examine software for security vulnerabilities, that is Trojan’s, backdoors etc. A user installing software from a repository will provide a level of confidence that the software does not contain malware/malicious code and will work cohesively with the operating system.

If you have not used all main operating systems OS X, Windows and Linux for least several years and gained a decent level of experience on package management and different approaches, you probably should keep your views to yourself and let those with an informed view and experience make the right/most justified/educated decision for haiku.

38

With a linux style package management it is virtually impossible to install software without an internet connection.

39

Big difference… between impossible and virtually impossible no reason the packager couldn’t be able to generate download scripts that could be ran from your favorite other OS with a network connection.

Also consider this… having a package manager like Linux with a long stable release cycle means that the amount you have to download is greatly reduced compared to not doing it this way. Libraries don’t have to be redownloaded each time a program needs them they just link to the same ones that are supplied by haiku SAVING YOU BANDWIDTH on your often metered internet connection.

40

We’ve all stated what we do and don’t want in the package manager, but does anyone know what the plan is for the package manager. The ideas page has been taken haiku dev.