Reasons against a linux-like package manager?

Forum thread started by alexei.boronine on Fri, 2010-04-09 06:10

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.

Comments

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

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 ;-)

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.

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

alexei.boronine wrote:

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.

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

alexei.boronine wrote:

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.

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.

alexei.boronine wrote:

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.

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.

Re: Reasons against a linux-like package manager?

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

Re: Reasons against a linux-like package manager?

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%28WS.10%29.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)

Re: Reasons against a linux-like package manager?

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"?

Re: Reasons against a linux-like package manager?

alexei.boronine wrote:

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"?

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.

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

halo wrote:

They treat closed-source and commercial software as second-class citizens.

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)

halo wrote:

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.

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.

halo wrote:

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.

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.

halo wrote:

Makes software deployment much more complex than necessary.

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.

halo wrote:

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.

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.

halo wrote:

Often this also means it requires admin priviledges, which is a problem.

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.

halo wrote:

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.

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.

halo wrote:

Doesn't discourage [you probably meant non-]native applications. [...] Doesn't discourage excessive external dependencies.

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.

satsujinka wrote:

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.

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.

Re: Reasons against a linux-like package manager?

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..

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

TheD3vilHimself wrote:

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

+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).

Re: Reasons against a linux-like package manager?

tonestone57 wrote:

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.

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.

Denise Purple wrote:

I am just getting more and more confused of what we're really debating about.

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.

Denise Purple wrote:

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.

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.

Re: Reasons against a linux-like package manager?

halo wrote:

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.

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.

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

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!

Re: Reasons against a linux-like package manager?

DavieB wrote:

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!

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

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

TeDiouS wrote:

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?..* "..."

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)..

Re: Reasons against a linux-like package manager?

Denise Purple wrote:

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.

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.

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

Denise Purple wrote:
TeDiouS wrote:

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?..* "..."

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...

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..

Denise Purple wrote:

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)..

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*

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

Such a bad delay, sorry about that.

Denise Purple wrote:

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.

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

Denise Purple wrote:

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.

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.

Denise Purple wrote:

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).

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

Denise Purple wrote:

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,[...]

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.

Denise Purple wrote:

[...]but whatever you say, I guess. I'm giving up on this topic, have fun.

Ok, thanks.

Re: Reasons against a linux-like package manager?

Hello, I'm new with Haiku, but about this topic, there is a solution:
http://haikuware.com/directory/view-details/development/app-installation...
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...
Great Os, fast, and works with little resources, please better documentation for the rookies (newcomers).

Re: Reasons against a linux-like package manager?

cb88 wrote:

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.

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?!

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

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

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

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.

Re: Reasons against a linux-like package manager?

Linux like dependancy resolution
versioned library support so you can run older packages as well as the latest and so on...
packages are will be mounted as disk images and mapped onto the regular file system so pacakges install nearly instantly

So its simple enough to understand but has enough complexity that it can handle alot of different use cases.

Re: Reasons against a linux-like package manager?

I would like to hear a statement of a core Haiku developer here...

I love the way to install software in its own and one folder...

...and delete the whole app with its libs without worring to delete libs used by other apps...

Re: Reasons against a linux-like package manager?

Why not read the blog posts then, those are the statements from a core Haiku developer.

Re: Reasons against a linux-like package manager?

cb88 wrote:

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.

This is exactly the scenario I meant. Download a package on windows machine then try to move it to target computer via memory stick.

If the dependency resolution was on the repository side it could just as easily create a stand-alone installer (via a web interface to the repository). The package manager could be used on your own haiku computer to update/install in linux type fashion. That download script is a smart idea.

Re: Reasons against a linux-like package manager?

kidd106 wrote:

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.

http://dev.haiku-os.org/wiki/PackageManagement

There are several pages now.

Re: Reasons against a linux-like package manager?

I've taken the time to read through, phew.

Dropping a file into a folder is not elegant, its lazy.Pointe finale. It merely wreaks of a security model that is ill conceived at best. Were talking about precompiled binaries, this isn't windows or ubuntu common now.. seriously. Despite your beliefs, dropping a file in a directory - in this context - would be "software installation". Your adding software ?!

I've read through Trac, it looks decent so far; yet it seems like its leaning towards redesigning a wheel were some existing solutions operate well.

I highly recommend devs take a look at the *how* of arch linux' package management. Its employs alot the techniques that are being re-coded in Trac.

- Packages are using LZMA2 compression. This has been proven stable and fast.
API is similar to zlib - http://tukaani.org/xz/
- The Package Format is very similar to an archlinux PKGBUILD - http://www.archlinux.org/pacman/PKGBUILD.5.html#_example

I'm still left wondering about the validity of xar type package format in this instance.

Nearly the whole 'Package Management Infrastructure' are/is how packages are handled, sans the daemon and folder structure.
--

As far as self hosted repos, there is nothing wrong with that in *capable hands*. Infact it should be fostered as a means of improvement, lets bolster more open source development. If one is not capable, no problem. Give them what works, the fastest.

Bundles and dependence are handled in arch via the PKGBUILDS;

ex..

...
...
groups=('xfce4')
# keep xorg-server-utils for https://bugs.archlinux.org/task/21096
# upower and consolekit for reboot/shutdown/hibernate/suspend
depends=('xfce4-panel' 'gconf' 'libgnome-keyring' 'libwnck' 'libsm'
'xorg-iceauth' 'upower' 'consolekit' 'hicolor-icon-theme')
...
...

so pulling xfce4 will offer the whole group *and* list numbered packages.
--:verbatim
:: There are 16 members in group xfce4:
:: Repository extra
1) exo 2) garcon 3) gtk-xfce-engine 4) terminal 5) thunar 6) tumbler
7) xfce4-appfinder 8) xfce4-mixer 9) xfce4-panel 10) xfce4-session
11) xfce4-settings 12) xfce-utils 13) xfconf 14) xfdesktop 15) xfwm4
16) xfwm4-themes
--:verbatim

I'm hoping this sheds some light on legacy alternatives literally taking a new look at whats working and why. Again, I'm all for striking out a new path; yet lets not 'throw the baby out with the bath water'.

repectfully,

~Nolo

Re: Reasons against a linux-like package manager?

A package manager is a solution to a problem that Haiku should avoid having in the first place, which is a filesystem organization that encourages a single piece of software to scatter itself all over a disk. There are cases where an app depends on a library that needs a security update, but equally many cases where irrelevant library updates can break old code. All things considered, the arrangement most conducive to reliability is that software should come packaged with exactly the libraries it was designed, built, and tested against. At most there should be a system to track the libraries a package carries with it to support user-initiated injection of updated libraries, but ideally such updates should come from maintainers after full integration and regression testing.