Re: [gentoo-dev] using Portage with other distributions.

[Terje Kvernes]

(I noticed the lack of gentoo-dev@g.o on the CC list, since I
  cannot know if this was intentional I'm leaving it off also for this
  reply.  feel free to add the gentoo list again if you so desire. :-)

Patrick Lauer <gentoo@×××××××××××××.de> writes:

> On Thu, 2003-07-17 at 17:09, Terje Kvernes wrote:
>
> > I've started trying to clean up emerge, and work my way through
> > Portage from there.  in my opinion, /usr/bin/emerge should look
> > something like this:
>
> I like it :-)

  thank you.

> It is easy to understand and should be quite modular.

  the concept is "encapsulation".  these days Portage has no
  understanding of the concept itself -- something which is _very_
  scary.  it feels a lot like Portage was developed as a
  proof-of-concept that grew into a "solution".

> > pretty please, if one is going to do something about the backend
> > layer, make it layered and pluggable.  with "layered" I mean that
> > we as an example should seek to make a database interface that you
> > can specialize for MySQL, PostgreSQL, Oracle or whatever.
>
> Yes, I know. but if you implement an SQL-layer it will be easy to
> plug a database into the backend. MySQL is just one specific target
> because it is available on almost all machines.

  fair enough.  just avoid making any assumptions about that backend.
  "assumptions is the mother of all fuckups".[1]
 
  [ ... ]

> > thank you, but I'm somewhat familiar with Python.  :-)
>
> I hope you can forgive my ignorance ;-)

  it's no biggie.  I'm rather used to people on gentoo-dev telling me
  to learn my python since I don't like the way portage looks today.

  I spent about a year and a half developing an XML database server
  and publishing solution in python, with four other people.  this was
  a few years ago though.  I have since dropped working with XML or
  python.
  
> > heh.  not quite.  I do "emerge sync && emerge -U --fetchonly" in
> > cron.daily.  merging I do manually, for several reasons.
>
> Maybe FEATURE="autofetch" should be implemented :-)

  heh.  seriously though, 'FEATURES="autofetch"' might be feature
  creep.  then again, if things are properly modular, it should be
  trivial to apply to the context you're in.  although we might want
  to disable it for searches.  :-p
   
> > stability is rarely a problem, most things can be fixed and
> > debugged.  I generally have the attitude that it's better that it
> > hits me than anyone actually expecting stability.  besides,
> > debugging is (occasionally) fun.
>
> Oh my, you have too much time on your hands ;-)

  actually, no.  time is by far my worth valuable asset.  the time it
  takes to observe, track and fix the bug varies.  ;-)

> But I agree, stability is rarely a problem with gentoo.

  life, generally, is good.  
   
  [ ... ]

> Since there is almost no official documentation about
> portage-internals this will be mostly deductive work in the
> beginning. There is a documentation effort, but it has not yet
> produced public documentation.  *sigh*

  I'm aware of this.  how you can produce a backbone in a distribution
  like what Portage is and _not_ have any formal documentation is
  rather scary.  
  
> > yup.  now, if I could only thump some sense into Python, I'd be
> > happy.
>
> Why that?

  package and object management in Python can be annoying.  'from
  Emerge import Emerge'?  seriously, I don't care what _file_ the
  Emerge class is in, I just want to load the class / namespace /
  scope / whatever you want to call it.

  also, the requirement that all labels should be declared before
  they're used is highly annoying.  I'd like /usr/bin/emerge to look
  more like:

import sys

from Emerge import Emerge 

processor = Emerge()
command, arguments = get_command( sys.argv )

# execute throws an exception on errors.
try:
	processor.execute( command, arguments )
except Exception, e:
	print e


def get_command( arglist ):
    # ...

  in effect I'd like to not have the main call at the bottom.  I read
  text and code from the top downwards.  I don't much like having to
  skip up and down to be able to follow the control flow.
 
> Python has some limitations, but in my experience it is more useful
> for rapid development and test implementations than most other
> languages.

  personally, I'd write the implementation in perl.  and no, perl
  isn't ugly if it's done properly.  if you want some examples, I can
  always dump them your way.  my current work is a "process
  processor", to enforce rules with consequences on the process table.
  <url: http://www.math.uio.no/~terjekv/flapp.html > is the current
  documentation for the main module.

> Portage in C would be brutal and even more obfuscated.

  Portage in C would be _bad_, that much we can agree on.  C++ would
  be even worse.  sadly enough, this is what Zynot are looking at
  doing.  

  it doesn't help if you want to clean up Portage when your target is
  C.  we have almost 10K lines of python code with a lot of libraries
  used.  how many lines of code would a similar C application consist
  of?



  [1] spot the reference.  

-- 
Terje

--
gentoo-dev@g.o mailing list