Caleb Cushing's Blog Also known as XenoTerraCide
Posts with the tag pms:

sync target support

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.

accept input from stdin

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.

minimum permissions and privilegdges

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 the victor

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.

Graphical Package Manager

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.

More than 3 levels of stable

Currently Gentoo has arch, ~arch, and ~M ( - if not available ).One of the main things people want are security patches only updates. I tend to agree with this, although they should be between arch and ~arch, maybe +arch. Technically a security patch can break things which is why they shouldn’t be considered stable.Regen2 should also have strict rules about what’s what. Alpha products should always be ~M, beta’s and rc’s should be ~arch.

buildpkg

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.

emerge-ng multiple trees

first I hate repositories, but it is unlikely they will go away. So we must strive to make sure that they are only needed for truly rare things. from my perspective the sunrise repo shouldn’t exist. and vcs builds should be in the tree. regen2 should strive to have everything possible in the tree. when it can’t an overlay should have all the capabilities of the main tree. meaning that an overlay shouldn’t automagically be considered less stable and require the keywording of all the ebuilds in it.

emerge-ng

at the time of this writing. a concept for software with a name that may not be it’s final, and it may never get done.emerge-ng should ultimately be a drop in replacement for the portage package (the main package manager) in gentoo linux.for clarity I will be referring to portage as the software and if I mean to refer to portage’s tree (basically one giant software repository), I will refer to it that way.