public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] using Portage with other distributions.
@ 2003-07-14 12:16 Terje Kvernes
       [not found] ` <1058168210.2166.6.camel@localhost>
  0 siblings, 1 reply; 5+ messages in thread
From: Terje Kvernes @ 2003-07-14 12:16 UTC (permalink / raw
  To: gentoo-dev


  first off: at work we don't run Gentoo and this will not change.  I
  would however like to use Portage for stuff that the chosen
  distribution doesn't supply, or just to keep more up to date
  software available under, say, /portage (the ROOT name is
  irrelevant, but it's not /usr or (/usr)/local).  think of this a
  good replacement for encap.

  my first attempt was to make portage self-contained under this root,
  using /portage/etc and similar structures.  this I had to abandon
  rather quickly, as /etc/make.conf and similar files are hardcoded to
  be under /etc.

  I then opted to keep a minimal set of files under /etc, but install
  software under /portage.  I proceeded to inject packages that I
  didn't want portage to fiddle with -- something that worked as
  expected.  I then tried to upgrade portage[1] and got the following
  error:

nommo:/# emerge -U world

portage: 'portage' user or group missing. Please update baselayout
         and merge portage user(250) and group(250) into your passwd
         and group files. Non-root compilation is disabled until then.
         Also note that non-root/wheel users will need to be added to
         the portage group to do portage commands.

         For the defaults, line 1 goes into passwd, and 2 into group.
         portage:x:250:250:portage:/var/tmp/portage:/bin/false
         portage::250:portage

>>> --upgradeonly implies --update... adding --update to options.
Calculating world dependencies ...done!
>>> emerge (1 of 1) sys-apps/portage-2.0.48-r1 to /
>>> md5 ;-) portage-2.0.48-r1.tar.bz2
Could not open the sandbox library at '(null)/libsandbox.so'.

  the user and group warning would be nice to turn off by the way.
  the real problem is the sandbox library which seems to be missing
  its path.  are there any good ideas on how to fix this?

  and, if anyone has done anything similar, I'm all ears.  if people
  are interested in making different roots under portage just
  work[tm], I might do some patching to portage and make the work
  available.


  [1] I based my Portage testing on the portage rescue image, which I
      dumped on /portage and created a lot of symlinks on /usr to make
      things work.  installing portage on /usr is something I really
      want to avoid, I _really_ wish for /portage to have everything
      related to portage.  :-/

-- 
Terje

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [gentoo-dev] using Portage with other distributions.
       [not found] ` <1058168210.2166.6.camel@localhost>
@ 2003-07-14 13:11   ` Terje Kvernes
       [not found]     ` <1058180419.2165.19.camel@localhost>
  0 siblings, 1 reply; 5+ messages in thread
From: Terje Kvernes @ 2003-07-14 13:11 UTC (permalink / raw
  To: Patrick Lauer; +Cc: gentoo-dev

Patrick Lauer <gentoo@toso-digitals.de> writes:

> On Mon, 2003-07-14 at 14:16, Terje Kvernes wrote:
>
> > first off: at work we don't run Gentoo and this will not change.  I
> > would however like to use Portage for stuff that the chosen
> > distribution doesn't supply, or just to keep more up to date
> > software available under, say, /portage (the ROOT name is
> > irrelevant, but it's not /usr or (/usr)/local).  think of this a
> > good replacement for encap.
> >
> > my first attempt was to make portage self-contained under this root,
> > using /portage/etc and similar structures.  this I had to abandon
> > rather quickly, as /etc/make.conf and similar files are hardcoded to
> > be under /etc.
>
> If you use chroot it's not a problem even to precompile gentoo for
> later installation. The procedure is basically:
> 
> * extract stage-n tarball into a directory
> * chroot /directory/where/you/put/it /bin/bash
> * emerge sync
> * emerge whatever-you-need

  this isn't a problem at all.  except that it's rather different from
  what I wish to achieve.  I already have a working system with glibc,
  GCC, bash, binutils and so on.  all I want portage to do is to
  install additional software outside of default system stuff.  this
  is why I injected the appropriate packages.  
 
> > the user and group warning would be nice to turn off by the way.
> > the real problem is the sandbox library which seems to be missing
> > its path.  are there any good ideas on how to fix this?
>
> in a chrooted environment it's not a problem. 

  that much we can agree on.  it doesn't help me though.

> The warnings are there for a reason, so son't ecpect them to go away
> ...

  there is a difference between "turn off" and "go away".  I know
  perfectly well why the warnings are there.  
 
> > [1] I based my Portage testing on the portage rescue image, which I
> >     dumped on /portage and created a lot of symlinks on /usr to make
> >     things work.  installing portage on /usr is something I really
> >     want to avoid, I _really_ wish for /portage to have everything
> >     related to portage.  :-/
>
> chrooting avoids all those path issues. There are some minor
> problems, but I have even used it to compile packages for a broken
> gentoo install _on the same machine_ without restarting ... :-)

  been there, done that.  I've changed glibc like that on a box.  this
  is neither a problem or a solution to what I'm looking at doing
  though.
 
> Happy hacking,

  always.  :-)

