How about BSDlike ports system on Illumos?

Added by M?rcis Lielturks over 3 years ago

Hi!

Want to do some brainstorming here.

I don't know details of how 3rd party software is integrated (and kept up-to-date) on Illumos, but what do you think about creating port system (or integrating NetBSDs "pkgsrc") on Illumos? I have used "pkgsrc" on Solaris 10 and was satisfied with results. I don't picture how hard would it be to create such system or integrate it from NetBSD, but it could expand amount of available software and introduce more decent versions of it.

Depending on feedback, I could try to set up pkg-src on my snv_134 for a start and see how that goes.

Pkgsrc supported OS list
http://www.netbsd.org/docs/software/packages.html#platforms
Some resources for setting up pkgsrc on Solaris 10
http://wtf.hijacked.us/wiki/index.php/Pkgsrc_on_solaris
http://asyd.net/home/docs/solaris/pkgsrc


Replies (29)

RE: How about BSDlike ports system on Illumos? - Added by Piotr Jasiukajtis over 3 years ago

Christopher J. Ruwe wrote:

I am Gentoo user since about six years and I do not think I am an analphabet regarding to unixes. However, bootstrapping Gentoo prefix on a 64bit Solaris feels like a "two steps ahead, one step back"-ballet. I have started on Friday evening and still I do not have a working portage on my machine. If this is not some peculiarity of my system, but a general state of affairs, then Gentoo portage is not the best choice as a package manager.

What about pkgcore then?: http://osunix.org/docs/DOC-1055

RE: How about BSDlike ports system on Illumos? - Added by Christopher J. Ruwe over 3 years ago

Looks interesting, thank you for that idea. It looks promising, I will give it a try, perhaps next weekend.

Cheers, Christopher

RE: How about BSDlike ports system on Illumos? - Added by M?rcis Lielturks over 3 years ago

Hi!

I also have gotten pkgsrc working on on OpenSolaris snv_134. I used gcc for bootstrap and it went quite well. Haven't had much spare time lately so I haven't achieved my first objective - get Samba compiled and working. But so far it looks nice. Haven't tried Portage jet, but from what I have read it appears that setup is more complicated than for pkgsrc.

RE: How about BSDlike ports system on Illumos? - Added by Richard Yao about 2 years ago

As a Gentoo contributor that is in the process of becoming a Gentoo developer, I would like to respond to some of the things that have been said here.

foo bar wrote:

It should already be possible to use Portage on Illumos via Gentoo Prefix. The project page mentions prefix working on Solaris. http://www.gentoo.org/proj/en/gentoo-alt/prefix/

Gentoo/Illumos would rock :)

As far as I know, the Gentoo Prefix lead developer uses Solaris exclusively. I was able to install Gentoo Prefix on Open Indiana 151. I do not see why it would not work on Illumos.

Mads Worsøe Duun wrote:

