Reasons against a linux-like package manager?

1

There seems to be a consensus on the fact that Haiku should have a package manager unlike the ones in most Linux distributions. It is very strange to me, I think Linux has a superior software installation system that: 1) does not use more space than required, 2) provides quick and easy updates, 3) allows easy installation of software and such programs as Ubuntu’s “Software Center”, 4) allows the system to manage its files whichever way is more effective and efficient.

Two reasons against it (that I found) are:

  1. Dropping a folder or unzipping an archive is simpler and more elegant than “software installation”. Why so? In Ubuntu, you can install any program by browsing the Software Center and clicking install next to what you’re interested in and uninstall next to whatever you want to see gone. What can be simpler and more elegant than that?

  2. Each program should be in a specific location and shouldn’t scatter files all over the system. Again, is there a strong enough reason for this (especially to the casual user, who doesn’t know or care about this stuff) that leads people to prefer it over a more effective system where files are grouped by their function: binaries with binaries, libraries with libraries, fonts with fonts etc. It seems that making a system purely based on bundles is extremely ineffective while making some programs use bundles and some not is extremely inelegant.

The bottom line: I think that Linux-like package management (while (very arguably) inelegant) simply works very well. From both the system’s perspective (having an organization of files that is most effective) and the user’s perspective (being able to click “install” and “uninstall” without having to care about what’s going on behind the scenes). I’ve been a Linux user for only four years, but in those years I’ve never had a dependency problem on my Ubuntu and Debian systems, “dependency hell” seems to be a thing of the past.

Reading some stuff on the internet, I see lots of people arguing for non-installation systems while failing to provide tangible reasons for them. I hope someone can explain to me what this is all about.

By the way, for any dev that may be reading this, Haiku totally rocks my socks off!

UPDATE:

Here is my list of downfalls of bundles:

  1. Most applications will be dependent on libraries. I see two implementations:
    1. Fat bundles. There are two problems with these:
      • Libraries need updating, some updates are crucial to security, how are you going to update a library inside a bundle? Is Haiku going to peek into each bundle? Is Haiku going to have a secondary location for libraries? If so, what's the point of including them in bundles in the first place?
      • Some libraries are so huge that putting them in fat bundles would be just crazy. Say you have 10 Qt applications. You're not going to have 10 copies of Qt in your filesystem, right?
    2. Have a secondary linux-like package manager which will take care of libraries. There are two ways to do this:
      • Provide an installation script with the bundle. If so, why not have a real package manager in the first place?
      • Make Haiku look for libraries each time you run the program and offer to install missing libraries. What if the user downloaded a bundle, copied it into his file system thinking how easy and user-friendly installation is and then went offline only to find out that he can't use the program
  2. So I installed a couple of Qt apps. The Qt library magically appeared somewhere. Now I want to uninstall them by deleting the bundles. Will the Qt library remain? If so, my system is sure to get polluted with tons of unused libraries. Will Haiku detect that no application requires it and delete the library as well? That's better, but shouldn't I decide? What if I plan on installing something else later? What if I have a limited internet connection? What if I am using the library for developing my own software?

I think that bundles are far more inelegant and ineffective than a linux-like package manager. They will be a mess to maintain, they are inconsistent by design, they obscure reality and confuse the user with false ideas (the impression that an application exists entirely in a folder is simply wrong because it doesn’t take into account the libraries that are doing much of the heavy lifting).

Furthermore, it is silly to argue that downloading a bundle and unzipping/copying it into some place in the filesystem is easier than just pressing “install” in a software manager.

UPDATE 2:

Here are some arguments for a centralized repository:

  1. Source code can be pushed to the repository and can be automatically compiled to multiple processor architectures. Look here: http://www.debian.org/ports/ do you think each Haiku developer would have ported his app to all of these? No, we would be lucky to have amd64 supported, and there will be almost nothing compiled for any other system.
  2. Updates are easy and quick. How do you see an upgrade on a Haiku-like system? Will each bundle have its own update checker?
  3. Installation is EASY. How on earth is looking for the developer's website, downloading a gigantic fat bundle taking care to choose the right one for your processor (explain that to my grandma) easier that just clicking "install" in a software manager next to the app you want??
  4. There is only one copy of each library and it stays updated. As I said previously, if you have 20 copies of the same library in 20 bundles, who's going to be updating them and how? Some updates, I point out again, are critical, security stuff, do you expect every developer to be on top of security issues of each library he is using and to quickly provide new gigantic bundles whenever a security update comes out? C'mon!
  5. Developers won't have to host and maintain their websites. Open source developers may not want to waste their time with web design, but without a centralized repository, you are forcing each developer to host their own programs, and each user to dig through butt-ugly websites to find what he needs. A solution to this is having a website like bebits.org, but if you're going to have a centralized software source like bebits, you might as well have a centralized repository, which does that and much more.

