public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Brian Harring <ferringb@gentoo.org>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] Questions about CVS locations and GID...
Date: Wed, 5 Oct 2005 16:10:51 -0500	[thread overview]
Message-ID: <20051005211050.GD10159@nightcrawler> (raw)
In-Reply-To: <e36b84ee0510051348j10bbad50k7aa785498806cc9@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4502 bytes --]

On Wed, Oct 05, 2005 at 01:48:03PM -0700, m h wrote:
> On 10/5/05, Brian Harring <ferringb@gentoo.org> wrote:
> > Yay, time for another flame war (just what I'd love to spend my time
> > on).
> 
> Sorry, I'm really not trying to kindle any flames here.
Heh, you're not, I'm just mildly pissy due to recurrent flamewars :)

> So, on the topic of rewrite.  Does there happen to be any testcases
> for portage?  Unittests, etc?  I'd be nice to verify that rewrite
> behaves properly (well, actually I want testcases for selfish reasons,
> so I don't break code if I change anything....)
Niadda.

Would love it if someone stepped up on that, since I don't 
particularly have the time right now :)


> > The current line of thought on it is global prefix going in as an addition
> > to an EAPI release, _strictly_ global prefix.  The home crap (interdomain
> > deps, querying information/location of package X) being a later release.
> >
> 
> Sorry, I don't know what EAPI means....
Ebuild API.
Stable portage's ebuild env, funcs available, etc, is EAPI=0.

Think of it as specifying the lib you want; the ebuild.sh specific 
changes that will be in the rewrite (elib, src_configure phase 
addition, deprived setup phase) would be EAPI=1

Basically, it gives us a way to introduce changes for how ebuilds are 
called/executed, what they expect from the env, without breaking 
things.  It also gives us a way to break compatibility between EAPI 
versions; as long as the metadata exported is correct for the ebuild's 
EAPI and we're still doing a declarative design for calling into the 
ebuild, we can basically do whatever we want.

> > Do 'em seperate.  Those who want interdomain, they can do the work.
> > Those who want global offset, they can do that chunk.
> 
> I understand the interdomain stuff to be that prefixed packages can
> depend on packages outside of their prefix?  If so, I don't want this
> "feature".  I want an isolated sandbox.  (Again, I realize others have
> different needs)
Pretty much.  Best description is dependencies between root's.
Global prefix (for osx) would either
A) have a vdb for that prefix that represented the package.provided 
   nodes
B) have a domain for root=/, and do interdomain.

A is likely route due to it being a helluva lot simpler; B is 
better/cleaner (imo), but it requires more work.

Baby steps. :)

> > To head off the "it's not going to work for vim-*", yah, you'll be
> > boned and have to install duplicate vim-* into the global prefix.
> > Bluntly, either you dive in and start wading through the problems
> > (fixing them as you go), or you sit back listening to how it's never
> > going to work (thus accomplishing nothing).
> > ~harring
> >
> 
> So, I figure I'm sortof diving in with Haubi's code (against the
> advice of those wanted a complete spec) since I think my needs seem to
> be the most minimum subset of what others want in this feature.  I
> think it's a good way to help me understand the innards of portage
> (though the code is pretty spaghetti right now).  I presume you think
> I should start with "rewrite" as a base?  What is the current status
> of rewrite?
Rewrite's code is a heck of a lot cleaner; oop based for starters :)
There is some nastyness, but it's encapsulated, and pretty much 
required.

Current state of it is that I'm atm stuck on plugin code, and a slight 
change to the config handling code.

Building/fetching are done, full immutable ebuild tree and vdb are 
done, immutable binpkg repository is done sans a package class.

The mutable thing is basically querying the db; for vdb and binpkg, 
they need to be modifiable, able to add a package to the repository 
(merging).  I'm working on that atm.

Jason's doing resolver work, state of that I can't comment on (that's 
his thing).

ebuild*sh side of it's already done- if you were looking to test out 
prefix building (experiment) I'd probably start there.


> Sorry for all the questions, again I'm not looking to start a flame
> war, I'm looking for some features and like what gentoo has done and
> what can be done with it.  I'm not trying to work against or outside
> what the mainline developers are doing....

Wouldn't worry about it, my initial response was phrased strongly due 
to the fact whenever implementing global prefix is brought up the 
screams against it start prior to even being able to iron out, or 
discuss it.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2005-10-05 21:11 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-05 18:35 [gentoo-portage-dev] Questions about CVS locations and GID m h
2005-10-05 19:54 ` Ciaran McCreesh
2005-10-05 20:06 ` Alec Joseph Warner
2005-10-05 20:18   ` m h
2005-10-05 20:25     ` Alec Joseph Warner
2005-10-05 20:24   ` Brian Harring
2005-10-05 20:48     ` m h
2005-10-05 21:10       ` Brian Harring [this message]
2005-10-05 21:52         ` m h
2005-10-05 22:02           ` Brian Harring
2005-10-05 23:01             ` m h
2005-10-05 23:10               ` Brian Harring
2005-10-05 20:57     ` Ciaran McCreesh
2005-10-05 21:13       ` Brian Harring
2005-10-05 22:31         ` Ciaran McCreesh
2005-10-05 23:00           ` Brian Harring
2005-10-05 23:14             ` Ciaran McCreesh
2005-10-05 23:22               ` Brian Harring
2005-10-05 23:38                 ` Ciaran McCreesh
2005-10-05 23:40                   ` Brian Harring
2005-10-06  0:13                     ` Ciaran McCreesh
2005-10-06  1:01                       ` Brian Harring
2005-10-06  1:07                         ` Ciaran McCreesh
2005-10-06  1:17                           ` Brian Harring
2005-10-06  1:23                             ` Ciaran McCreesh
2005-10-06  1:32                               ` Brian Harring
2005-10-06  1:40                                 ` Ciaran McCreesh
2005-10-06  1:48                                   ` Brian Harring
2005-10-06  2:01                                     ` Ciaran McCreesh
2005-10-06  2:39                                       ` Brian Harring
2005-10-06 11:51                                         ` Ciaran McCreesh
2005-10-06 12:08                                           ` Jason Stubbs
2005-10-06 13:07                                           ` Alec Warner
2005-10-06 18:29                                             ` Ciaran McCreesh
2005-10-06 18:42                                               ` Brian Harring
2005-10-06 19:11                                                 ` Ciaran McCreesh
2005-10-06  1:56                       ` Kito
2005-10-06  2:02                         ` Ciaran McCreesh
2005-10-06  2:11                           ` Kito
2005-10-05 23:27             ` Alec Warner
2005-10-05 23:38               ` m h
2005-10-05 23:46                 ` Alec Warner
2005-10-05 21:16       ` Kito
2005-10-05 21:34         ` Brian Harring
2005-10-05 22:29         ` Ciaran McCreesh
2005-10-05 22:53           ` Brian Harring
2005-10-05 23:03             ` Ciaran McCreesh
2005-10-05 23:21               ` Brian Harring
2005-10-06  4:14         ` Finn Thain
2005-10-06  4:22           ` Brian Harring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051005211050.GD10159@nightcrawler \
    --to=ferringb@gentoo.org \
    --cc=gentoo-portage-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox