Package Management - Present and (hopefully near) Future

Blog post by zooey on Tue, 2011-02-01 14:27

One month has passed (too fast), so it's time to summarize the developments
in the fields of package management for Haiku.

Where we are now

Implementation has been started, the following is a list of more or less
working elements of the package kit and accompanying tools:

  • infrastructure classes for translating package management requests into individual jobs and execution support for those jobs
  • request- and job-classes for managing package repositories (adding, updating, removing)
  • classes maintaining and representing package-specific information (package-provides & -requires, package-versions, ...)
  • pkgman - a (console-)binary implementing package management on top of the package kit
  • support for parsing ".PackageInfo" configuration files during package creation, a .PackageInfo file looks like this:
    name = mytool
    version = 0.9.8i-1
    architecture = x86
    summary = "mytool is cool"
    description = "the mytool package
    is a very nice package"
    packager = "me"
    vendor = "my company"
    copyrights = [ "(C) 2010, My Company PLC" ]
    licenses = [ "GPL v2", MIT ]
    
    provides = [
        lib:libmytool = 0.8.5,
        cmd:mytool
    ]
    
    requires = [
        haiku >= r1,
        libssl == 0.9.8
    ]
    

Filesystem structure

Following is the current version of the filesystem structure as it would be with package management active:

+-boot
  |
  +-apps ->             [symlink to /boot/common/pkg-tree/apps]
  |
  +-common
  | |
  | +-cache
  | |
  | +-packages          [dropping a package here will activate it system-wide,
  | | |                  most packages' contents will appear in 
  | | |                  /boot/common/pkg-tree, but specially marked system
  | | |                  packages will appear in /boot/system]
  | | |
  | | +-history         [contains info required for rolling back in time, used
  | | |                  by package manager]
  | | |
  | | +-jailed          [dropping a package here will make its contents appear
  | |                    in a package-specific folder under pkg-tree (a 'jail'),
  | |                    from where only packages that were marked as depending
  | |                    on this one specifically will be able to access it]
  | |
  | +-pkg-tree          [mountpoint of system package-fs, contents of the 
  | | |                  packages in /boot/common/packages appear here, the 
  | | |                  folders follow "Haiku filesystem hierarchy" (to be
  | | |                  defined, an example given below)]
  | | |
  | | +-add-ons
  | | |
  | | +-apps
  | | |
  | | +-bin
  | | |
  | | +-boot
  | | |
  | | +-data            [+ what used to be in 'share']
  | | |
  | | +-documentation
  | | |
  | | +-include
  | | |
  | | +-lib
  | |
  | +-settings          [+ what used to be in 'etc']
  | | |
  | | +-backup          [room for setting backups - used by package manager
  | |                    to backup settings during an upgrade]
  | |
  | +-var
  |
  +-home
  | |
  | +-config
  | | |
  | | +-packages        [dropping a package here will activate it for user]
  | | | |
  | | | +-history       [contains info required for rolling back in time]
  | | | |
  | | | +-jailed        [dropping a package here will activate it jailed for 
  | | |                  user]
  | | |
  | | +-pkg-tree        [mountpoint of user package-fs, contents of the 
  | | | |                packages in /boot/home/packages appear here]
  | | | |  
  | | | +- ...
  | | |
  | | |
  | | +-settings
  | |   |
  | |   +-backup        [room for setting backups ...]
  | |
  | +-mail
  | |
  | +-people
  |
  +-system              [any system-packages found in /boot/common/packages
    |                    will appear here - those contain either a complete
    |                    "system" or small, sequential "system-fix" updates]
    |
    +-develop           [moved here from /boot/develop (except for the 'tools'
    |                    folder), as it depends on the current system - the
    |                    tools subfolder (gcc & binutils) will be spread out
    |                    over /boot/common/pkg-tree]
    |
    +-optional          [moved here from /boot/optional, as the contents depend
                         on the system]

In contrast to the last one presented in my blog, there no more is a separate "ports" tree, ported packages will just be treated as haiku-native packages (the line between these two classifications is too hard to draw). As a result, ports would have to follow some set of Haiku policies, defining where any package may (and may not!) put files. There will be a tool that will check any package against these policies and only packages complying with them will be made part of the official Haiku repositories.

Bits and Pieces

Package "Jailing"

One concept for dealing with ABI incompatibilities is to allow packages to be "jailed": a jailed package will not be activated in the usual manner, but its contents will appear completely separate somewhere in a folder specific to that package. Jailed packages will not take part in package management at all, i.e. the will usually be other (newer) versions of jailed packaged installed on the system.

Now if an update of a (supposedly compatible) library package is found to break one or more applications, the package manager can be asked to jail the last working version of that library package. Additionally, an attribute would have to be added to broken application(s) referring to the jailed version of the library. Upon activation of the application package(s), the package-fs would create links in a package-local 'lib' folder to the jailed library.

What's left to do?