Haiku has to embrace the Open Source world. If you expect companies to eagerly start porting their proprietary apps to Haiku you are wrong. On the other hand, to tell an open source developer to bundle his applications with all the libraries, to host those fat bundles (multiple huge bundles for each app – x86, amd64, ppc etc.) on his own website and keep them updated with all the libraries is to tell him to go f*ck himself. Not in 2010.

UPDATE 3: It was pointed out to me that Qt binaries are quite small, I actually didn’t check before posting. A better example would have been something like Mono.

2

Another reason against a linux-like package manager is that Haiku simply isn’t Linux.

I’ve been a Linux user for only four years, but in those years I’ve never had a dependency problem on my Ubuntu and Debian systems, “dependency hell” seems to be a thing of the past.

The package manager downloads dependancies automatically.

3

A software catalog is a good idea, one thing that I dislike about linux in that regards is that no one system does it the same so it always feels different in every distro and devs can’t make up their minds. A catalog is fine and dandy, it could also support paid apps if needed and maybe have a daemon that monitors for updates. Not too long ago somebody posted about using bundles. Bundles (like .app bundles in OS X) have the advantage that as far as the user experience even if dependent folders are left behind when deleted the user feels like he’s in charge. Also it’s easier to sort through your installed applications from the source where if you just point to binaries and depend on shortcuts these shortcuts can be lost and deleted in some cases and you’ll have users reinstalling software when they just lost a link.

Haiku isn’t linux and that’s a good thing. Being able to provide a consistent experience is a very big deal.

4

Actually, unzipping an archive to a directory like /boot/apps/ IS easier. With Linux you are always dependent on the package manager to hide all the complicated work for you, and it’s not really flexible. For a first-time install, the package management in Linux may be good enough, but otherwise it can be quite a hassle. In Haiku, I can just copy every folder in /boot/apps/ to a temporary location, then wipe out the entire partition and just copy them back to a new Haiku installation. Or, I can just keep the applications on another partition all the time if I want. That’s the beauty of it. There is no way that I could just copy every file from a Linux application, and then copy them back to the right directories after a reinstall or whatever, and do this for every application I need.

Now there are some applications that install in a Linux-ish way too, but I generally think that’s a mistake and that those applications should be fixed. There are some major things, like Qt, which might be better to have installed globally, but this practice should be kept to a minimum IMO.

5

The123king: Another reason against a linux-like package manager is that Haiku simply isn’t Linux.

Sorry, this doesn’t make sense.

TheD3vilHimself: shortcuts can be lost and deleted in some cases and you’ll have users reinstalling software when they just lost a link.

While it is true, I think the cons outweigh it (see UPDATE in my original post).

TheD3vilHimself: Haiku isn’t linux and that’s a good thing.

I can turn this argument around by saying that Haiku isn’t OS X and that’s a good thing :wink:

Denise Purple: With Linux you are always dependent on the package manager to hide all the complicated work for you, and it’s not really flexible.

I strongly disagree with this statement. A linux package manager is actually very simple in design, when you are installing a program it firstly resolves dependencies (our bundle system will have to do the same thing, there is no way around it, the only difference is that while Linux is honest about what going on behind the scenes, our system tries to hide it in favour of making a false impression of simplicity). Then the linux package manager installs each package by distributing its files across the file system. Their locations are recorded in a database so packages can be cleanly removed. There is nothing complicated about it, the process is entirely transparent.

It is also far more flexible because you have full control over what software and which libraries you have installed. If you are a casual user, you will be given a list of application to install/uninstall, and the stuff behind the scenes won’t bother you. If you’re a power user, you will be given a list of all the packages.

Denise Purple: In Haiku, I can just copy every folder in /boot/apps/ to a temporary location, then wipe out the entire partition and just copy them back to a new Haiku installation.

