Re: [gentoo-portage-dev] The merge of emerde with emerge

[Brian Harring]

On Fri, 2004-12-03 at 10:01 +0100, Paul de Vrieze wrote:
> At the point where there are proper modules in portage, I'm all for it to
> make everything a module.
It's coming down the pipe.  Obviously done when it's done, but
refactoring the tree code and moving it out of portage.py and into their
own modules is my next target after I put the finishing touchs on cache
refactoring, and contents backend refactoring (bit more then a finishing
touch on the latter- need to do integration of it).

> What I mean is that slack code should be
> modularized in such a way that there is no trace of it when you don't
> want it.
For using a slack repository, it's possible/viable.  For
identifcation/merging of a slack tgz, that's a different case.  Unless
portage is dynamically loading all modules in a directory (or in a
specified list), identification of the tgz will be tricky- _even_ if all
slack related code is loaded on demand, that still leaves the nasty mess
of writing hooks for modules to register functions for identification of
a format.  I honestly don't see that happening for a long while, I'd
expect identification of the various formats to be handled in portage.

>  For the current system that means some wrapper of some kind.
Define wrapper.  module wrapper, seperate binary wrapper...

>  For
> a modularized system that means that there is a slack package that
> installs a number of slackware specific modules and configures portage to
> use them.
There really isn't/won't be any simple way to configure portage to be
aware of new formats on the fly (imo).  It's doable, but I disagree that
no additional formats should be supported until the code is implemented
that way- as is, we already have code in portage for handling our own
binpkg format, and for rpms.
~brian


--
gentoo-portage-dev@g.o mailing list