A lot ;-), I'm afraid [in planned implementation order]:

  • the 'package' tool parses .PackageInfo, but doesn't actually write any of these package attributes to the package file yet (I plan to to work on that later today)
  • the repository format needs to be defined and implemented. It's pretty clear that the repository format will follow the example set by Ingo's hpkg format, i.e. it will contain package-attributes in a very compact format that's fast to read.
  • tools for setting up a package building environment need to be created, which will basically setup a chroot environment containing just the packages required for building a specific target package, enter the chroot, build the software and package it.
  • Haiku's package policies (rules about where files of specific types have to go) need to be defined and a tool needs to be implemented that checks hpkg files against those policies.
  • supporting tools for creating a package repository from a set of packages (and uploading that repository to some server) need to be implemented
  • the package-fs needs to support an ioctl that returns information (package attributes) about the currently active packages - this is required by the package kit's solver when it needs to compute the required actions for any package action request.
  • the package kit's solver needs to be implemented, which basically means collecting package attributes from active packages and all repositories and passing them to libsatsolver (the same solver library that's used by openSUSE's zypper).
  • the package kit (and pkgman) needs to gain more requests and jobs, implementing addition, update and removal of packages
  • the bootloader needs support for package-fs, in order to be able to actually find the system (as that's contained in packages, too)
  • a caching mechanism should be added to the package-fs, such that it doesn't need to parse all the hpkg files individually, but instead can store its state and restore it after a reboot (unless the state of packages has been altered, of course).
  • support for package jailing needs to be implemented in the package kit
  • [ probably some more stuff I forgot ]
  • finally, when the package kit itself is working as intended, a graphical package management tool would be cool

That's it for now - I'll try to continue working on this stuff during the next weeks ...

Comments

Re: Package Management - Present and (hopefully near) Future

Wow, thanks a lot for the status report. You've already accomplished a great deal, but I agree it's still quite a bit of work left. The planning is pretty important in itself. You've done a good job there. Some items of the TODO list need further technical planning, of course, like how to implement the chroot feature, or how to modify the boot loader, but as far as the package management itself is concerned, the planning gives quite a clear concept. Thanks for all your hard work!

Re: Package Management - Present and (hopefully near) Future

Concerning the chroot, there isn't that much to do, actually. Chrooting itself works and with bindfs it's possible to bind the existing system folder into the chrooted environment. So all that's missing is indeed a tool that takes care of the installation of build-requirements and the building and packaging of the target software. I suppose we should probably just adjust 'haikuporter' to do that, since it really does a similar job already.

Filesystem structure

One of the really nice things about haiku is its simplicity. The user interface is clean and simple. The system is easy tio use and learn due to the enheritance of BeOS's elegant clean file structure. Remember that the file structure is also part of the user experiance. With Haiku as with BeOS one can quickly become familiar with the entire system. So far that is.

These changes make Haiku look more complex than Windows or Linux. This is not the Haiku way. These changes are for the convenience of the programmer not the user. One dioes not make design decisions based the ease of the programmer, but how the user will interact with the program.

None of these changes are required to have a package manager that will work. Haiku has a "database-like" filesystem that can be harnessed to give the packagemanager all of the required information without ruining the elegance that is Haiku.

SAVE HAIKU

Keep the simple elegant filesystem structure that we enherited from BeOS.

Re: Filesystem structure

I think its fine to have a more advanced file system structure. And in comparison with modern operating systems, the proposed new structure is alot less convoluted than OS X, Linux and Windows. In these systems there are more symbolic links and hidden files then your body can handle. In operating systems of the past it has been shown that the simpler the structure the nastier it gets...look at the System 32 folder in Windows XP. Its a mess.

Also for an end user there is no reason why the more advanced folders can not be hidden by the desktop environment, like OS X does. If you want to access these folders then you either open a terminal or reveal the hidden fodlers from the desktop environment.

I'm all in favour of keeping things simple and clean (unlike Windows and OS X), but to restrict changing the structure due to BeOS legacy fantasies is a little naive.

I must say that package management is a touching issue for myself and will dictate if i use a platform, but i think with repositories and a single package management tool i can breath more easily. Keep up the good work.

Re: Filesystem structure

The more complex the filesystem structure is, the less friendly the system becomes. I remember my first introduction to BeOS, I felt like I was in control of my computer for the first time since I moved on from DOS. This is important. Most computer users are afraid of the system because they cannot make heads or tails of the scattered filestructure. This proposed structure is more fractured and confusing than Windows or Linux.

Haiku is better than this. There is no reason to clutter up the filesystem just for a package manager. The filesystem attributes can be used to accomplish all goals that this mess is attempting to fix. We need to use the right tool for the job. This is like using a jack-hammer to drive a tack.

Obviously I disagree, a simple elegant filesystem structure can be used in a modern operating system.

Re: Filesystem structure

neonnds wrote:

but to restrict changing the structure due to BeOS legacy fantasies is a little naive.

Its't not legacy. What is better: just unarchive and run or introduce hard and unstable package management system, have regular problems with installing and store megabytes of unnecessary files. Answer is obvious.

Some says, that just unarchiving isn't enough, but I don't see in what cases not enough.

Applications
Applications can be installed in /boot/apps folder and store settings in /boot/home/config/settings/[app name]_settings file or /boot/home/config/settings/[app name] folder. For security reasons application mustn't store settings in other places. Application have all libraries(only *.so libraries, not headers or *.a files) in lib folder. Application and its config can be uninstalled by putting it in Trash.

Development packages
All SDKs can be installed in /boot/apps/ too. There are environment setup script present with distribution. It set library, include and path directories in /boot/home/config/boot/UserSetupEnvironment. End user don't need to install development package to run an application.

Runtime systems
Runtime systems are .NET, Java etc. It is usual applications. It set Java, .NET etc mime types and default application. After this you open Java, .NET etc files by double click.

UNIX ports
For ports can be used program like Cygwin. It doesn't pollute file system and can emulate all needed environment. End user ports must be presented as usual applications like Gimp and Inkscape on Windows.

Re: Filesystem structure

Bundling applications has several problems associated with it, all discussed in previous posts about haiku and package management. At the end of the day, package managers and repositories have a superior advantage over bundled applications.

1. A package manager allows for a single entry and exit point of all software entering your system. Thus your filesystem is kept clean.
2. A package repository allows for the community to collaborate and ensure haiku software conforms to packaging standards. Thus keeping your file system clean and your system stable.
3. A package repostiory allows for users to find software from a single source, rather then searching the web for a piece of software, that may or may not contain malicous code and may not have been examined by the haiku community.
4. A package manager can be more user friendly then a download, double-click install approach (why do you think apple has just release the App Store for OSX?)
5. Developers and power users often need to have custom builds of software. If they didn't have a package manager and repositories they would have to seek out the source code, download it, make changes then compile and then install. This would of course mean that software would be installed and not managed, as occurs in OSX and Windows. This means further spraying of the file sytem with un-managed files.
6. With a package manager (such as Arch Linux's pacman and packer) a developer/power user can enter the package name, it will be retrieved, configurable, packaged, and installed all through the package manager. Thus easily removable and managable in the future.
7. A pretty interface can be placed over the cli package manager in the future, to make it similar to the App Store in OS X or Add/Remove Programs in Windows. A novice user wouldn't know what was going on in the background, and wouldn't rightfully care. All they would know is that their system runs forever and software was easy to install. Thus both power users and novice users win.

I have a strong suspicion your primary operating system is windows, and thus why you have such a strong desire to have double-click install bundles. I suggest you use a decent linux distro for a few years and then go back to Windows. I bet you won't feel bundels are the way to go after such an experience.

Re: Filesystem structure

neonnds wrote:

3. A package repostiory allows for users to find software from a single source, rather then searching the web for a piece of software, that may or may not contain malicous code and may not have been examined by the haiku community.

Its bug, not a feature :) In package manager lists I can't find useful, stable, has important features this program for me or not. Better I can search programs in internet, see screenshots, read reports etc and select suitable program.

How developer can put his program in repository? What about commertical programs?

About viruses: if OS has good architecture viruses won't be work. Need kernel protected file system permissions for applications and user rights. For example applications musn't have write access to /system directory and some others.

neonnds wrote:

4. A package manager can be more user friendly then a download, double-click install approach (why do you think apple has just release the App Store for OSX?)

It solved by starting Expander and selecting output to /boot/apps when download is finished.

neonnds wrote:

5. Developers and power users often need to have custom builds of software.

Look at RobinHood server distribution.

neonnds wrote:

I have a strong suspicion your primary operating system is windows, and thus why you have such a strong desire to have double-click install bundles. I suggest you use a decent linux distro for a few years and then go back to Windows. I bet you won't feel bundels are the way to go after such an experience.

I use Haiku, Windows and in rare cases Ubuntu Linux. In Linux I always have problems with installation, like "Unknown error" etc and I don't want to fix package manager problems, it's terrible. Stability and simplicity is much more important then dependencies resolving.

Re: Filesystem structure

bbjimmy has stated pretty much exactly my opinion on all this package management crap. there should be no such animal in this OS. this is not a *nix. don't turn it into one.

Re: Package Management - Present and (hopefully near) Future

Good show!

A gentle, cautionary reminder: don't forget to keep looking for the right balance among technical factors, human factors and Haiku/BeOS system elegance. One cannot achieve optimization in all of them, but one should be able to reach the best middle ground through care and planning.

Re: Package Management - Present and (hopefully near) Future

Well I have to agree with other to keep it simple and if I ask myself is that the file system I would like to have on my computer for ever and ever then sorry to say the answer is no.

"there no more is a separate "ports" tree, ported packages will just be treated as haiku-native packages (the line between these two classifications is too hard to draw). As a result, ports would have to follow some set of Haiku policies, defining where any package may (and may not!) put files."

As a result, ports would have to follow some set of Haiku policies, defining where any package may (and may not!) put files." while in some way you are going to compromise the beauty of a simple file system.

ports - (the line between these two classifications is too hard to draw) I think you might have looked at this from the wrong angle. Ports are inevitable but if a port follows the Haiku policies and file system then it can be consided as a haiku-native package but if a port needed a unix type file system then it should go in the ports tree and that were I think you could have drawn a classification between the two, by the type of file system the port used. Was just wodering by having a perspective that a classification is too hard to draw it resulted in the above file system.

ports tree - does It gives you the option a few years down the road to get rid of the ports folder and along with it any unix type file system in Haiku? rather then set in stone a file system that is a compremise for ports.

"Make everything as simple as possible, but not simpler."

Must commend you on openly posting your progress - respect!

File system simplicity

Some people here seem to miss the point completely on why the BeOS file system is simple. Simple does not mean structurally flat or with few elements only. The original BeOS file system layout is easy to understand (or call it "simple"), exactly because it is neither flat nor does it contain only few elements. It is easy to understand because it is descriptive. You can follow a deep path and understand exactly where you are and what type of files you are looking at. This is the whole point. The original Windows file system layout (as has been mentioned) was very simple, everything was in System32. That is simple, but not easy to understand at all, since it's a complete mess and you don't know what you are looking at. That most files had a 8.3 characters naming scheme didn't help either.

Now, Haiku cannot be stuck with the BeOS feature set forever. There has to be progress. Package management has many, many advantages. I don't feel like repeating them, especially since (some!) of the advantages have been repeated here in this thread already.

Progress in Haiku means adding new features, but keeping them in the spirit of BeOS. I.e. easy to understand. The proposed new file system layout, even if it is perhaps not set in stone, is exactly such progress. You can understand it all just by looking at the paths. There may be more paths, but that does not mean it's harder to understand, as long as the new paths are descriptive. Which they are.

Some stuff you have to learn of course, but that was the case with BeOS as well. When looking at home/config/add-ons/translators for example, you had to know what a translator is. Translating can mean many things. You had to learn it's about image files. With the proposed layout, you have to learn some stuff again. You have to learn that Haiku does package management, and that packages go into /boot/common/packages. Once you know that, it's very simple, since you can just drop for example a self-contained package into that folder, and it will just work. And delete it and it will be completely gone. I consider that more simple than extracting an application into /boot/apps/, then going to /home/config/be/Applications and making a symlink to the application for it to appear in the Deskbar... or finding out that the package did not include a library it depends on and is now broken since another package extracted a newer version of the library to /boot. Yeah, let's hunt down an older version from "somewhere" and put it into the lib folder of the broken app. Some fun.

Hope this puts some of the fear and doubt into perspective.

Re: File system simplicity

stippi wrote:

Some people here seem to miss the point completely on why the BeOS file system is simple. Simple does not mean structurally flat or with few elements only. The original BeOS file system layout is easy to understand (or call it "simple"), exactly because it is neither flat nor does it contain only few elements. It is easy to understand because it is descriptive. ....

There may be more paths, but that does not mean it's harder to understand, as long as the new paths are descriptive. Which they are..

What does this describe to the user?

/boot/jailed/

/boot/boot/

/boot/optional/ [moved here from /boot/optional, as the contents depend
on the system] ??

/boot/packages/
/boot/pkg-tree/

this is a bunch of stuff shoved under boot that will confuse a new user ( not to mention an experianced one)

Ah I now see the error in my thinking.

The filesystem map was confusing me.

There is no /boot/packages or /boot/pkg-tree, there is /boot/common/packages and /boot/common/pkg-tree.
although these are confusing, at least they are in /boot/common.

It is starting to make some sense, but it is still more confusing than it needs to be. There is no need to remove /boot/apps. and packages and pkg-tree should be merged or have better names.

Re: File system simplicity

bbjimmy wrote:

... The filesystem map was confusing me.

There is no /boot/packages or /boot/pkg-tree, there is /boot/common/packages and /boot/common/pkg-tree.
although these are confusing, at least they are in /boot/common.

It is starting to make some sense, but it is still more confusing than it needs to be. There is no need to remove /boot/apps. and packages and pkg-tree should be merged or have better names.

I replaced the filesystem map with one that is hopefully easier to visualize.

Yes, pkg-tree could certainly have a better name. But for now, as the package manager itself (along with the FindDirectory.h) are the only bits that need to know about it, the name of the folder shouldn't delay progress. Maybe something like 'package-mountpoint', 'package-contents', 'mounted-contents', ..., could be used?

Re: File system simplicity

mmadia wrote:
bbjimmy wrote:

It is starting to make some sense, but it is still more confusing than it needs to be. There is no need to remove /boot/apps. and packages and pkg-tree should be merged or have better names.

I replaced the filesystem map with one that is hopefully easier to visualize.

Yes, pkg-tree could certainly have a better name. But for now, as the package manager itself (along with the FindDirectory.h) are the only bits that need to know about it, the name of the folder shouldn't delay progress. Maybe something like 'package-mountpoint', 'package-contents', 'mounted-contents', ..., could be used?

How about you move it inside 'packages', and name it 'activated' or something like that. Speaking of passive voice, please rename 'jailed' to 'jail': if we are supposed to drop things there why does the folder look like it is managed by the system?

.PackageInfo configuration format

What is the format of .PackageInfo? It doesn't seem to be JSON or YAML. Package information is more often queried from the web, than edited manually, so I can't see much value in custom format. Why reinvent the wheel?

Python goes as far as providing package metadata in RFC-822 format.
http://www.python.org/dev/peps/pep-0345/

Re: Package Management - Present and (hopefully near) Future

I've added a simplier and compact version of folder hierarchy below. Easier to read & follow for me. I left blank lines to separate main folders more.

Your PackageInfo file looks very good. Not sure if you would want to track gcc version in there (gcc2 vs gcc4). Keep in mind mytool will require gcc2 or gcc4 of libssl depending which one it was compiled with.

Jailed Packages
Same idea came to me. You check library for ABI breakage (maybe in PackageInfo file? (bool) ABI-break). If 1 (yes), you check all applications that rely on the older version of that particular library and create symlink in local lib folder to older library version. So, I would say you are on the right track here.

File Hierarchy
1) I find the name pkg-tree kinda confusing I think. I prefer name like package-mount (package-install, package-group), names that Matt suggested are ok too but it seems only one folder is mountable? I believe only pkg-tree/apps will be where packages are mounted to. (ie: pkg-tree/apps/firefox, pkg-tree/apps/webpositive), etc.