While I can see how it is easier to migrate full applications from one installation to another (provided that some obscure magic takes care of libraries and all the dirty little hacks and nicks that will have to be used because of the rigidity of the system), it is a rare task to perform. If a user decides to install Haiku to another computer in his house, he can probably afford to reinstall his favourite programs, especially having a software manager with a friendly interface. Having said that, this is a valid argument in favour of bundles, though again, it still doesn’t quite outweigh the ones against, at least for me.

6

Could you guys take a look at this following approach to app packages. I think it is a very trouble free approach as it is was designed to work on a mobile platform. I think it would be phenomenal if haiku programs were handled like this.

  • http://pandorapress.net/2009/11/10/brief-video-pnd-packages-in-action/
  • http://pandorapress.net/2009/12/01/pxml-validation-tool-for-pandora-apps/
7

This is way complicated. A typical BeOS/Haiku app should have all libraries in its own lib/ directory. One simple unzipping, done.

I think it’s pretty hard to be in control of that as a casual user in a Linux system. On Ubuntu at least, hundreds of libraries are already listed in the package manager, and it’s pretty hard to make out what you actually need. --autoremove is a good command-line option to deal with that, but sometimes it removes stuff that shouldn’t be removed.

Libraries and all should be organized inside the application’s own directory and its subdirectories. Libraries go into /boot/apps/APPNAME/lib/. Also, Haiku is not meant to break binary compatibility that often. There is no magic involved at all. Actually, I came from Ubuntu, and I have to say No, reinstalling all applications is quite a hassle at least for me.

Now this example is on Windows (Since Haiku doesn’t have that many applications yet), but the concept is the same: I have about 60 different applications under the emulation category alone. It is much easier to just keep them under one directory, and get to work instantly after a reinstall, than having to also reinstall them as well, one-by-one, even provided package management is available. I also have to add, since they are generally self-contained, pretty much no libraries have to be installed after reinstalling the system either.

8

The funny thing is that Linux apologists always bring up the freedom point but actually an average Linux distribution is not so free for the average end user. In fact, it is way more closed than competing operating systems.

The software repository is typically maintained by distribution maintainer and average guy who only uses his mouse finds out pretty soon that the root user of his system is some guy in South Africa or some other place. I personally find it intimidating not being able to install some required software by just few clicks/keypresses just because that distant guy decided not to provide prepackaged version.

Not to bring up the clutter this approach leaves behind. When I need some app to do one time task, it may install gazillion of libraries which stay polluting my system if I’m not very good at keeping an eye on my doings.

Haiku guys do not see themselves as software distributors, in fact it seems they welcome system buildes, OEMs and other people to use their software. By keeping the end user software management out of their scope is probably better decision than building a repository of every known app that runs on Haiku. And even if they did, they could not possibly supply users with some “killer apps” like Gobe (excuse me, but this seems to be the only fair example).

What Haiku could do is to provide a mechanism for updating the core system and that’s about it. It could be extended to some kind of update_server API other software vendors could use like this:
Hey, server, here’s the InfoFile, work on it. The update_server will carry out the instructions in the file - check new version online, download files, unzip, copy to disk. Or if the new version is built on never version of core stuff, it would simply fail to upgrade by saying that the system needs to be upgraded to v? first.

Oh, the dependencies. They aren’t much of an issue if the system has been designed properly and all core functionality is already provided with it. The software vendors should be using functions provided by the core system in first order and only failing on that should use 3rd party components. Which should be then part of the application, not the system.

Missing shortcuts when unzipping, dropping unzipped folder into /boot/apps? There are attributes. The main executable should have an attribute like “Application”. The app should instantly appear in /boot/home/config/be/Applications_Query

9

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.

The problem with dependency hell is that releases and updates happen so often and if you are using a binary package it may well not work if it isn’t statically compiled or includes its own libs…

*IMO apps in the repo should use a package manager of sorts

*Apps outside the repo should include all needed libs or be static and only require unzipping in boot

Perhaps a guideline that states that minor releases may break repo packages but not static and that major releases can break anything.

If you say that a minor release can’t break repo packages then you a in the debian stable situation its just too old. Packages such as SDL for instance what happens if a game needs 1.2 and the other needs 1.3 do you just say no 1.3 games and then there are compile options sometimes not all features are enabled? Do you really want every app to install all of its own libs?

