This is just a feature concept. May or may not ever happen. Live builds for portage usually run off the trunk/master branch of a scm tool. This is a great idea, but why couldn’t we take this a step further, usually people who use scm’s ‘tag’ there releases, so why couldn’t the same ‘live’ build have an option for using a tag instead of trunk. This would allow releases to roll out much faster too.

So, I won’t be the Tree Maintainer for Funtoo anymore. In light of the new situation I’m forking Funtoo. I’m not going into details why I’m not the tree maintainer anymore on this blog, except to point out how Regen2 will differ.I’ll be continuing to maintain a tree with all the overlays I had added and more to come. you can get a copy of my version of portage at git://github.

HereI explain why emerge –sync should return to it’s original sync form.I think emerge sync should have the ability to have a target. Currently emerge –sync has a target of the SYNC variable in make.conf or the default hardcoded. However, git support is being added to portage. git is a very powerful tool, and the Funtooproject uses it to manage it’s full portage tree. git doesn’t work like rsync, it’s not so straight forward as rsync uri, which is effectively what emerge sync is doing.

Ok so I have yet another idea for portage and other portage like package managers. actually this is probably more aimed at EAPI. Different types of USE flags. The 2 I’m thinking of off the top of my head could be described as volatile and non-volatile. Basically a use flag marked volatile means a package needs to be recompiled if it gets changed one marked non-volatile most likely just pulls in another dependency or copies files such as documentation.

if possible emerge-ng should be able to accept input from <STDIN>, e.g. cat packagelist | emergeng, thus far neither portage nore pkgcore have this capability.

I like security… which means I should be able to run portage as portage (user) and have the umask be 077, or perhaps 027. Unfortunately the last time I checked portage could handle these restrictive permissions (I forget if it was these exactly) except for one set… java. In a perfect ebuild world all ebuilds would be able to be installed under a very restrictive umask.Should regen2 ever come to fruition this should be fixed.

pkgcore is my pick for the next portage and codebase for emerge-ng. I admit I haven’t let paludis have a chance (yet).Why haven’t I let paludis have it’s chance?The reasons are quite simple. Everytime I have tried paludis prior to this it has required extra configuration (meaning it doesn’t work out of the box). I believe this was fixed recently. However,paludis@1208029212: [WARNING] Use of Portage configuration files will lead to sub-optimal performance and loss of functionality.

Anyone that knows how I work in linux, knows that I"m comfortable with the cli, and prefer it to a gui. I know that not everyone is or should have to be. Sometimes a gui can make management easier. Even a die hard cli person like me realizes that. However, you should never have to do things the gui way, they are just front ends. emerge-ng needs to support having a gui even if the development of such a project is not directly part of the emerge-ng project.

emerge-ng should be able to build rpms, and debs. regen2 should be the distro that builds other distro’s, not only should it be good at that (gentoo is now) it should be designed for it.–This workby Caleb Cushingis licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

details are hereso apparently the folks running the kde overlay have decided to discontinue portage compatibility. I suppose I can’t blame them, on the other hand I don’t approve. Even though I haven’t started testing paludis yet. I am still firmly against it as it is as gentoo’s next package manager. I won’t be regen2’s without heavy modification. Including some re-writes. I do intend to investigate the possibility of using paludis code in emerge-ng.