Only application programs are mounted and all other folders are not mounted? (ie: bin, add-ons, include, lib) otherwise you would need one or more bin packages, one or more add-on packages, etc.; if only one package file for each folder; it would require constant updating to the latest.

2) I like (POSIX) share name over data.

3) I like docs over documentation

4) "specially marked system packages will appear in /boot/system" Only time this should happen is with Haiku's system updater. Otherwise, packages should not install to system because all changes to system should happen in Haiku repo.

5) I prefer tools continue to stay in develop folder. Makes them easier to find that way.

6) I also prefer applications to be in /boot/apps (quicker to get to) but you put them under common & home pkg-trees because of multiuser support which will come in R2. To get an early start with group & user applications.

Overall looks good to me with couple of minor issues which all relate to hierarchy.

Mounted packages is a different way of doing things. Not sure how I feel about them yet but we will see how things work out.

boot
   apps -> /boot/common/pkg-tree/apps (symlink)
 
   common
      cache
      packages
         history
         jailed
      pkg-tree
         add-ons 
         apps 
         bin 
         boot 
         data 
         documentation 
         include 
         lib 
      settings
         backup
      var
 
   home
      config
         packages
            history
            jailed
         pkg-tree
            +same subfolders from /boot/common/pkg-tree
         settings
            backup
      mail
      people
 
   system
      develop
      optional