Windows has a package manager too (http://technet.microsoft.com/en-us/library/cc748979(WS.10).aspx)… also note that even if you are using a package manager customarily you can install non repo stuff in /opt on Linux assuming you have the privileges (which I think on haiku will be the same as Windows ie you aren’t a guest)

10

I updated my post with some arguments for a centralized repository.

@Denise Purple

Much of my reply is in the update of my original post. As for your example with reinstallation, as you can provide anecdotal evidence on one side of the question, I can provide it on the other. I’ve done an extraordinary amount of distro-hopping and installing all the applications I need is very easy and quick under a Debian-based system. Your argument still stands, but I remain unconvinced that it is a major thing to to take into account when there are so many more serious arguments against.

mude: I personally find it intimidating not being able to install some required software by just few clicks/keypresses just because that distant guy decided not to provide prepackaged version.

Firstly, I have to say that there were maybe one or two times in my entire Linux career when I had to install a program from sources. And these programs weren’t some end-user apps. Secondly, there are tons of open source software available at the moment, if most developers aren’t even packaging their software for Debian or Ubuntu (that’s a HUGE user base) what makes you thing they’ll start eagerly packaging it for Haiku? Especially if Haiku makes it such a pain in the ass with fat bundles?

mude: When I need some app to do one time task, it may install gazillion of libraries which stay polluting my system if I’m not very good at keeping an eye on my doings.

This is a trivial problem. You can set up the package manager to remove all orphaned libraries automatically (although, I, personally, would probably turn this “feature” off).

mude: Oh, the dependencies. They aren’t much of an issue if the system has been designed properly and all core functionality is already provided with it. The software vendors should be using functions provided by the core system in first order and only failing on that should use 3rd party components. Which should be then part of the application, not the system.

Have you ever installed a Linux program to see that it pulls in a ton of dependencies? You know why? Because that program needs a ton of dependencies. Do you expect, say, a Qt app written in Python that uses, say, MySQL for storage to include all of that inside the bundle? Or are you going to tell the developer that if he needs so many 3rd party components his program is not “properly designed”?

11

[quote=alexei.boronine]
Do you expect, say, a Qt app written in Python that uses, say, MySQL for storage to include all of that inside the bundle? Or are you going to tell the developer that if he needs so many 3rd party components his program is not “properly designed”?[/quote]

I’d say - yes, it’s badly designed. Well designed program would only take what the core system has to offer - the GUI, the storage &c. In your case, the Qt app example is IMHO not very well designed (assuming it’s a desktop app). Why the hell desktop user needs database server? Why the mysqld needs to be running all the time when I only use the app twice a month? I’d suggest the developer should consider more lightweight solutions like SQLite or similar. Or better yet, if the developer would like to be the app more scalable, just default to SQLite and give option to connect to MySQL.

Ideally the core system should be providing those capabilities in the form of Database Kit (NeXT, anyone?). Of course, Python should be part of the system in this case as well.

Well, all the above would be the case in the ideal world. We live in the ecosystem where any software is scarce and we need to cope somehow. But that doesn’t justify badly designed systems and applications. In any case the single-user desktop app should not require server components and any non-standard components should be self-contained. The package manager only makes some sense if the app depends on some third-party components that are typically maintained and updated separately from the app itself. But even then if the components is not part of the system, it is part of the app so the app provides should make the component available. The package manager only hides the problem from the end user.

Say, an app requires libxyz v1.0. If the libxyz is updated separately from application the app may break if not properly maintained even if it worked perfectly when using library version 1.0. If the app providers see that they benefit from moving to library v2.0, they will do so and release a new version including the updated library.

The bottom line is that if application developers use 3rd party frameworks instead of core OS capabilities, the OS provider can not help here. If the OS vendor decides to make MySQL part of the system, then, of course using it is normal and it would be updated during the system update. In Linux world, the package manager is required because large portion of available software is made part of the system.

12

First of all, I hope we’re debating about the same thing. I have nothing against repositories, or getting applications mainly through the package manager with simple clicks. I don’t think anyone has argued against that.

Also, my calling Linux-ish package management complicated is not because it’s so complicated to click Install and enter your password. The complicated aspect is all the stuff that goes on in the background. Many users probably have no real clue what the package manager in Linux is actually doing, they just have to trust that it’s doing the right thing. This basically means that if anything goes wrong with the package manager, you’re screwed. This has happened a few times for me in Ubuntu, and the only solution would sometimes be to reinstall the system. While desktop-oriented distributions have done quite a good job at hiding this and only showing the user a pretty GUI, it feels too much like a hack or a band aid solution. Especially for example when you have no idea why the installation suddenly has paused because for some reason it needs a key press, and it forgot to tell you about this.

What you said about telling developers to fuck themselves is really exaggerated. A “huge” library like Qt can take about 3 MB to include with an application. This isn’t really a lot in 2010. It’s not hard to package either. Have you ever taken a look inside a .deb file? It’s pretty ugly. Let me give you a good example with a Qt application of what it can look like with a self-contained application, to make things more clear:

bsnes/

bsnes
bsnesd

bsnes/lib/

QtCore4.so
QtGui4.so
snesfilter.so
snesreader.so
supergameboy.so

Now, Qt is a foreign GUI framework. While nobody can stop you from using it, Haiku has a GUI framework, among other things, of its own. The three other libraries here are specific to this application, and weigh around 1,5 MB. This is one very important difference between Haiku and Linux: Haiku has a standard for developing applications. Because of this, applications will always be judged according to their level of “nativeness”, so many dependencies which would be obvious in Linux, should be rare in Haiku, minimizing the problem further.

There is also no need for anyone to create a website at all. Even now, you can submit applications to Haikuware, and this was one of the reasons why it was created if I remember correctly, because BeBits had many dead links and stuff. When a package manager gets up and running, this should be even simpler, at least for the end-user.

About .deb files: Yes, you can download them locally and click on them. But because of how things work in Linux, the application needs to be compatible with the current set of packages (So issues arise every 6 months when you upgrade to a new version of the system, with most distributions). Also, if you’re offline and you’re missing a dependency, you’re screwed. If there’s a library conflict, you’re even more screwed.

13

I’m going to have to back up. It seems that the root of our disagreement lies in our different vision of Haiku’s future.

I think that package management and portability, being able to get any program for any major processor architecture, being able to develop in any programming language, using any framework and any library you want is a huge asset of the Linux world. This environment enables open source developers to make apps for the Open Source world, not just for one operating system. Packaging for any Linux or BSD distributions, for Mac, even for Windows (http://windows.kde.org/ is a primer) is mostly a matter of compiling tarballs.

I believe that Haiku should embrace this culture and work to make it easier to deploy the countless gigabytes of available free software to this new platform. Forcing developers to do bundles is the opposite of that.

@muda

If Haiku is going to tell developers that depending on 3-rd party components, on different programming languages, on Mono, on Qt and GTK etc is “bad design”, not many people will be interested in developing for Haiku.

Having said that, I do see the elegance in having a tight API, using a single GUI toolkit etc. It’s just that I would give it up in a heartbeat if offered what the open source world already has to offer.

I predict that in a few years projects such as TiltOS will totally overshadow Haiku. They will offer a vastly superior selection of software. For that reason, they will be much more attractive to users, and, in turn, much more attractive to developers.

Time will tell.

14

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

  • They treat closed-source and commercial software as second-class citizens. For me, one of the key differentiators between Haiku and other open-source desktop operating systems is that it embraces closed-source and commercial software. Any package managements system should treat all types software the same, and people looking for an ideologically-driven operating system should look elsewhere.
  • They have a poor user-experiences, in several ways:
    1. 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.
    2. Magic. Linux package managers are infected with the problems of magic form the top-down. The package manager can pretty much do anything they want. This is extremely undesirable for plenty of reasons - whether because installing or removing the wrong package can completely change your system, or simply when things goes wrong. Often this also means it requires admin priviledges, which is a problem.
    3. Updates. While not having everyone rolling out their own update mechanism is a good thing, having updates at the mercy of the package maintainer and the update policy of your particular distro is frankly ridiculous. No-one wants to be stuck with year-old software, or be at the mercy of the decisions of a small number of volunteers to update it. These things should be completely under the control of the developer.
  • Makes it extremely difficult to install multiple versions of software side-by-side.
  • Burden on the Haiku project. Linux-style package management would requires a lot of initial effort, a lot of continuous effort, and significant bandwidth expense, and would vastly increase the scale of an already-large project.
  • Doesn't discourage native applications. Linux has shown that an ugly mix of GTK, KDE, Qt, Mono and Java applications don't make for a good or consistent user experience, and anything that provides a gentle push towards native applications is a good thing. Homogeneity is good.
  • Doesn't discourage excessive external dependencies, which results in an operating system that vastly increases in size over time as people take them for granted. So, yes, I am saying that a music player shouldn't suddenly decides it needs MySQL to list a few songs, which results in other software using it and the entire operating system coming with MySQL.
  • Makes software deployment much more complex than necessary.

Linux-style package managers aren’t actually the ideal. The reason they exist is because they were retrofitted into a legacy architecture, based around a constantly-changing platform with little attachment to backwards compatibility, and that it implicitly encourages an ideology that drove it, particularly in the early days. It’s not because it’s the perfect solution.

15

What exactly is stopping us from doing both bundles and package managers?
It seems to me that the choice should be up to the developer. If they want it in a bundle then they can bundle it. If they want it in the repo then they should upload it to the repo and maintain it there. As the core of the system, all Haiku should do is provide the means to do both. Which means that Haiku needs to have a specification for a package manager (otherwise you’ll end up with the mess of different package managers that *nix systems have.) While you can come up with reasons not to use a package manager for some cases, there is no reason not to have the ability to utilize the strengths of a package manager.

16

No they don’t. Closed source software is welcome in, say, Ubuntu’s “partner” repository, it’s just that most commercial software developers don’t give a damn about Ubuntu. (And they won’t even know about the existence of Haiku, good luck “embracing” them)

Ubuntu has had an Add-Remove program for years, now there’s Software Center, Linux Mint has MintInstall, I’m sure there’s many more.

It will be easier for developers to package their software than to bundle it. Then there’s the vast majority of developers who don’t know or care about Haiku. In this case you have two choices: 1) be “at the mercy of a package/bundle maintainer” (“ridiculous”) or 2) not get the software.

What on earth is complex about it?? The fundamental difference between a package and a bundle is that package gets unzipped across the system and a bundle gets unzipped into a single folder. Boo-hoo! Especially considering the fact that packages relieve the developer of the task of downloading, compiling and bundling 3-rd party libraries.

These are implementation problems, not problems of the package management paradigm. Haiku can implement a package manager to restrict setup scripts of disallow them altogether.

Admin privileges are required when making a change that will affect all users, it makes sense. There is nothing stopping Haiku from allowing package installation for a single user.

This is open source, the project is as large as the number of people willing to contribute. Whether it’s packages or bundles, lots of work will have to be done by lots of developers and package/bundle maintainers. (By the way, making packages is easier than making bundles) The only valid argument here is the bandwidth, but if so many Linux distributions can pull it off, so can Haiku.

The vast majority of Open Source developers are volunteers, their only care is to use their free time as productively as possible. I develop, say, a word processor for Linux (most likely it has already been ported to BSD, Mac and maybe even Windows) and decide to port it to Haiku. Haiku discourages me by saying that it has too many external dependencies and it uses a foreign GUI toolkit. What do I do? Do I start eagerly rewriting my program? No, I’d be wasting time for a few thousand users when my work is needed for a few hundred thousand.

Thus Haiku’s policy saved its userbase from a fine word processor.

