portage-c

[siti]

I am developing a program called portage-c which is intended to be a replacment for portage in the future.

As you can guess it's written in C, it has lightish dependencies (sqlite3, glib2).

I've got many things implemented:
* Search functionality - much faster than esearch probably a little slower than EIX as portage-c includes more metadata
* Verify function to check out for corruption
* Some qpkg function like "-f"
* Some other functions to find files with 2 or more packages using it
* Depepency code - slightly better than portage
* Ebuild.sh with stuff like unpacking, compiling and start of merging code

The biggest features is probably the design:
* VERY Modular
* SQL (only sqlite3 atm)
* Common Hash interface
* Designed for multithreading (This'll be good when the multicores come )
* Designed for speed
* Different interfaces can easily be added (Ie: GUI, command-line can all use the API)

Although portage-c is starting to look very promising I am in need of some developers that are good coders in C. As I want to get portage-c to be able to be used over portage ASAP. And most of all the developers need to have some free time and be dedicated/motivated. I am in the process of writing docs (using doxygen) to make it easier for devs to understand portage-c.

So if this sounds like you post here. Also any other comments about portage-c are welcome

To grab the current developer version of portage-c, RUN:

Code: Select all

svn co https://secure.adevel.com/svn/portage-c/trunk/portage-c

(you need subversion)

[Voltago]

Are you planning to be 100% portage-compatible?

[plbe]

nice idea...look foward to testing it

[Q-collective]

Cool

[siti]

Are you planning to be 100% portage-compatible?

At the moment I am using alot of portage stuff. I think portage-c needs to stay compatable for anyone to start using it. In the future there could be a move to a new ebuild format or other stuff like that.

[Wicked Wesley]

Hey man, that sounds pretty cool, would be even better without the sqlLite dependency, but hey, can't have it all I would definitly use it! Searching can be sooooooooo slow with portage As long as you keep it compatible, people will use it. And if enough people use it, gentoo devs will probably switch to it

Good luck!
Wesley

[allucid]

would be even better without the sqlLite dependency, but hey, can't have it all

It needs some kind of database to be quick and manageable.

[tigrezno]

would be even better without the sqlLite dependency, but hey, can't have it all

It needs some kind of database to be quick and manageable.

A small database can be implemented without dependencies, as it won't save sensible data, just the portage metadata

[uman]

ok well I decided to start working on portage-c yesterday. It is going to be awesome when finished!

[EzInKy]

Hey man, that sounds pretty cool, would be even better without the sqlLite dependency...

You are right about the sqLite dependency. System software should statically link as much as possible to avoid breakage due to library changes. As for the prospective "c" portage version, many have contemplated such projects in the past, including me when they deprecated the "--upgradeonly" option. Seems I even recall someone planning a "c++" fork of Gentoo a couple of years ago that even made Slashdot headlines. I guess that one died an ignoble death (a lot of politics was behind it too) because it was never heard of again. But that does bring up the main problem, which is forking.

Gentoo is among the top ten Linux distributions, and the system does work pretty darn well despite its reliance on an interpreted language such as Python, an utterly horrible language for those of us with bracket fetishes. Now sometimes forking a project is good, but only if there is a clear and perfectly sound reason to do so. So, to the original poster I ask the question. Why. with all the open source "c" and "c++" code that sorely needs to be written to create apps that don't exist, should a programmer work on one that does?

DISCLAIMER: The above was typed out after spending the last week studying low level Xlib and OpenGL interfaces while consuming a twelve pack of beer. Take with a grain of salt B-)

[allucid]

As for the prospective "c" portage version, many have contemplated such projects in the past, including me when they deprecated the "--upgradeonly" option.

This is offtopic but you do understand that --upgradeonly was deprecated because there are better methods in place to handle mixed "arch" and "~arch" systems than the ugly ACCEPT_KEYWORDS="~arch" and --upgradeonly combo of the past? There is no need for the --upgradeonly option with the current portage system in use now.

[plbe]

The one thing I miss about FreeBSD is reverse dependencies...don't forget this one

[EzInKy]

This is offtopic but you do understand that --upgradeonly was deprecated because there are better methods in place to handle mixed "arch" and "~arch" systems than the ugly ACCEPT_KEYWORDS="~arch" and --upgradeonly combo of the past? There is no need for the --upgradeonly option with the current portage system in use now.

Yes, I participated in some of the discussions. Running an "~arch" system from the time it was introduced I thought people should just make up their minds. But your right, it is offtopic and my thoughts were meandering B-)

[pilla]

Moved from OTW

[siti]

Yeah there have been alot of forks();

I just discovered a few days back "portage2" in gentoo's cvs. It looked like the person done some planning then realised it would take ages and abondoned it. Also there was zynot, that's dead I think.

The difference with portage-c is that it's got actual code that works and is being activley developed. You can already see advantages in a fresh remake. Sadly python portage doesn't have a good design structure which is the reason they are unable to add features quickly. With portage-c half the advantage is a good modular design which will mean features are really really easy to add

[charlieg]

Once this gains a bit more momentum I can see it being quite popular. I might try it when a few more features and a bit more testing has happened. (Too busy to just jump in feet first, I'm afraid.)

[Sparky]

When are you planning finish portage-c?

[siti]

When are you planning finish portage-c?

I would hope to have a fully done portage replacment by the end of this year. Maybe sooner maybe later. Things like this are impossible to predict when it'll be complete...

[Evil Dark Archon]

compile error in latest svn revision

Code: Select all

 gcc -DHAVE_CONFIG_H -I. -I. -I.. -fPIC -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I../include -O3 -fomit-frame-pointer -pipe -s -march=athlon64 -mmmx -msse -msse2 -m3dnow -funroll-loops -fprefetch-loop-arrays -ftracer -w -MT modules.lo -MD -MP -MF .deps/modules.Tpo -c modules.c  -fPIC -DPIC -o .libs/modules.o
modules.c:70: error: conflicting types for 'p_module_start_async'
../include/portage-c.h:74: error: previous declaration of 'p_module_start_async' was here
modules.c:70: error: conflicting types for 'p_module_start_async'
../include/portage-c.h:74: error: previous declaration of 'p_module_start_async' was here
modules.c:95: error: conflicting types for 'p_module_get_number_running'
../include/portage-c.h:76: error: previous declaration of 'p_module_get_number_running' was here
modules.c:95: error: conflicting types for 'p_module_get_number_running'
../include/portage-c.h:76: error: previous declaration of 'p_module_get_number_running' was here
modules.c:110: error: conflicting types for 'p_module_start_sync'
../include/portage-c.h:75: error: previous declaration of 'p_module_start_sync' was here
modules.c:110: error: conflicting types for 'p_module_start_sync'
../include/portage-c.h:75: error: previous declaration of 'p_module_start_sync' was here
make[2]: *** [modules.lo] Error 1
make[2]: Leaving directory `/root/portage-c/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/portage-c'
make: *** [all] Error 2

[NocturnalCoffeeMan]

ohhh... I always thought that portage-c was a standalone portage system for other distros like slackware and mandrake and such.

[uman]

Evil Dark Archon: How exactly did you try to build it?
NocturnalCoffeMan: no but there is something like that called "emerde" (the creators didn't seem to realize it sounds like e-shit to the French lol)

[Evil Dark Archon]

standard ./configure, make, make install (if it got to that point)

[siti]

compile error in latest svn revision

Code: Select all

 gcc -DHAVE_CONFIG_H -I. -I. -I.. -fPIC -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I../include -O3 -fomit-frame-pointer -pipe -s -march=athlon64 -mmmx -msse -msse2 -m3dnow -funroll-loops -fprefetch-loop-arrays -ftracer -w -MT modules.lo -MD -MP -MF .deps/modules.Tpo -c modules.c  -fPIC -DPIC -o .libs/modules.o
modules.c:70: error: conflicting types for 'p_module_start_async'
../include/portage-c.h:74: error: previous declaration of 'p_module_start_async' was here
modules.c:70: error: conflicting types for 'p_module_start_async'
../include/portage-c.h:74: error: previous declaration of 'p_module_start_async' was here
modules.c:95: error: conflicting types for 'p_module_get_number_running'
../include/portage-c.h:76: error: previous declaration of 'p_module_get_number_running' was here
modules.c:95: error: conflicting types for 'p_module_get_number_running'
../include/portage-c.h:76: error: previous declaration of 'p_module_get_number_running' was here
modules.c:110: error: conflicting types for 'p_module_start_sync'
../include/portage-c.h:75: error: previous declaration of 'p_module_start_sync' was here
modules.c:110: error: conflicting types for 'p_module_start_sync'
../include/portage-c.h:75: error: previous declaration of 'p_module_start_sync' was here
make[2]: *** [modules.lo] Error 1
make[2]: Leaving directory `/root/portage-c/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/portage-c'
make: *** [all] Error 2

I'll commit a fix soon. It's just I forgot to update the prototype which had guint instead of gsize which would only fail on amd64...

[uman]

ok at the moment it's just me and siti developing this, and I'm a C/programming n00b so there's really only like 1.5 developers
So if anyone wants to help us realize our goal of making portage better and faster, come see us in #portage-c on irc.freenode.net. We need all the help we can get!

[neonik]

Here the ebuild (alternatively portage-c-svn-20050325.ebuild):

Code: Select all

# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-apps/portage-c/portage-c-svn-20050325.ebuild,v 1.1 2005/03/25 11:44:47 neonik Exp $

inherit eutils subversion

DESCRIPTION="Gentoo package manager written in C"
HOMEPAGE="http://portage-c.sourceforge.net"
LICENSE="GPL-2"
SLOT="1"

# add other architectures as long as tested :)
KEYWORDS="~x86"

# any USE flags, e.g. static or epm?
IUSE=""

# check out the version numbers
DEPEND=">=dev-db/sqlite-3.2.0
	>=sys-libs/glibc-2.3.3.20040420-r2
	>=sys-devel/gcc-3.3.5-r1
	>=dev-libs/glib-2.6-2-r1"

# any more run dependencies required?
RDEPEND=">=dev-db/sqlite-3.2.0"

ESVN_REPO_URI="https://secure.adevel.com/svn/portage-c/trunk/portage-c"
ESVN_PROJECT="portage-c"
# ESVN_BOOTSTRAP="./build.sh"

cflag_setup()
{
	append-flags -std=c99
}

src_compile()
{

	einfo "Please ignore configuration warnings like: warning: underquoted definition of ..."

	export WANT_AUTOMAKE=1.8
	emake -f Makefile.cvs

	econf --sysconfdir=/etc --prefix=/usr --disable-dependency-tracking || die "Could not configure"

	emake || die "emake failed"

}

src_install()
{
	mkdir ${WORKDIR}/${PF}/INSTALL_DIR

	local_dir=${WORKDIR}/${PF}/INSTALL_DIR

	emake install DESTDIR=${D} || die "Could not install"

# 	install configs
	insinto /etc
	doins ${local_dir}/etc/*

# 	install the executable binaries
	dobin ${local_dir}/usr/bin/*

# 	install includes
	insinto /usr/include/portage-c
	doins ${local_dir}/usr/include/portage-c/*

# 	install common libs
	insinto /usr/lib
	dolib ${local_dir}/usr/lib/*

	insinto /usr/lib/pkgconfig
	doins  ${local_dir}/usr/lib/pkgconfig/*

	insinto /usr/lib/portage-c
	dolib ${local_dir}/usr/lib/portage-c/*

# 	install docs
	dodoc AUTHORS COPYING ChangeLog INSTALL README NEWS

# should be done
}
pkg_postinst()
{
# little warning message
	ewarn "Please note that this software is in its early development stage and should"
	ewarn "not be considered stable for use on production systems."
	ewarn "Please do not submit BUGS found in this software to Gentoo developers - they are"
	ewarn "in no way affiliated with Portage-C and therefore do not support it"
	ewarn "and therefore cannot be made responsible for any harm done, as well as Portage-C developers and affiliated persons."
	einfo "As for the rest, please feel free to test it out and provide us feedback at http://portage-c.sourceforge.net or in #portage-c@irc.freenode.net."
}

Edit: Fixed the ebuild, works now properly.

New issue: As you can see the ebuild is quite dirty (see the function src_install() ), for some reason I cannot get it to `emake install DESTDIR=${D}` which would be rather logical. If anyone can fix that, please do so.

I'd like to ask you to check the dependencies, also the RDEPS. Thanks.