Re: Package Management - Present and (hopefully near) Future

I like this hierarchy, seems to be alot more self explainable. That is, you can look at it and make an educated guess what each folder should contain.

Re: Package Management - Present and (hopefully near) Future

tonestone57 wrote:

I've added a simplier and compact version of folder hierarchy below. Easier to read & follow for me. I left blank lines to separate main folders more.

Your PackageInfo file looks very good. Not sure if you would want to track gcc version in there (gcc2 vs gcc4). Keep in mind mytool will require gcc2 or gcc4 of libssl depending which one it was compiled with.

Jailed Packages
Same idea came to me. You check library for ABI breakage (maybe in PackageInfo file? (bool) ABI-break). If 1 (yes), you check all applications that rely on the older version of that particular library and create symlink in local lib folder to older library version. So, I would say you are on the right track here.

File Hierarchy
1) I find the name pkg-tree kinda confusing I think. I prefer name like package-mount (package-install, package-group), names that Matt suggested are ok too but it seems only one folder is mountable? I believe only pkg-tree/apps will be where packages are mounted to. (ie: pkg-tree/apps/firefox, pkg-tree/apps/webpositive), etc.

Only application programs are mounted and all other folders are not mounted? (ie: bin, add-ons, include, lib) otherwise you would need one or more bin packages, one or more add-on packages, etc.; if only one package file for each folder; it would require constant updating to the latest.

2) I like (POSIX) share name over data.

3) I like docs over documentation

4) "specially marked system packages will appear in /boot/system" Only time this should happen is with Haiku's system updater. Otherwise, packages should not install to system because all changes to system should happen in Haiku repo.

5) I prefer tools continue to stay in develop folder. Makes them easier to find that way.

6) I also prefer applications to be in /boot/apps (quicker to get to) but you put them under common & home pkg-trees because of multiuser support which will come in R2. To get an early start with group & user applications.

Overall looks good to me with couple of minor issues which all relate to hierarchy.

Mounted packages is a different way of doing things. Not sure how I feel about them yet but we will see how things work out.

boot
   apps -> /boot/common/pkg-tree/apps (symlink)
 
   common
      cache
      packages
         history
         jailed
      pkg-tree
         add-ons 
         apps 
         bin 
         boot 
         data 
         documentation 
         include 
         lib 
      settings
         backup
      var
 
   home
      config
         packages
            history
            jailed
         pkg-tree
            +same subfolders from /boot/common/pkg-tree
         settings
            backup
      mail
      people
 
   system
      develop
      optional

Ask yourself this, how much of that hierarchy can you remove and place on the packager"how much is needed at all" ? Also how much of that hierarchy is needed in a general sense.

My basic design philosphy "for anything" is always to remove stuff until it stops working. then take one step back. streamline whats left.

Less is more. It needs to be just complex enough to get the job done. Less bugs that way to.

Re: Package Management - Present and (hopefully near) Future

tonestone57 wrote:

I believe only pkg-tree/apps will be where packages are mounted to. (ie: pkg-tree/apps/firefox, pkg-tree/apps/webpositive), etc.

Only application programs are mounted and all other folders are not mounted? (ie: bin, add-ons, include, lib) otherwise you would need one or more bin packages, one or more add-on packages, etc.; if only one package file for each folder; it would require constant updating to the latest.

The only distinction between pure apps and packages of other kinds (like libraries) is that for pure apps, the pathnames within the package all begin with "apps/appname/".