-- 
Terje

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [gentoo-dev] using Portage with other distributions.
       [not found]                 ` <1058439429.2138.13.camel@localhost>
@ 2003-07-17 23:11                   ` Terje Kvernes
  2003-07-18  0:53                     ` Terje Kvernes
  2003-07-19 11:41                     ` Chris Smith
  0 siblings, 2 replies; 5+ messages in thread
From: Terje Kvernes @ 2003-07-17 23:11 UTC (permalink / raw
  To: Patrick Lauer; +Cc: gentoo-dev

  (I noticed the lack of gentoo-dev@gentoo.org 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@toso-digitals.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@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [gentoo-dev] using Portage with other distributions.
  2003-07-17 23:11                   ` Terje Kvernes
@ 2003-07-18  0:53                     ` Terje Kvernes
  2003-07-19 11:41                     ` Chris Smith
  1 sibling, 0 replies; 5+ messages in thread
From: Terje Kvernes @ 2003-07-18  0:53 UTC (permalink / raw
  To: Patrick Lauer; +Cc: gentoo-dev

Terje Kvernes <terjekv@math.uio.no> writes:

> (I noticed the lack of gentoo-dev@gentoo.org 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. :-)

  bah.  ignore me after 11pm.  my apologies, Gnus does magical stuff.

  [ ... ]

-- 
Terje

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [gentoo-dev] using Portage with other distributions.
  2003-07-17 23:11                   ` Terje Kvernes
  2003-07-18  0:53                     ` Terje Kvernes
@ 2003-07-19 11:41                     ` Chris Smith
  1 sibling, 0 replies; 5+ messages in thread
From: Chris Smith @ 2003-07-19 11:41 UTC (permalink / raw
  To: gentoo-dev

On Thursday 17 July 2003 23:11, Terje Kvernes wrote:
>   fair enough.  just avoid making any assumptions about that backend.
>   "assumptions is the mother of all fuckups".[1]

>   [1] spot the reference.

That would be Under Siege 2: Dark Territory :)

As quoted by the bad guy boss, Penn to his henchmen when he assumed that the 
hero, had been killed, when really he was hanging off the end of the train :D

[/OT]

Cheers,
Chris.


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-07-18 23:38 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-07-14 12:16 [gentoo-dev] using Portage with other distributions Terje Kvernes
     [not found] ` <1058168210.2166.6.camel@localhost>
2003-07-14 13:11   ` Terje Kvernes
     [not found]     ` <1058180419.2165.19.camel@localhost>
     [not found]       ` <wxxhe5o13ok.fsf@nommo.uio.no>
     [not found]         ` <1047905040.2258.7.camel@localhost>
     [not found]           ` <wxxn0fe9m47.fsf@nommo.uio.no>
     [not found]             ` <1058379469.8788.13.camel@localhost>
     [not found]               ` <wxxfzl56vh3.fsf@nommo.uio.no>
     [not found]                 ` <1058439429.2138.13.camel@localhost>
2003-07-17 23:11                   ` Terje Kvernes
2003-07-18  0:53                     ` Terje Kvernes
2003-07-19 11:41                     ` Chris Smith

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox