Slashdot Mirror


BSD Version Of Gentoo's Portage

eugene ts wong writes "Here is some good news for BSD users. Gentoo Weekly Newsletter has an article that says that there is a BSD version of portage. It's still in a developmental stage, but it's definitely making progress."

8 of 155 comments (clear)

  1. Re:Ease of Use for Package Management by sporty · · Score: 5, Informative

    Do realize, that ports has done this for a long time. Only diff beween ports and portage are the command structure, some layout and the systems that they originated for.

    The cool thing about ports in relation to freebsd, and prolyl the other bsd's.. is that they integrate with the package systems used. SO if you want, you can download the tbz (vs tgz) package or use /usr/ports.

    --

    -
    ping -f 255.255.255.255 # if only

  2. Re:Portage versus Ports? by aliquis · · Score: 2, Informative

    The huge difference between ports and portage is that portage has replaced makefiles and instead uses a python based solution. They also got USE-flags there you can specify stuff like "X ssl gtk -kde -cups" and stuff like that, to make applications which can use X and ssl compile with those options enabled, but not compile kde and cups support.

  3. Re:Portage versus Ports? -- IMHO/IMOE by Ricin · · Score: 3, Informative

    Portage doesn't replace makefiles, at least not the ones provided to build the actual program.

    The FreeBSD's ports' Makefile basically sets a load of build/package organization variables, almost the same as a portage "ebuild" does. An ebuild is a script though. I've submitted a few when I was trying out Gentoo a while ago.

    Portage just happens to be written in python (good choice BTW IMHO) whereas the traditional pkg-tools for FreeBSD are C based and the portupgrade utility is written in Ruby.

    Portage was inspired by NetBSD's pkgsrc which was derived from FreeBSD ports. Flags like PROVIDES are similar to USE and somewhat comparable to FreeBSD's make options for ports e.g. "NO_GUI"=true and stuff like that. I do like the USE idea though.

    The interesting thing about portage as a FreeBSD user is two sided really: the pro would be that the functionality of portupgrade would be part of the portmanager tool (portage) itself, the con is that *BSD (even Net) are not a kernel with packaged userland, it is a full (perhaps small though) OS and the hard thing is always where to draw the line and whether or not the base system can and should be put into packages/ports/ebuilds also. Like any OS Gentoo Linux needs a bootstrap and a chaintool too to build the rest. LFS'ish (quite easy though, they have good docs).

    The Gentoo "rc scripts" are also very NetBSD inspired and recently FreeBSD has followed this approach, e.g. using PROVIDES, and BEFORE, etc.

    My (rather short) experience with portage was that I liked it, but it's definately more geared towards a linux (kernel+tools+pkgs) system. It also broke quite frequently though. And of course, python is always nice, if only to unbreak little things easily (I'm not much of a C person).

  4. Re:Shortcoming #1: by Arandir · · Score: 4, Informative

    Do we really need to throw out stable and robust ports entirely just because you like the USE flags? If it's so desperately wanted by you, then perhaps you could actually code it up. It's all just simple makefiles, so you don't even need to learn python.

    There already are "USE" flags of a sort, but they're more specific than the general purpose flags that Gentoo uses. Adding some new flags should be a piece of cake, if you can convince the committers of their need.

    --
    A Government Is a Body of People, Usually Notably Ungoverned
  5. Re:Shortcoming #1: by stab · · Score: 2, Informative

    OpenBSD has FLAVOR and MULTI_PACKAGES exactly for this. Each port has a set of knobs that can be twiddled, and the binary packages are generated and named appropriately.

  6. Re:Changes to ports by __past__ · · Score: 2, Informative
    The problem with this is that some ports (e.g. ghostscript and php) have curses based front-end for selecting make flags. This causes portupgrade to wait for user input
    Use portupgrade -m "BATCH=yes", and no user input will be required. You can also set the variables that you want your ports to be built with in /etc/make.conf, or, more flexibly, in /usr/local/etc/pkgtools.conf, based on the ports name (including wildcards). This is a good idea anyway, because you don't have to remember all these options, they will be the same on every update.

    The only problem is finding the options you can use. The best approach is currently to simply examine the port's makefile, say by grepping for "^\.if", but that doesn't always work (for example, the postfix ports use a different mechanism). So learning to read and understand makefiles is a good idea, and reading the porter's handbook also pays off. A standardized mechanism to query a port for all available options would be definitly a Good Thing (it would also make writing graphical frontends for the ports tree way easier, for example) - there have been some ideas how this could be done, but nothing has worked good enough yet, and of course, switching ~8000 ports to a new system would be a lot of work.

  7. Re:What they don't want you to hear... by Anonymous Coward · · Score: 1, Informative

    Why do you insist upon posting with out the facts? According to NetCraft Surveys (yes, I come from a world where we actually like to quote our sources.) Usage of the BSD's is actually increasing. And by most reports (including e-week, and linuxworld) *BSD's are more stable than any other system out there. Before you decide to make another idiot comment to make yourself feel better about who you are try to get the facts straight.

  8. Re:What I know about *BSD by qmrq · · Score: 1, Informative

    1. You can not play games on it. 2. It cannot be used by my grandma. 3. It lacks a GUI of any note. 4. There is no support available for it. 5. It is an assortment of fragmented OSes. 6. It cannot be run on the x86 platform. 7. You have to compile everything and know C. 8. Support for the latest hardware is always poor. 9. It is incompatiable with GNU/Linux. 10.It is dying. 1. Of course you can play games on it. 2. Sure it can. 3. You can use any popular GUI. wm, KDE, GNOME etc. 4. Are you too stupid to figure out mailing lists? 5. No, it's not. 6. Ehm. Yes it can. 7. Wrong again. 8. Sometimes. Same thing with any *NIX though. 9. ? Wrong wrong wrong. :( 10. Hah! Not hardly.