Generally speaking the packages' contents are presented as stacked all on top of each other, as if unzipped in the same spot. Contents are merged (virtually). Folders that overlap are simply shared. Files that overlap - a simple form of package conflict - is dealt with or prevented by the package manager.

Apps like Mozilla and Transmission can (optionally) both contain "bin/..." and "documentation/man/..." (alongside "apps/mozilla/...") and it just works. There's no need for a "bin" package or a "documentation" package. Packages coexist.

I think the package-fs employs a single mountpoint, sourcing the collection of packages from a given folder. Not an individual mount per package.

Re: Package Management - Present and (hopefully near) Future

Quote:

6) I also prefer applications to be in /boot/apps (quicker to get to) but you put them under common & home pkg-trees because of multiuser support which will come in R2. To get an early start with group & user applications.

I have given this more thought and still think putting applications in /boot/apps makes things way easier for me to find them and only deal with one folder (more focused).

This really depends on multiuser support. I believe it will only be two levels:
1) system wide applications (/boot/apps)
2) user only applications (/boot/home/user-name/apps)

So, we could put programs in /boot/apps to keep users out of messy /boot/common/pkg-tree. Also makes it quicker to find the applications using terminal. I believe better for users with /boot/apps.

Re: Package Management - Present and (hopefully near) Future

tonestone57 wrote:

we could put programs in /boot/apps to keep users out of messy /boot/common/pkg-tree.

The blog post proposal's symlink
/boot/apps -> /boot/common/pkg-tree/apps
accomplishes exactly what you describe.

Which is a good thing, since AFAIK (please correct me if I'm wrong) a single filesystem instance can only have a single mount point; e.g. /boot/common/pkg-tree and not both that *and* /boot/apps.

The separation of system-wide and user-installed packages is probably done by having -two- separate packagefs instances, each with its own mountpoint, and sourcing its own collection of packages -- rather than having a single packagefs instance sourcing two sets of packages and publishing their contents in multiple locations.

Re: Package Management - Present and (hopefully near) Future

It's true that there will be separate instances of package-fs for the system-wide packages and for the user-specific packages. Currently, it's planned to have three of them. One watching /boot/home/config/packages and populating /boot/home/config/pkg-tree, and two for system-wide packages: one watching /boot/common/packages and populating /boot/common/pkg-tree with all *non-system* packages and a second instance watching /boot/common/packages for system packages and populating /boot/system with these.

/boot/software and ~/software

I think the cumbersome "pkg-tree" folder name could be sidestepped by having the contents of system-wide packages published at /boot/software and user-specific ones at ~/software. (Or if one is crazy enough to consider it alls "apps": /boot/apps and ~/apps.)

(The set of packages would still reside in the suggested folders /boot/common/packages and ~/config/packages.)

I think this would appear more simple and be easier to understand. Calling it "software" does not exclude e.g. software documentation, like man pages. Even if some content, like event sound sets, wallpaper collections, etc, might not fit a strict definition of software, it fits well enough, IMO.

Re: /boot/software and ~/software

can these situations be avoided ?

http://www.linux-archive.org/ubuntu-user/480208-i-made-big-mistake-depen...

is there a procedural process to prevent this issue yet ? looks like a Id10T error.

"re: dependency hell" ?

Did you mean to reply to me? I'm not much of a Linux user, but I would guess he manually installed packages from some alien distro or from some previous or following release of the same distro.

There is no way to fully prevent a user from willfully, manually screwing up his set of installed packages and their interdependencies by mixing in packages that don't fit the rest. (If you want another pegged wheels for you gear box, order one that fits.) People would do well to get all packages from a trusted, quality repository.

There's probably a lot that can be done to ensure the quality of packages, before they're published, but packages with incomplete metadata are likely to slip through at times, so I think repositories need to publish metadata updates for such packages, to help package managers out of dead ends.

Post-install (but pre-use) a linker analysis could be done (of executables and libraries they depend on) to catch failure early, roll back (or splice an app package with a specific library version), and report this to the repository, for further testing and possible metadata update.

In an ideal world, package quality assurance is done server-side at the repository, which has automated builds (for non-closed software) and automated testing, resulting in a well-tested collection of packages, e.g. once a week, and since the cost to install/deinstall packages is little with the package-fs, a user with a small set of packages, say a few apps, could simply trash the old set (manually or via the package manager) and get the entire set fresh from the repo. A clean slate. As long as the new software is backwards-compatible with written settings files it should work okay.

Re: "re: dependency hell" ?

kirilla wrote:

Did you mean to reply to me? I'm not much of a Linux user, but I would guess he manually installed packages from some alien distro or from some previous or following release of the same distro.

There is no way to fully prevent a user from willfully, manually screwing up his set of installed packages and their interdependencies by mixing in packages that don't fit the rest. (If you want another pegged wheels for you gear box, order one that fits.) People would do well to get all packages from a trusted, quality repository.

There's probably a lot that can be done to ensure the quality of packages, before they're published, but packages with incomplete metadata are likely to slip through at times, so I think repositories need to publish metadata updates for such packages, to help package managers out of dead ends.

Post-install (but pre-use) a linker analysis could be done (of executables and libraries they depend on) to catch failure early, roll back (or splice an app package with a specific library version), and report this to the repository, for further testing and possible metadata update.

In an ideal world, package quality assurance is done server-side at the repository, which has automated builds (for non-closed software) and automated testing, resulting in a well-tested collection of packages, e.g. once a week, and since the cost to install/deinstall packages is little with the package-fs, a user with a small set of packages, say a few apps, could simply trash the old set (manually or via the package manager) and get the entire set fresh from the repo. A clean slate. As long as the new software is backwards-compatible with written settings files it should work okay.

it wasn't directed specifically at you. It was a broader statement about the need for a quality assurance design needing to be implemented. In all honesty I think someone needs to be able to put "haiku " seal of approval on stuff and haiku should charge " nominal fee" for doing so.

It will help ensure the package works, is correctly formated, doesn't break system files etc etc etc.

I am far less concerned with getting files on the machine then I am with getting the right files, in the right place, and having a good solid basis for knowing they will function correctly. I think another tennant should be that everything must be precompiled and include any needed librarys.

Obviously on a framework like QT the situation is different. It begs one to question if QT and a few other common frameworks should be included at the base level with a haiku release to simply cut down on the cruft. The current QT 4.7 and 4.8 wiegh in around 20mb each. its not heavy enough to leave off and QT opens a nice window for alot of application support quickly.

The issue is that it doesn't encourage the use of the native API.

I also dislike th eidea of catering to a unix/unixlike filesystem comming to the OS. if your going to port a application fix the directory structure to use the native system. Don't break the native system to fix the application.

Re: "re: dependency hell" ?

thatguy wrote:

It was a broader statement about the need for a quality assurance design needing to be implemented. In all honesty I think someone needs to be able to put "haiku " seal of approval on stuff and haiku should charge " nominal fee" for doing so.

Presently Haiku Ports does most of the porting and building, so we'd pretty much be paying ourselves. I think it would be a mistake trying to get money from 3rd parties. Better to fund a QA service, sort of like Haiku Ports.

thatguy wrote:

I also dislike the idea of catering to a unix/unixlike filesystem comming to the OS. if your going to port a application fix the directory structure to use the native system. Don't break the native system to fix the application.

We're not breaking the filesystem hierachy. The amended filesystem structure, where the separate pkg-tree for pure "ports" is removed, does not promote more of a unixlike filesystem than Haiku already does. The unixlike folders (e.g. "bin") in the pkg-tree are already there in ~/home/config, in /boot/common and in /boot/system. The suggested pkg-tree simply follows this theme.

(Open a Terminal and type "ls -l /" in Haiku and in BeOS, and see the familiar unix top folders. The major difference between BeOS and Haiku is that Haiku adds /boot/common in preparation for multiuser.)

Re: "re: dependency hell" ?

kirilla wrote:

Presently Haiku Ports does most of the porting and building, so we'd pretty much be paying ourselves. I think it would be a mistake trying to get money from 3rd parties. Better to fund a QA service, sort of like Haiku Ports.

Nominal fee, that means like $20. If the app developer feels they have a worthy commercial application that well developed and properly inplemented. $20 is nothing. you could do it for free. That would obviously be your choice.

If you had a APP store where you took a percentage of the sale you could skip the upfront charge. Haiku must find a way to be self funding on a much greater scale then it has thus far. Even if its just niche operating system it needs viable income stream for development and wouldn't it be nice to have ingo/stippi/axel being paid to work fulltime?

thatguy wrote:

We're not breaking the filesystem hierachy. The amended filesystem structure, where the separate pkg-tree for pure "ports" is removed, does not promote more of a unixlike filesystem than Haiku already does. The unixlike folders (e.g. "bin") in the pkg-tree are already there in ~/home/config, in /boot/common and in /boot/system. The suggested pkg-tree simply follows this theme.

(Open a Terminal and type "ls -l /" in Haiku and in BeOS, and see the familiar unix top folders. The major difference between BeOS and Haiku is that Haiku adds /boot/common in preparation for multiuser.) I

I think multiuser is a huge mistake but thats another debate.

anyways keep it simple. I also like my appps being segregated into their own folders.

IE

boot/apps/sausage/lib

and then

boot/sharedfiles libs enviroments etc.

not

boot/app/mess of everything

Re: "re: dependency hell" ?

thatguy wrote:

Nominal fee // APP store // viable income stream

We hardly have any commercial apps. Inventing fees is very much premature, and beyond the scope of this blog post IMO.

thatguy wrote:

I also like my apps being segregated into their own folders.
boot/apps/sausage/lib
not boot/app/mess of everything

I think your fears are unfounded.

Here's a mostly self-contained app, relying on a single library.

package ArmyKnife
./apps/armyknife/ArmyKnife
./apps/armyknife/docs/Copyright.txt
./apps/armyknife/docs/ArmyKnife.html
./addons/Tracker/ArmyKnife-K

package TagLib
./lib/libtag.so
./headers/libtag/... .h (C/C++ headers)

Do you find that messy?

This structure isn't any different from BeOS or Haiku without package management. The few other folders introduced by package management (for rollback, history etc) are tucked away neatly in /boot/common and ~/config/. No big trade-off, IMO, for desperately needed functionality.

Re: "re: dependency hell" ?

kirilla wrote:
thatguy wrote:

Nominal fee // APP store // viable income stream

We hardly have any commercial apps. Inventing fees is very much premature, and beyond the scope of this blog post IMO.

thatguy wrote:

I also like my apps being segregated into their own folders.
boot/apps/sausage/lib
not boot/app/mess of everything

I think your fears are unfounded.

Here's a mostly self-contained app, relying on a single library.

package ArmyKnife
./apps/armyknife/ArmyKnife
./apps/armyknife/docs/Copyright.txt
./apps/armyknife/docs/ArmyKnife.html
./addons/Tracker/ArmyKnife-K

package TagLib
./lib/libtag.so
./headers/libtag/... .h (C/C++ headers)

Do you find that messy?

This structure isn't any different from BeOS or Haiku without package management. The few other folders introduced by package management (for rollback, history etc) are tucked away neatly in /boot/common and ~/config/. No big trade-off, IMO, for desperately needed functionality.

I don't find that problematic, however wouldn't it make sense to just fatten the ISO a bit to include all the needed libs currently in use ? Maybe offer the iso in 2 varietys fat and skinny ?

I'd be curios to track which one is more popular anyways.

Aside from that, the layout you show is the current layout which just unzipz to boot and works.

So why did a package manager need to be designed if the solution was as simple as a self extracting zip files that extracts to boot/apps ??

if the result is the same. I think the onus should be placed on the application developer to include all need libs etc. Now if the devs just wanted to have a formalized utility that check for packaged libs vs installed or current libs, wouldn't that have been just as easy ?

developing commercial apps, income streams and deployment tools should be top prioritys as this Os gets closer to finished and from my POV its not that far off.

dependencies, user -> common

I think the package manager needs to safe-guard against user-installed packages satisfying dependencies of system-wide packages, since that easily breaks in a multiuser scenario.

Re: dependencies, user -> common

Rest assured, it will guard against that.

As with packages, there are two kinds of repositories (system-wide and user-specific) and no package from a user-specific repo will ever satisfy a dependency from a system-wide repository's package. Neither will a package that's been activated in /boot/home/config/packages (no matter if manually or by pkgman).

Re: dependencies, user -> common

kirilla wrote:

I think the package manager needs to safe-guard against user-installed packages satisfying dependencies of system-wide packages, since that easily breaks in a multiuser scenario.

I like the fact the haiku isn't multi user. I have always found that to be a pain in the ass for my home machines and actually in alot of commercial settings. doesn't mean you can't have computer security, it just means its alot easier.

For things like point of sale, the software doing the transacting can handle users. the os doesn't need to. What would be nice is some way to lock down the system in a point of sale situation to protect crucial data but again, much of this can be done in the application itself.

Multiuser is a roundabout solution to a application design issue. Haiku wouldn't make a good server OS where multiuser would make sense. Linux is far better in that role.

there is no reason that at some point there couldn't be a Haiku client and linux server arrangement. Really leveraging the strengths of each for a really over all good package.

Re: dependencies, user -> common

thatguy wrote:

I like the fact the haiku isn't multi user. I have always found that to be a pain in the ass for my home machines and actually in alot of commercial settings. doesn't mean you can't have computer security, it just means its alot easier.

Hopefully, multi user in Haiku will be friendlier than what we're used to from other systems. On the other hand, I do see your point about simplicity. An interesting turn of events since the BeOS days is widespread use of virtualization. One could imagine running multiple single user systems in virtual machines instead of implementing multi user support.

thatguy wrote:

there is no reason that at some point there couldn't be a Haiku client and linux server arrangement. Really leveraging the strengths of each for a really over all good package.

Lots of interesting solutions could spring from this line of thought. Imagine a Haiku install with only the base system, and no user files. Then to "log in" and get access to user content and programs, you mount a network disk from a Linux server.

This could be combined with the idea about virtualization to provide terminal service capabilities. The Linux server could spawn virtual Haiku machines on demand, all of which mount the same system disk read-only. All user content would be accessed from the underlying Linux system, which acts as a file server.

Re: dependencies, user -> common

tbe wrote:

Hopefully, multi user in Haiku will be friendlier than what we're used to from other systems. On the other hand, I do see your point about simplicity. An interesting turn of events since the BeOS days is widespread use of virtualization. One could imagine running multiple single user systems in virtual machines instead of implementing multi user support.

Multiuser is alot of the problem in computer security. It remove responsobility for application security back to the OS developer instead of adressing the problem where it truly begins. Usually the browser. A secure computer should basically ignore any incoming request for back door modes. They simply shouldn't be there. Handling self installing virus's is also fairly easy. Using file permissions you can pretty much prevent the issue from occuring.

Example: remove BASH and Terminal calls from anywhere but userland in a specific way. the terminal can only be summoned by mouse or keyboard input from the desktop or application folder etc etc etc and require a password to enable Terminal. Even if someone did find a way to instintate terminal it still couldn't use terminal becuase terminal is protect. same thing goes for writing files to certain areas of the OS. those could be password protected as well.

tbe wrote:

Lots of interesting solutions could spring from this line of thought. Imagine a Haiku install with only the base system, and no user files. Then to "log in" and get access to user content and programs, you mount a network disk from a Linux server.

This could be combined with the idea about virtualization to provide terminal service capabilities. The Linux server could spawn virtual Haiku machines on demand, all of which mount the same system disk read-only. All user content would be accessed from the underlying Linux system, which acts as a file server.

I am thinking differently here. I despise the cloud computing concept it goes back to the mainframe. I was reffering soley to file and data storage and webhosting etc.

Haiku would be the super user in such a scenario the Admin if you will. It would command the linux based server from the client machine. but the two would not interoprate directly therby increasing security.

plus using binary incompatable partners reduces the risk of cross infection if something did get in.

Re: Package Management - Present and (hopefully near) Future

Each time i read about the work that's been done to add this useless bloat to Haiku, i cry a little inside.

Re: Package Management - Present and (hopefully near) Future

Crup wrote:

Each time i read about the work that's been done to add this useless bloat to Haiku, i cry a little inside.

at least its not in the kernel or window manager and should be easily defeated or removed if the user was so inspired.

Re: Package Management - Present and (hopefully near) Future

I feel the same. I see that part of what drew me to Haiku is now getting lost just to satisfy Linux users who can't deal with having two copies of a library no matter how small it is. This is all ridiculous, and I hope someone will fork Haiku if this package management idea becomes a reality.

Re: Package Management - Present and (hopefully near) Future

I know exactly what you mean!

Surely, the following approach could be taken:

1. The core OS is a black box. Period. Allow the OS to update itself. Think: Windows Update. This includes applications that are bundled with the OS (/boot/apps/).

2. Each application the user adds is a black box. Period. Allow each application to update itself. Think: Portable applications under Windows (~/apps/).

Each application has to adhere to a known menu structure. Let the system build a database of installed applications by extracting meta-data from the applications folder. Design the system so that the applications only have permission to perform their function within their own respective folders. They simply have no permission to go elsewhere.

3. Create an Appstore, so that there is a centralised location for these self-contained black box applications to be found and managed.

In this way:
1. The OS would remain pristine. The equivalent of Windows slowdown with time would be irrelevant.
2. The equivalent of "DLL hell" would be irrelevant.
3. Applications could be backed up and restored by simply copying the folder in which the applications live. That is something that we Windows users have been complaining about since before Windows 95, and it has never been addressed.
4. You can have multiple applications all using different versions of the same library, and none would clash with each other.
5. Deleting the application's folder would be all that was required to completely rid your system of the application.
6. Security issues regarding outdated libraries would be irrelevant, as the folder is not allowed to access anything outside of itself.
7. The user now feels in control of the system and not the other way around. When I uninstall an application under Windows, I have to go to some extraordinary steps to make sure the system is in the same state as it was before the installation. With the equivalent of the idea of a portable application, that is a thing of the past.
8. The OS hierarchy could be streamlined further and simplified.

The downside:
1. Having multiple versions of the same library in multiple folders take up extra space.
2. I don't see any further downsides.

Surely, the upside of this approach outweighs the downside?

Re: Package Management - Present and (hopefully near) Future

otello wrote:

Design the system so that the applications only have permission to perform their function within their own respective folders. They simply have no permission to go elsewhere.

It may appear simple but I think something called "capabilities" would have to be implemented for such a design to be feasible, and that you underestimate the scale of such a redesign, putting Haiku back on the drawing board and delaying it by years. (And likely making it unable to run apps for BeOS.)

Capabilibites are found in research and niche systems. And in Symbian, apparently:
http://en.wikipedia.org/wiki/Capability-based_security#Research_and_comm...

otello wrote:

6. Security issues regarding outdated libraries would be irrelevant, as the folder is not allowed to access anything outside of itself.

Apps sealed being off from each other (not just in memory but also at the filesystem level) does not solve issues of remote execution, priviledge escalation, etc, as apps still need to interface the operating system, each other, and user data. Plenty of attack vectors.

Security-wise there's not an huge difference IMO, to have a single, shared foo library version 1.2.3 (with an exploitable vulnerability), or multiple copies of the same, in self-contained, sealed-off app folders. Either the potential exploit exists locally or it does not. But in the single-copy case a security update can likely be applied quicker, and the vulnerability be gone from the system.

I, too, like MacOSX app bundles, and find them very nice, from a casual user point of view. But from what I've seen of MacOSX (in versions before Tiger, at least) that system does not lend itself to installing lots of *non-app* software, developer-oriented file explosions like perl or python, in a controlled manner, which is probably why e.g. Fink was created. (Correct me if I'm wrong.)

