* Felix Salfelder <fe...@salfelder.org> [2013-04-22 13:01:20 +0200]: > On Mon, Apr 22, 2013 at 03:15:54AM -0700, Timo Kluck wrote: > > We're trying to replace the current spkg system (actually the spkg system > > like it exists in the git repo) by some version of Gentoo's portage. This > > would be similar to the lmonade project, except that it's trying to be a > > smooth transition from the current source distribution. > are you targeting sage-upstream or is this a local hack that is doomed > to fail some releases (and several git-transitions) later? We're targeting sage/git upstream.
> > As soon as this works, then it would be possible to use this to generate
> > debian packages, since portage keeps track of installed binary files for
> > packages. So the debian/rules file could query portage for which files
> > should go into which binary package.
> the goal of the/my gsoc project would be streamlining the packaging of
> debian/gentoo/whatever packaging process. having to use an extra layer
> ("portage"), makes things worse. no debian maintainer i can think of
> would seriously use it.
You don't have to use portage. If all spkgs are debian packages, then
there is no point in using portage since you won't be using any spkgs
anyway. You could of course use it as part of the build process and
unmerge portage in a final step to remove it again.
> PS: i don't want to make your work obsolete, but it's obviously too
> gentoo centric
I don't believe it is gentoo centric. Actually, I'm not even using
gentoo myself anymore.
The current SPKG approach has its problems, especially with the new git
layout. One main problem being that you cannot uninstall an SPKG when
you switch to a branch where it is not present. That's where we want to
use portage. I at least don't think of portage here as a distribution
system, but just as a tool to configure/install/uninstall things in a
local prefix.
julian
signature.asc
Description: Digital signature