You are absolutely right. The only result of Haiku not providing its own package manager is the appearance of spin-offs like TiltOS (I’m certain that at least a couple more will appear in the next few years), which already has superior potential than its parent. Haiku seems to have high expectations for the amount of software it’s going to get just by appearing on the scene. In reality, commercial vendors will not care about Haiku the same way they don’t care about Linux while open source developers have better things to spend their time on than rewriting programs for an unpopular operating system.

17

I am just getting more and more confused of what we’re really debating about. I thought it was pretty much decided that Haiku would get a package manager. And that’s a good thing. What I, and probably many others, oppose, is a Linux-style package manager. If you really like how it works in Linux, then you should probably stick with that, because it goes against Haiku’s philosophy on such a core level. If you want to see an example of a package manager that works quite well, although it has some details to sort out, try Synthetic Package Manager (Available on Haikuware). It manages to respect the Haiku way of doing things, while providing a simple way to install applications.

I’m sorry to hear that you are feeling let down by Haiku’s “merciless” consistency and vision and thus won’t port your “awesome” word processing application. Now, I don’t know what application we’re talking about, and perhaps it’s really cool, but I want consistency, speed, and ease-of-use. Haiku is a desktop-oriented OS after all. This comes with some downsides, like not being able to just do a recompile, and have any application from any OS work just like that, or not being able to install the OS on your microwave oven. But in the end, this is a trade-off that I can live with, because Haiku provides the best desktop experience so far, and it wouldn’t be able to do that if it became like Linux. What you’re missing from Linux is exactly its problem.