Re: Package Management - Present and (hopefully near) Future

kirilla wrote:

It may appear simple but I think something called "capabilities" would have to be implemented for such a design to be feasible, and that you underestimate the scale of such a redesign, putting Haiku back on the drawing board and delaying it by years. (And likely making it unable to run apps for BeOS.)

Capabilibites are found in research and niche systems. And in Symbian, apparently:
http://en.wikipedia.org/wiki/Capability-based_security#Research_and_commercial_systems

The orthogonally persistent OS concept sounds similar to what I had in mind. Thank you for pointing me to that resource. I do understand your point. It is better to have something, than nothing.

kirilla wrote:

Apps sealed being off from each other (not just in memory but also at the filesystem level) does not solve issues of remote execution, priviledge escalation, etc, as apps still need to interface the operating system, each other, and user data. Plenty of attack vectors.

There has to be a way to protect the system from old software that does not get updated, but has vulnerabilities. I have had to use old outdated software in a few instances, because it became unmaintained but the function was still required.

kirilla wrote:

Security-wise there's not an huge difference IMO, to have a single, shared foo library version 1.2.3 (with an exploitable vulnerability), or multiple copies of the same, in self-contained, sealed-off app folders. Either the potential exploit exists locally or it does not. But in the single-copy case a security update can likely be applied quicker, and the vulnerability be gone from the system.

