[minix3] Alternative Package Manager?

[Thomas Cort]

Greetings,

My name is Thomas, and lately I've been playing around with minix.
I've been using packman to install software and find it to be somewhat
limited. I have a lot of experience with the portage package manager
( http://www.gentoo.org/proj/en/portage/ ) used by Gentoo ( http://gentoo.org/
), and would like to lend my expertise. portage is a python program
that operates on ebuilds (bash shell scripts) to build and install
software packages on Linux (13 architectures!), AIX, FreeBSD, HP/UX,
Interix, Irix, Mac OS, Mint, OpenBSD, and Solaris. It has many
advanced features like sandboxing, protection against overwriting
already installed files, conditional compilation (i.e. enabling/
disabling of features), customizable compilation flags, integration
with distcc/ccache is possible, and much more. portage has a vast
repository with thousands of packages ( http://packages.gentoo.org/ ).
minix has the software needed to run portage (python, bash, rsync,
wget, coreutils, GNU toolchain, etc). I'm considering doing a project
that would involve creating ebuilds (scripts portage can use to create
packages) for the minix specific software (kernel, servers, drivers,
headers, man pages, etc) and updating ebuilds that already exist
(packages like bash, gcc, etc) to work on minix (i.e. apply minix
specific patches, etc). In essence I would replace packman with
portage and the packman packages with ebuilds and portage packages. It
isn't a trivial project, so before I begin I have a few questions for
the minix community to gauge the level of interest and enthusiasm.

1) Would the minix community find this to be a useful project?

2) Would you try it out when it was ready (i.e. when all of the
packages that can be installed with packman are available to install
with portage)?

3) How likely would it be that the mainline minix releases would
include the portage package manager? If not very likely, would it be
problematic if I created a portage based minix install CD (not forking
the minix code, not adding any crazy patches, just the plain vanilla
packages but installable/upgradable with portage)?

4) On a scale of 1 (terrible idea) to 10 (great idea) how would you
rate this idea?

Thanks for your input!
-Thomas

--
You received this message because you are subscribed to the Google Groups "minix3" group.
To post to this group, send email to min...@googlegroups.com.
To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/minix3?hl=en.

[Erik van der Kouwe]

Hi,

Thanks for your interest in MINIX and your proposal.

1) Would the minix community find this to be a useful project?

MINIX is in need of a better package manager. However AFAIK this one
is GPL licensed and we prefer to use only BSD licensed code in the
base system. The package manager is part of the bae system, so we are
unlikely to accept Portage as the default package manager.

We from the MINIX team prefer the pkgsrc package manager. Hopefully,
we will get a GSoC student to port this for us.

2) Would you try it out when it was ready (i.e. when all of the
packages that can be installed with packman are available to install
with portage)?

Probably not, given that if all goes well we should have pkgsrc
reasonably soon.

3) How likely would it be that the mainline minix releases would
include the portage package manager?

Given the license issues and the availability of an alternative, the
chance is very low.

> If not very likely, would it be
problematic if I created a portage based minix install CD (not forking
the minix code, not adding any crazy patches, just the plain vanilla
packages but installable/upgradable with portage)?

Feel free to do that, the license allows it and we are certainly not
opposed to new projects deriving from MINIX. However, do keep in mind
that the maintenance burden is substantial.

With kind regards,
Erik

[Luca Barbato]

On Apr 16, 9:21 pm, Erik van der Kouwe <erik...@gmail.com> wrote:
> Hi,
>
> Thanks for your interest in MINIX and your proposal.
>
> 1) Would the minix community find this to be a useful project?
>
> MINIX is in need of a better package manager. However AFAIK this one
> is GPL licensed and we prefer to use only BSD licensed code in the
> base system. The package manager is part of the bae system, so we are
> unlikely to accept Portage as the default package manager.

You might find pkgcore[1] as a nicer fit since it is also BSD
licensed. Most of the work anyway
would be providing ebuilds for all the minix packages and ensuring
that what's available through
portage repository would build and run properly on minix.