Projects like pkgcore (http://www.pkgcore.org) was partly made to fix some of the mess of portage. OSUNIX was a project that wanted to use pkgcore on Opensolais, but is stalled now.

Actually, pkgcore focused on making a faster portage, but portage development had enough momentum that it never quite caught up in functionality. The core functionality of pkgcore is written in C.

Mads Worsøe Duun wrote:

I know about the Gentoo prefix (Alt project), but I really prefer Pkgsrc for different reasons:

1. Had much more success compiling ports with Pkgsrc 2. Written i C, dose not depend on third party software like python and bash 3. A license that fit Illumos better (BSD) (portage is GPL-2) 4. Simplicity (portage is complex) 5. Well written code (portage is a mess)

1. Gentoo is in the process of merging the Gentoo Prefix tree into the main Gentoo tree, which should address this.
2. Pkgsrc uses shell scripts. There is some interest among Gentoo developers in removing bashisms from ebuilds, but so far, there is no strong reason to pursue it. Illumos could change this. As for the python dependency, there is also some interest in reimplementing portage in C, but this has not happened yet due to lack of man power and general need. A reimplementation would be useful to the Gentoo Prefix project, which goes through great pains to maintain python across platforms.
3. Since portage is written in python, I am not sure how its license requirements differ from those of a BSD license. It is not like you can choose violate the license by distributing binaries. Also, nothing stops Illumos from writing your own portage implementation and licensing it as you pleases. If you write it in C, you might even receive help from the Gentoo Prefix project, which suffers greatly from the need to be even more cross-platform compatible than Python upstream. Having a reimplementation in C would eliminate the necessity of patching python to work on new platforms.
4. Ports has its own complexity problems. The FreeBSD developers have rewritten it from scratch as a consequence, largely implementing ideas already in portage: http://www.youtube.com/watch?v=JwDXoT767hM
5. As far as I know, portage is very well maintained and the code is rather clean. Please elaborate on this.

Mads Worsøe Duun wrote:

If we were gonna use portage, I hope it would be as prefix only. I like the way the BSD's separates the core system from the third party software.

Portage also makes a similar distinction. @system is used for core system software while @world contains everything else. Gentoo/FreeBSD has FreeBSD components in @system.

devsk devsk wrote:

With Nexenta having GNU userland, integrating portage in the system is easier than ever. No need to duplicate stuff in prefix, which I currently use.

A GNU userland is not a requirement for portage. Gentoo/FreeBSD has relatively few GNU components and portage works without a problem.

foo bar wrote:

The vast majority of the maintenance labor goes in to maintaining the packages, not the package manager itself. It takes an army of people to maintain the Gentoo ebuilds, and every new spec requires another dedicated army of developers to maintain the package library. The work involved is far greater than with the binary package genre. This obviously isn't sustainable. Standardization of a source-based package manager format is absolutely critical. We really need to be working towards sharing as much between source-based operating systems as possible rather than re-inventing the wheel.

When a new version of a software project is released, supporting it is possibly by simply renaming the file and updating a Manifest with an automated tool (i.e. `ebuild /path/to/ebuild update`). With the new thin-manifest support in portage, that last part is not strictly necessary. Supporting a new architecture means changing a single line in the ebuild file, which is known as keywording it.

Ebuilds are basically write once, work everywhere packages. You must write them properly, but that is true for anything. Gentoo protects users from maintainer errors by maintaining two trees, stable and testing. In order for an ebuild to enter the stable tree, it must first be in the testing tree for 30 days and have no outstanding bugs. With that said, Illumos has its own release process, which should vet any problems before code is released to users.

Lastly, Google is using portage to build Chome OS. They selected it with the statement that it made things easier for them.

Jonathan Edwards wrote:

+1 on the ebuild front .. all it takes is a couple missteps in a few critical packages (eg: emerge glibc) and you can be majorly SOL

The last I checked, any UNIX system would be disabled if you made a mistake installing glibc. With that said, Illumos inherits ZFS from Solaris, so it is theoretically possible to pre-stage updates, which solves this problem. I have been working on implementing ZFS support in Gentoo. I plan to talk to the portage developers about modifying portage to support update prestaging through ZFS snapshots on systems that use ZFS.

Jonathan Edwards wrote:

oddly, one of the big complaints is the ability to find reliable binary emerge'd targets .. I say - keep it simple - most of the work has already been done in the major linux distros (yum, apt) and the problems and solutions are generally well understood .. why re-invent the wheel again? Do you really go faster and have less problems when you make whistling hubcaps, spoilers, and glow in the dark chrome - i thought it was more about maintaining the correct [tire] pressure .. :)

This is not a major complaint in Gentoo, although I know that the Sabayon Linux developers do binary packages on top of emerge. I understand it works well until you start fiddling with USE flags, although making changes to a binary package that are incompatible with other ones installed on the system is a problem for any operating system.

Christopher J. Ruwe wrote:

I am Gentoo user since about six years and I do not think I am an analphabet regarding to unixes. However, bootstrapping Gentoo prefix on a 64bit Solaris feels like a "two steps ahead, one step back"-ballet. I have started on Friday evening and still I do not have a working portage on my machine. If this is not some peculiarity of my system, but a general state of affairs, then Gentoo portage is not the best choice as a package manager.

That would be because Gentoo Prefix has only two active developers. The others are infrequent contributors. They maintain a separate prefix portage tree, which contains 9483 packages (versus 15554 in the main tree and about 7000 in pkgsrc). The prefix tree is currently being merged into the main tree, with developers of the main tree helping to make their ebuilds "prefix ready", which should address many of the problems. Currently, there are about 300 ebuilds that have yet to be merged into the main tree. With a little luck, this will happen this year, which will go a long way toward addressing this issue.

Also, I am beginning to contribute to the Gentoo Prefix project, so for what its worth, the active developer count could soon increase by 50%. Interest in the Gentoo Prefix project is also rising, so I expect it to receive much more attention in the future.

Piotr Jasiukajtis wrote:

Christopher J. Ruwe wrote:

I am Gentoo user since about six years and I do not think I am an analphabet regarding to unixes. However, bootstrapping Gentoo prefix on a 64bit Solaris feels like a "two steps ahead, one step back"-ballet. I have started on Friday evening and still I do not have a working portage on my machine. If this is not some peculiarity of my system, but a general state of affairs, then Gentoo portage is not the best choice as a package manager.

What about pkgcore then?: http://osunix.org/docs/DOC-1055

Gentoo Prefix maintains a fork of portage that enables it to work as a userland package manager. The changes are gradually begin merged into portage upstream, but unfortunately, pkgcore would need similar changes to act as a package manager for Gentoo Prefix. I do not know whether or not these changes have been made.

M?rcis Lielturks wrote:

Hi!

I also have gotten pkgsrc working on on OpenSolaris snv_134. I used gcc for bootstrap and it went quite well. Haven't had much spare time lately so I haven't achieved my first objective - get Samba compiled and working. But so far it looks nice. Haven't tried Portage jet, but from what I have read it appears that setup is more complicated than for pkgsrc.

I tried installing pkgsrc on Mac OS X and I found installing it to be harder. I suspect that it would have been easier had I had root privileges on the machine on which I was installing it.

With that said, I think your issue with the installation procedure is that you need to do the bootstrap process manually. I wrote a script that I am working on that can theoretically automate the installation of Gentoo Prefix. It is available online at the following address:

http://www.cs.stonybrook.edu/~ryao/prefix-install.sh

As always, read the source before executing strange scripts on your system. As a standard disclaimer that is also included in the license header, I am not responsible if this does bad things to your system.

« Previous 1 2 (26-29/29)