Isn't that the same as saying, let's rather take the gun out of the safe and place it in the living room. If the library is maintained and is patched and the program continues to work, then I agree that it would be the equivalent of removing the gun from the premises. Unfortunately, it is not guaranteed that the software would continue to work once the library had been patched, which would require the old version to be reinstated. If the library is no longer maintained, then surely, putting the gun back in the safe is the safer bet?

kirilla wrote:

I, too, like MacOSX app bundles, and find them very nice, from a casual user point of view. But from what I've seen of MacOSX (in versions before Tiger, at least) that system does not lend itself to installing lots of *non-app* software, developer-oriented file explosions like perl or python, in a controlled manner, which is probably why e.g. Fink was created. (Correct me if I'm wrong.)

My perspective is that of a user, so normally portable applications have a small number of files. Your point is valid, regarding adding something like perl to the system. How does Haiku propose to solve that problem?

Re: Package Management - Present and (hopefully near) Future

otello wrote:

My perspective is that of a user, so normally portable applications have a small number of files. Your point is valid, regarding adding something like perl to the system. How does Haiku propose to solve that problem?

We're going to try using the package-filesystem for all third party software, including ports like perl, and have the package manager manage dependencies.

The work is well under way:
http://cia.vc/stats/author/zooey

http://dev.haiku-os.org/browser/haiku/trunk/src/kits/package

http://dev.haiku-os.org/browser/haiku/trunk/src/bin/pkgman
http://dev.haiku-os.org/browser/haiku/trunk/src/bin/package
http://dev.haiku-os.org/browser/haiku/trunk/src/bin/package_repo

The initial packagefs implementation was created by Ingo 15 months ago.
http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/kernel/file_syst...

Re: Package Management - Present and (hopefully near) Future

me too.

this project needs a benevolent dictator to maintain a unified and BeOS-ideal plan. package management is indicative of bad underlying architectural design. i feel the same about shared libraries. there should be OS libs for the API and nothing else. Haiku is looking more and more like just another *nix implementation, based on what i've read over the last two years. it's no longer relevant to me. i've been using Mac OS X more and more. i'm preferring it in pretty much most ways except for the fact that it doesn't perform like BeOS used to (as in, there are times when the system isn't responsive to the user where BeOS never had such problems). structurally, what it presents to the user (advanced or newbie) is far more sensible on Mac OS X than on Haiku. the reliance on shortcuts and libraries for basic function... the idea of needing a package manager... it's just the wrong way to go.

and none of these open source developers get it. they grew up as developer geeks, learning from the old ways of unix designs. Mac OS X is a unix, but, more and more, that underlying architecture is invisible and doesn't affect standard user activities such as installing a new application.

why am i even bothering... i should just walk away and forget about all this once and for all.

Re: Package Management - Present and (hopefully near) Future

Yes but forking is another Linux virus, too :-)

I fear this the wrong path, too but forking is never a solution first we have 2 Haiku (1 hybridized with Linux as it needs a Package Manager to install everything) and another done in the RIGHT way (using bundle) then someone else want to substitute AppServer with an ugly X server then someone other want to use an other packager manager and so on.. now we have 100 Haiku(s) all incompatibles each other as it is in the Linux world: Haiku will not be a Desktop OS but a Toys OS nothing more.

We have to continue to support the ONLY ONE Haiku hoping the Package Manager not destroy it completely, maybe either if it appears a lot complicated can work well; we most have faith :-)

Re: Package Management - Present and (hopefully near) Future

fano wrote:

Yes but forking is another Linux virus, too :-)

I fear this the wrong path, too but forking is never a solution first we have 2 Haiku (1 hybridized with Linux as it needs a Package Manager to install everything) and another done in the RIGHT way (using bundle) then someone else want to substitute AppServer with an ugly X server then someone other want to use an other packager manager and so on.. now we have 100 Haiku(s) all incompatibles each other as it is in the Linux world: Haiku will not be a Desktop OS but a Toys OS nothing more.

We have to continue to support the ONLY ONE Haiku hoping the Package Manager not destroy it completely, maybe either if it appears a lot complicated can work well; we most have faith :-)

Linux is a virus

Re: Package Management - Present and (hopefully near) Future

fano wrote:

Yes but forking is another Linux virus, too :-)

I fear this the wrong path, too but forking is never a solution first we have 2 Haiku (1 hybridized with Linux as it needs a Package Manager to install everything) and another done in the RIGHT way (using bundle) then someone else want to substitute AppServer with an ugly X server then someone other want to use an other packager manager and so on.. now we have 100 Haiku(s) all incompatibles each other as it is in the Linux world: Haiku will not be a Desktop OS but a Toys OS nothing more.

We have to continue to support the ONLY ONE Haiku hoping the Package Manager not destroy it completely, maybe either if it appears a lot complicated can work well; we most have faith :-)

Linux is a virus

this guys commentary is often hilarious.

http://linuxhaters.blogspot.com/