lu

[1] http://www.pkgcore.org/

[Erik van der Kouwe]

Hi,

> You might find pkgcore[1] as a nicer fit since it is also BSD
> licensed. Most of the work anyway
> would be providing ebuilds for all the minix packages and ensuring
> that what's available through
> portage repository would build and run properly on minix.

Thanks for the idea, but pkgsrc is also BSD licensed. Moreover we plan
on porting more code from the BSDs in the future, so it will most likely
be easier to get their packages as well.

Does pkgcore have any particular advantage over pkgsrc?

With kind regards,
Erik

[Luca Barbato]

On Apr 18, 9:14 am, Erik van der Kouwe <erik...@gmail.com> wrote:
> Hi,
>
> > You might find pkgcore[1] as a nicer fit since it is also BSD
> > licensed. Most of the work anyway
> > would be providing ebuilds for all the minix packages and ensuring
> > that what's available through
> > portage repository would build and run properly on minix.
>
> Thanks for the idea, but pkgsrc is also BSD licensed. Moreover we plan
> on porting more code from the BSDs in the future, so it will most likely
> be easier to get their packages as well.

Gentoo already supports freebsd and hopefully other bsd systems will
be added,
netbsd had been ported to a degree last summer and the student who did
is becoming
a developer, so the port should remain live and maintained.

> Does pkgcore have any particular advantage over pkgsrc?

pkgcore is an alternate implementation of portage package manager, so
it shares
most of its strengths as package manager and all the strengths due the
ebuild format.
I have no experience with pkgsrc, so I looked at the online docs and
poked the web
interface/cvsweb, probably some points are wrong. Those are the first
that came to me
after just 20min of digging, probably I'm missing more and I'm not
seeing the strengths
of pkgsrc at all. I hope someone with more experience with both would
give more
details =) :


- pkgsrc repo seems to have 8886 packages, portage repo 13882
- the category layout is more structured in portage
- writing a package has an higher barrier since the pkgsrc makefile
syntax and convention
seems less uniform than ebuild ones and less structured/organized
- The pkgsrc package management facility is scattered across make
calls, pkg_* calls and other,
portage an pkgcore keep most of it in a single call (pmerge/emerge)
- Both pkgcore/portage and pkgsrc seems to have Q/A facilities
- Both pkgcore/portage and pkgsrc have a full dep resolver
- pkgcore has support for multiple repositories, pkgsrc doesn't
- pkgsrc doesn't seem to have an organized support to enable/disable
optional feature (use flags in portage)
- nor a way to have optional features switched on/off (e.g. ccache,
distcc, collision protection and such)

Beside that I can see many similarities in the basics so I won't feel
completely lost using pkgsrc, probably people
used to pkgsrc won't feel lost using pkgcore or portage as well.

lu

[Antoine LECA]

Luca Barbato wrote:
> Gentoo already supports freebsd and hopefully other bsd systems will
> be added, netbsd had been ported to a degree last summer and the
> student who did is becoming a developer, so the port should remain
> live and maintained.

If I understand you correctly, it means that _when_ Minix will complete
the new BSD-compatible (or BSD-based, as you want) litfing which is in
progress, _then_ Minix could be added as a new architecture, alongsides
with FreeBSD and NetBSD on Gentoo. Correct?

>> Does pkgcore have any particular advantage over pkgsrc?
>
> pkgcore is an alternate implementation of portage package manager, so
> it shares most of its strengths as package manager and all the
> strengths due the ebuild format.

Thanks for the information digging, it really helps (me).

> - pkgsrc repo seems to have 8886 packages, portage repo 13882

I would not give too much emphasis about these numbers. I know for a
fact that a number of pkgsrc packages are pretty old and without live
utility, or with very small potential audience, and I believe that the
same goes on with any other package manager. Giving more importance to
those numbers will only contribute to that inflation, and I consider it
a Bad Thing (YMMV, of course).

> - the category layout is more structured in portage

Not too surprising when one looks at pkgsrc!

> - writing a package has an higher barrier since the pkgsrc makefile
> syntax and convention seems less uniform than ebuild ones and less
> structured/organized

This raises immediately one question: which make tool is used? required?
Since Minix switches to BSD make, the requirements for BSD Makefiles is
a non-event; OTOH, requiring GNU make seems problematic for a BSD-based
tool...



Antoine

[Luca Barbato]

On Apr 19, 10:31 am, Antoine LECA <Antoine.Lec...@gmail.com> wrote:
> Luca Barbato wrote:
> > Gentoo already supports freebsd and hopefully other bsd systems will
> > be added, netbsd had been ported to a degree last summer and the
> > student who did is becoming a developer, so the port should remain
> > live and maintained.
>
> If I understand you correctly, it means that _when_ Minix will complete
> the new BSD-compatible (or BSD-based, as you want) litfing which is in
> progress, _then_ Minix could be added as a new architecture, alongsides
> with FreeBSD and NetBSD on Gentoo. Correct?

It means that gentoo supports the bsd userspace now, so if the gentoo/
minix
port is successful users would be able to pick which component they
like better
with minimal effort.

> > - pkgsrc repo seems to have 8886 packages, portage repo 13882
>
> I would not give too much emphasis about these numbers. I know for a
> fact that a number of pkgsrc packages are pretty old and without live
> utility, or with very small potential audience, and I believe that the
> same goes on with any other package manager. Giving more importance to
> those numbers will only contribute to that inflation, and I consider it
> a Bad Thing (YMMV, of course).

We try to keep packages alive and we have even a dedicated group to
actively
cleanup the tree to address such issue =)

> This raises immediately one question: which make tool is used? required?

ebuild syntax is shell, so it doesn't require a specific make, but
indeed requires
a compatible shell interpreter.

lu

[Gautam BT]

As part of my GSoC application, I did some reading up on pkgsrc. Some of the differences being discussed are not entirely true:

- pkgcore has support for multiple repositories, pkgsrc doesn't

By repos, you mean repos for binary packages? If so one can export PKG_PATH to switch between repos. See [1] for more details.

- pkgsrc doesn't seem to have an organized support to enable/disable
optional feature (use flags in portage)
- nor a way to have optional features switched on/off (e.g. ccache,
distcc, collision protection and such)

pkgsrc does have support for enabling and disabling features as well as for optional features. See [2] for more details.

[1] http://www.netbsd.org/docs/pkgsrc/using.html#using-pkg
[2] http://www.netbsd.org/docs/pkgsrc/options.html

--
Gautam

[Luca Barbato]

On Apr 19, 3:21 pm, Gautam BT <gautam...@gmail.com> wrote:
> As part of my GSoC application, I did some reading up on pkgsrc. Some of the
> differences being discussed are not entirely true:
>
> > - pkgcore has support for multiple repositories, pkgsrc doesn't
>
> By repos, you mean repos for binary packages? If so one can export PKG_PATH
> to switch between repos. See [1] for more details.

repositories in gentoo are both source and (optionally) binary so
overlooked that part.

> - pkgsrc doesn't seem to have an organized support to enable/disable> optional feature (use flags in portage)
> > - nor a way to have optional features switched on/off (e.g. ccache,
> > distcc, collision protection and such)
>
> pkgsrc does have support for enabling and disabling features as well as for
> optional features. See [2] for more details.
>
> [1]http://www.netbsd.org/docs/pkgsrc/using.html#using-pkg
> [2]http://www.netbsd.org/docs/pkgsrc/options.html

Thank you for pointing it, I completely missed that part

[Patrice Clement]

Hello,

I am the student who was in charge of porting Portage over NetBSD
during last Google Summer of Code. I handled both Portage and pkgsrc
APIs so maybe my thoughts could be useful for some of you:

Portage and pkgsrc have different behaviors and different aims as
well:
- pkgsrc is a framework to build and compile packages. It has no
reason to be without pkg_* tools, mostly used for packages maintenance
like pkg_install(1) [1]. pkg tools and pkgsrc are 2 distinct
projects.
- On the other side, Portage is a complete set of tools (frontend/
backend) developed by the same people, in a common project.
- pkgsrc aims to be multi-plateform, contrary to Portage (even though
Portage tends to become multi-plateform thanks to collateral projects
like Gentoo/BSD).
- pkgsrc doesn't support flavors, in a way that Gentoo does, mainly
via USE flags. Its flavors' support is not straightforward at all:
when you want to build, for instance, lighttpd with ipv6 support, you
have to explicitly specify it in /etc/mk.conf with a pretty awkward
syntax, something like PKG_OPTIONS.lighttpd += ipv6. And this, for
each package you want ipv6 with. Quite cumbersome, I guess.
- pkgsrc is horrible to keep up-to-date. Check out this wiki page to
understand what I'm talking about [2]: 3rd party tools (yes, 3rd
party, not base system tools), each doing a bunch of different things.
And it's not officially documented.
- I said a mean thing: maintenance tends to be ease thanks to an apt-
like tool, lately developed by a French NetBSD developer. Check out
pkgin [3].

There are plenty of other differences, but that are the first that
came to my mind. Hope it helps.

Cheers,

Patrice

[1] http://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkg_install/README.html
[2] http://wiki.netbsd.se/How_to_upgrade_packages
[3] http://imil.net/pkgin/

[Gautam BT]

- pkgsrc doesn't support flavors, in a way that Gentoo does, mainly
via USE flags. Its flavors' support is not straightforward at all:
when you want to build, for instance, lighttpd with ipv6 support, you
have to explicitly specify it in /etc/mk.conf with a pretty awkward
syntax, something like PKG_OPTIONS.lighttpd += ipv6. And this, for
each package you want ipv6 with. Quite cumbersome, I guess.

I have not used portage, so I am not sure about the advantages of Gentoo's USE flag over pkgsrc option framework. However, for the above example, adding inet6 to PKG_DEFAULT_OPTIONS (either on the command line or in mk.conf) will enable ipv6 support for all packages that use ipv6.

--
Gautam

[Luca Barbato]

On Apr 19, 10:52 pm, Gautam BT <gautam...@gmail.com> wrote:
> > - pkgsrc doesn't support flavors, in a way that Gentoo does, mainly
> > via USE flags. Its flavors' support is not straightforward at all:
> > when you want to build, for instance, lighttpd with ipv6 support, you
> > have to explicitly specify it in /etc/mk.conf with a pretty awkward
> > syntax, something like PKG_OPTIONS.lighttpd += ipv6. And this, for
> > each package you want ipv6 with. Quite cumbersome, I guess.
>
> I have not used portage, so I am not sure about the advantages of Gentoo's
> USE flag over pkgsrc option framework. However, for the above example,
> adding inet6 to PKG_DEFAULT_OPTIONS (either on the command line or in
> mk.conf) will enable ipv6 support for all packages that use ipv6.
>

It looks quite similar to me, in Gentoo you have:

in /etc/make.conf a USE var you can set like this

USE="mmx sse sse2 X gtk acpi svg xcb"

you might override it from command line by usual means

USE="foo" emerge foobar

you can see what are the use options available through

emerge -vp foobar

you can optionally query details through

euse -i foo

or set them through

euse -E foo (if you feel lazy)

if you want override use flags per package you can put a line in a
file in /etc/portage/package.use or /etc/portage/package.use/name if
you like to keep things more ordered, the syntax is quite
straightforward:

cat-bar/foobar foo -bar

for some more see our docs[1] or the man page[2]

Again looks to me portage useflags and pkgsrc flavours are similar
concept and provide a similar feature but with a simpler and more
rational layout on the Gentoo side ( probably since I'm more used to
it)

lu

[1] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=2
[2] http://linuxreviews.org/man/portage/