Everything in Linux has layers of layers of abstraction, and there are no real standards for anything. This leads to an inconsistent, buggy and slow experience for end-users. In Linux, you have: ALSA, OSS, ESD, Phonon, Qt, GTK, EFL, Tk, KDE, GNOME, Xfce, Enlightenment, and more, all somewhat incompatible with eachother, and all with their specific issues. Haiku has a built-in desktop environment, its own standards for a GUI, audio, video (Yes, with built-in codecs!) and so on. This is what makes Haiku great. It wouldn’t be like that if Haiku upon boot had to start an X server, 4+ sound servers, 4+ GUI toolkits, MySQL, etc, just because some developer who doesn’t even care that much about Haiku thinks that’s fine because it removes the need of investing any time with it.

About Mono: This is a language, and unless there are license issues or such, I think it should be installed globally, or maybe even be included with Haiku. This is very different from using a foreign sound server or GUI toolkit IMO.

About TiltOS: While I appreciate some of the work kaliber has done on porting, TiltOS itself doesn’t work that well for me, box is unable to install some of its own packages, and it kind of seems like the author is just trying to turn Haiku into Linux (No surprise, he is also the author of a Linux distro, with the same package manager). Even an X server is included in the repos…

18

Haiku will develop a C/C++ Package Manager - hopefully for R1.

The Package Manager will be “loosely” based on Linux style package manager model. It will use same concepts, ideas and principles but will change and improve them accordingly to fit with Haiku. Other words, lots of things will be done like how Linux does package management and couple things will differ.

A general idea (brainstorm) of what to expect in Haiku’s Package Manager is listed here:
http://dev.haiku-os.org/wiki/PackageManagerIdeas

It should be interesting to see what exact differences there are to Linux Package Manager when completed. It could have similar look and feel but hard to say. I myself like Synaptic (Debian) and think it is good to look at for reference. It is a question of what Synaptic does good, what does it lack or do bad and what could be made better/different or more to fit Haiku style.

19

+1

A software catalogue is a good idea if we can define more than one in an InstallationManager : for example
-www.hailu-os.org
-www.haikuware.com
-www.yellowbites.com
… and if it checks for updates.
One thing I can not stand anymore, is when every applications check for its update at startup(or worse, with daemons). It should by the operating system’s jobs ! (and so InstallManager’s job). It’s a matter of UI consistency, performance, resource consumption… and amount of work for developers.

Also, the end-user should by able to tell for each software if he want to update it automatically, manually (when you enter InstallManager) or interactively (InstallManager asks you when it detects a new version).

20

[quote=tonestone57]Haiku will develop a C/C++ Package Manager - hopefully for R1.

The Package Manager will be “loosely” based on Linux style package manager model. It will use same concepts, ideas and principles but will change and improve them accordingly to fit with Haiku. Other words, lots of things will be done like how Linux does package management and couple things will differ.

A general idea (brainstorm) of what to expect in Haiku’s Package Manager is listed here:
http://dev.haiku-os.org/wiki/PackageManagerIdeas

It should be interesting to see what exact differences there are to Linux Package Manager when completed. It could have similar look and feel but hard to say. I myself like Synaptic (Debian) and think it is good to look at for reference. It is a question of what Synaptic does good, what does it lack or do bad and what could be made better/different or more to fit Haiku style.[/quote]

The fact that Haiku will resolve dependencies is great, I still disagree with the idea of having a package as a self-contained blob though. Linux package management (dependencies, updates from repository, organizing files by function) isn’t perfect, but I am convinced that in the Open Source environment it is fundamentally the best solution.

There was a lot of misinformation in this thread, and I tried my best shedding light on linux-like package management since a few here seem to have an irrational fear about it.

To rephrase what I’ve said in my last post, it seems that our disagreement lies in the fact that I would trade consistency for having a greater choice of apps and you wouldn’t.