Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-15 Thread Zac Medico
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Harring wrote:
 On Sat, Apr 15, 2006 at 11:01:56AM +0900, Jason Stubbs wrote:
 On Saturday 15 April 2006 03:31, Brian Harring wrote:
 cache backend selection (failed import == defaults to sys default)
 This is incorrect. It displays an error message and quits.
 Still leaves the other features then (and raises the question that 
 it's not internally totally standard)...
 
 Either way, standard for it is preferable (again, prefer failures 
 myself, but I'm not a normal user)...

We could make it an optional feature, for example, users could add -autoadapt 
to FEATURES if they want portage to exit instead of autoadapt.

Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEQJzk/ejvha5XGaMRAsk5AJ9nUlpGuLxJHahhtuBqml56kNUg3QCfS+HE
jtwyY9k2x8LEUlwN1LbvR4w=
=HQd5
-END PGP SIGNATURE-
-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-14 Thread Philipp Riegger

On Apr 7, 2006, at 5:26 PM, Alec Warner wrote:

We have a new cache format, confcache, parallel fetch, etc... The  
bonus
is these features are already mature and relatively old ( a year +  
as of

now ).


Reading about confcache i have one question:

When i saw, that this feature exists (in make.examples) i activated  
it. But it did not work because i had not emerged confcache. I think  
this check should be stricter, if i want confcache and have  
FEATURES=confcache and confcache is not emerged, i think  
emerge ...  should die, not just say Ok, you said you want it but  
you don't have it, so i don't use it. What do you think about that?


Philipp
--
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-14 Thread Brian Harring
On Fri, Apr 14, 2006 at 05:15:53PM +0200, Philipp Riegger wrote:
 On Apr 7, 2006, at 5:26 PM, Alec Warner wrote:
 
 We have a new cache format, confcache, parallel fetch, etc... The  
 bonus
 is these features are already mature and relatively old ( a year +  
 as of
 now ).
 
 Reading about confcache i have one question:
 
 When i saw, that this feature exists (in make.examples) i activated  
 it. But it did not work because i had not emerged confcache. I think  
 this check should be stricter, if i want confcache and have  
 FEATURES=confcache and confcache is not emerged, i think  
 emerge ...  should die, not just say Ok, you said you want it but  
 you don't have it, so i don't use it. What do you think about that?

Precedent is against you in this case...sandbox is the same way 
(notify instead of bailing).

Personally I prefer the if I told you to do something, bail if you 
can't approach, but for features portage has usually done the 
opposite.
~harring


pgpZNDBdMy8pf.pgp
Description: PGP signature


Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-14 Thread Alec Warner

Brian Harring wrote:

On Fri, Apr 14, 2006 at 05:15:53PM +0200, Philipp Riegger wrote:


On Apr 7, 2006, at 5:26 PM, Alec Warner wrote:


We have a new cache format, confcache, parallel fetch, etc... The  
bonus
is these features are already mature and relatively old ( a year +  
as of

now ).


Reading about confcache i have one question:

When i saw, that this feature exists (in make.examples) i activated  
it. But it did not work because i had not emerged confcache. I think  
this check should be stricter, if i want confcache and have  
FEATURES=confcache and confcache is not emerged, i think  
emerge ...  should die, not just say Ok, you said you want it but  
you don't have it, so i don't use it. What do you think about that?



Precedent is against you in this case...sandbox is the same way 
(notify instead of bailing).


Personally I prefer the if I told you to do something, bail if you 
can't approach, but for features portage has usually done the 
opposite.

~harring


Meh, past behavior is not really a great excuse here.  If the majority 
thinks it sucks, then it can always be changed.


-Alec

--
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-14 Thread Brian Harring
On Fri, Apr 14, 2006 at 02:10:27PM -0400, Alec Warner wrote:
 Brian Harring wrote:
 it. But it did not work because i had not emerged confcache. I think  
 this check should be stricter, if i want confcache and have  
 FEATURES=confcache and confcache is not emerged, i think  
 emerge ...  should die, not just say Ok, you said you want it but  
 you don't have it, so i don't use it. What do you think about that?
 
 Precedent is against you in this case...sandbox is the same way 
 (notify instead of bailing).
 
 Personally I prefer the if I told you to do something, bail if you 
 can't approach, but for features portage has usually done the 
 opposite.
 ~harring
 
 Meh, past behavior is not really a great excuse here.  If the majority 
 thinks it sucks, then it can always be changed.

The I'm going to help you out approach is in use in (quick look 
through)

cache backend selection (failed import == defaults to sys default)
PORT_LOGDIR
ccache
distcc
sandbox/usersandbox
PORTDIR_OVERLAY (disables non existant directories)
parallel-fetch (disables if distlocks isn't on)
gpg feature

Basically... all existing features that are optional disable 
themselves if they don't work (exemption being 
strict/stricter/servere, since not applicable to them).

What I'm saying is be consistant- I say the existing standard sucks, 
but going willy/nilly per feature isn't good for users.


Sidenote, why is userfetch a feature?  That seems like something that 
should be userpriv by default to me...
~harring


pgpEPF8Bvc20f.pgp
Description: PGP signature


Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-14 Thread Jason Stubbs
On Saturday 15 April 2006 03:31, Brian Harring wrote:
 Sidenote, why is userfetch a feature?  That seems like something that 
 should be userpriv by default to me...

It broke somebody's ftp setup.

http://bugs.gentoo.org/show_bug.cgi?id=92960

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-14 Thread Jason Stubbs
s/ftp/nfs/ in the mail that I just sent.

--
Jason Stubbsw
-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-14 Thread Jason Stubbs
On Saturday 15 April 2006 03:31, Brian Harring wrote:
 cache backend selection (failed import == defaults to sys default)

This is incorrect. It displays an error message and quits.

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-14 Thread Brian Harring
On Sat, Apr 15, 2006 at 11:01:56AM +0900, Jason Stubbs wrote:
 On Saturday 15 April 2006 03:31, Brian Harring wrote:
  cache backend selection (failed import == defaults to sys default)
 
 This is incorrect. It displays an error message and quits.
Still leaves the other features then (and raises the question that 
it's not internally totally standard)...

Either way, standard for it is preferable (again, prefer failures 
myself, but I'm not a normal user)...
~harring


pgpEc8sZvtMRn.pgp
Description: PGP signature


Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-10 Thread Jason Stubbs
On Saturday 08 April 2006 21:48, Ned Ludd wrote:
 On Sat, 2006-04-08 at 11:18 +0900, Jason Stubbs wrote:
  On Saturday 08 April 2006 07:36, Ned Ludd wrote:
   On Fri, 2006-04-07 at 14:19 -0400, solar wrote:
FEATURES=buildpkg ROOT=/ emerge gcc
rm -rf /dev/shm/foo

ROOT=/dev/shm/foo emerge gcc -pvK

Notice how it selects the incorrect deps? 
IE: eselect cuz it's the first listed dep in the || ( ) vs the
gcc-config
   
   + When you already have a copy of gcc-config installed on / and in 
   .tbz2 format in ${PKGDIR}/All and no eselect anywhere.
  
  This should work. I believed I had fixed it by adding the use_binaries
  parameter and code paths to dep_zapdeps. If it's not working then there must
  be a bug left somewhere.
 
 Must be a bug left somewhere then. I just tested with 
 Portage 2.1_pre7-r4 and the result is the same.

Got it. The bug was in bindbapi. For consistency's sake, I changed most of the
db[/] to db[myroot] except where db[/] is specifically required. However,
db[myroot][bintree].dbapi.* were all working with an empty repository as
bintree holds all the data and uses lazy initialization which bindbapi wasn't
triggering.

I've fixed the current use case and covered aux_get as well, but this bug could
easily come back if another method of bindbapi is used.

  Having a quick look at the dep_zapdeps function, I can't see what but I 
  think
  I've discovered another bug. If use_binaries is true, porttree isn't checked
  for matches which means that it'll fall through to the last resort code
  when there's no matching binaries which could end up selecting an atom that
  only has masked porttree matches.
 
 yikes.

This is and isn't the case. use_binaries is only enabled with -K so masking
doesn't take affect anyway.

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-08 Thread Donnie Berkholz
Zac Medico wrote:
 Well, please file a bug then.  How are we supposed to fix bugs that we aren't 
 aware of? :)

With the portage regression test suite, of course. =)

Donnie



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-07 Thread Ned Ludd
On Thu, 2006-04-06 at 13:13 -0700, Zac Medico wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi everyone,
 
 I think the current quality level of the 2.1 branch is good enough to make it 
 a release candidate.  From my perspective, it seems like a waste of 
 everyone's time to roll a 2.0.55 release when 2.1 is a perfectly good 
 replacement (with lots of bug fixes relative to 2.0.54).
 
 I know there are probably some additional features that people would like to 
 get into 2.1 before we make this transition.  Despite this, I think that it's 
 in everyone's best interest to retire the the 2.0.x branch as soon as 
 possible so that it doesn't waste people's time.  This transition doesn't 
 necessarily mean that it's going to be a long time before some desired 
 feature X is available in the stable version of portage.  The next release 
 after 2.1 (2.2 or whatever) doesn't necessarily have to be too far off in the 
 future.
 
 So, I'd like to create 2.1 branch that is closed to mostly anything except 
 regression fixes and release it as portage-2.1_rc1 this Saturday.  We can 
 continue to do ~arch releases of the development branch (2.2 or whatever it 
 becomes) every 2 weeks.  Does now seem like a good time for this transition?  
 Your feedback would be appreciated.

If this has been repeated elsewhere than sorry for the re-post.

The resolver still needs a bit of work before it's ready.

Handling of the || () in ROOT!=/ via the -K option is not in that 
good of shape in 2.1_NXX and can't really be used. Till that's 
addressed 2.1(re-ping jason) in my eyes absolutely should 
not even be considered for any rc status.

Other than that I'm quite pleased with many aspects of 2.1


-- 
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux

-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-07 Thread Alec Warner
Zac Medico wrote:
 
 
 This kind of thing will be less of a problem if we shorten the period of the 
 release cycle.  If we shorted it to 2 months or so, then it won't matter much 
 when something gets bumped to the next cycle.
 
 
Also this isn't exactly news to you all as I sent my intentions already
a while ago, and last I asked you all agreed with them, so is there any
reason to rush this now?
 
 
 Like I've said above, I'm annoyed by the length of this release cycle.  The 
 gap between 2.0.x and 2.1 has grown so large that a 2.0.55 release seems (in 
 my mind) like beating a dead horse.  The way I see it, a shorter release 
 cycle is needed so that bug fixes are released in _stable_ versions sooner.
 
 Zac

See my problem is that some of the features proposed aren't two month
testing features.  Particularly when you rewrite decent portions of the
application you need longer than two months to get decent testing
coverage.  Sure Unit Tests are helpful for that too, but they don't
cover all cases and really the best testing platform is to let the
people who play with portage do the testing and get some real results
prior to release.  The great thing about 2.1 is that *everyone* uses it.
 Of course they use it because it's better, which may not necessary be
the case for future versions.

We have a new cache format, confcache, parallel fetch, etc... The bonus
is these features are already mature and relatively old ( a year + as of
now ).

-Alec
-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-07 Thread solar
On Fri, 2006-04-07 at 21:06 +0900, Jason Stubbs wrote:
 On Friday 07 April 2006 20:54, Ned Ludd wrote:
  Handling of the || () in ROOT!=/ via the -K option is not in that 
  good of shape in 2.1_NXX and can't really be used. Till that's 
  addressed 2.1(re-ping jason) in my eyes absolutely should 
  not even be considered for any rc status.
 
 Can you refresh my memory on what the issue is here?

Example off the topof my head:

FEATURES=buildpkg ROOT=/ emerge gcc
rm -rf /dev/shm/foo

ROOT=/dev/shm/foo emerge gcc -pvK

Notice how it selects the incorrect deps? 
IE: eselect cuz it's the first listed dep in the || ( ) vs the
gcc-config

I forget what the title of the subject was but I recall us 
talking about it a bit on the portage alias a month or two ago and you 
more or less stated it's not broken at this point it's just not been 
coded to handle such cases yet. Other ppl who do alot of work with
either || () / $ROOT such as Donnie or Alec should also be 
able to give some insights also.



-- 
solar [EMAIL PROTECTED]
Gentoo Linux

-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-07 Thread Zac Medico
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alec Warner wrote:
 See my problem is that some of the features proposed aren't two month
 testing features.  Particularly when you rewrite decent portions of the
 application you need longer than two months to get decent testing
 coverage.  Sure Unit Tests are helpful for that too, but they don't
 cover all cases and really the best testing platform is to let the
 people who play with portage do the testing and get some real results
 prior to release.

Sure, it's possible that a two month release cycle might not be possible to 
achieve in some cases due to the nature of the changes that have occurred.  
However, that's not to say that it's never possible.  Furthermore, we can be 
selective about the changes that are integrated during a particular release 
cycle, and changes that require disproportionate amounts of testing can be 
bumped from the current release cycle (for later integration, at a time that 
does not interfere with the release of well tested features).

Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFENt9n/ejvha5XGaMRAhY6AJ4nMLOkpQ+lmjpoEGPHJlgPjJXQoACg4REK
lXvWWC3BLk/ttplyCd2BjDg=
=xk4t
-END PGP SIGNATURE-
-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-07 Thread Ned Ludd
On Fri, 2006-04-07 at 14:19 -0400, solar wrote:
 On Fri, 2006-04-07 at 21:06 +0900, Jason Stubbs wrote:
  On Friday 07 April 2006 20:54, Ned Ludd wrote:
   Handling of the || () in ROOT!=/ via the -K option is not in that 
   good of shape in 2.1_NXX and can't really be used. Till that's 
   addressed 2.1(re-ping jason) in my eyes absolutely should 
   not even be considered for any rc status.
  
  Can you refresh my memory on what the issue is here?
 
 Example off the top of my head:
 
 FEATURES=buildpkg ROOT=/ emerge gcc
 rm -rf /dev/shm/foo
 
 ROOT=/dev/shm/foo emerge gcc -pvK
 
 Notice how it selects the incorrect deps? 
 IE: eselect cuz it's the first listed dep in the || ( ) vs the
 gcc-config

+ When you already have a copy of gcc-config installed on / and in 
.tbz2 format in ${PKGDIR}/All and no eselect anywhere.

Depstring: || ( app-admin/eselect-compiler
=sys-devel/gcc-config-1.3.12-r4 ) ...

Candidates: ['app-admin/eselect-compiler', '=sys-libs/ncurses-5.2-r2']

Then compare with 
ROOT=/dev/shm/foo emerge -pvk gcc


-- 
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux

-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] 2.1 release candidate soon?

2006-04-06 Thread Marius Mauch
On Thu, 06 Apr 2006 19:11:49 -0700
Zac Medico [EMAIL PROTECTED] wrote:

 The manifest code doesn't have very many use cases so I'd expect that
 we would have hit most major problems by now (even with a small
 sample).  Any necessary changes are likely to be small patches.  As
 an alternative, we can cut the 2.1 branch at the point before
 manifest2 was merged (2.1_pre7, essentially).

Releasing 2.1 without manifest2 is a no go, it would significantly
delay the deployment and transition. I'm not requesting to delay 2.1
for another few months, just one more pre release so people get a
chance to test it for one or two weeks.

  The remaining feature I'd like to get into 2.1 is the
  tree-format-check issue, but that could probably be slipped in in
  the rc phase (don't really like that idea, but it's an option).
 
 I don't want to rush the development of new features such as
 manifest2 or the tree-format-check.  We have a 2.1 branch that, in
 it's current state (2.1_pre7-r4, for example), provides significant
 benefits over the 2.0.x branch.  By delaying 2.1's release for the
 addition of _new_ features, we run the risk of the release being
 delayed indefinitely by just one more feature syndrome.
 Personally, I'd rather have shorter release periods so that just one
 more feature syndrome becomes less of an issue.

Ehm, this is not just one more feature, both manifest2 and
the tree-format-check are things to improve forward compability (or for
the latter even enable forward compability at all), so delaying them
will hinder future development, not only for us.
Also this isn't exactly news to you all as I sent my intentions already
a while ago, and last I asked you all agreed with them, so is there any
reason to rush this now?

Marius
-- 
gentoo-portage-dev@gentoo.org mailing list



[Fwd: Re: [gentoo-portage-dev] 2.1 release candidate soon?]

2006-04-06 Thread Alec Warner

Sorry, send with wrong address earlier.


 Original Message 
Subject: Re: [gentoo-portage-dev] 2.1 release candidate soon?
Date: Thu, 06 Apr 2006 20:09:06 -0400
From: Alec Warner [EMAIL PROTECTED]
To: gentoo-portage-dev@lists.gentoo.org
References: [EMAIL PROTECTED]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 Hi everyone,

 I think the current quality level of the 2.1 branch is good enough to
 make it a release candidate.  From my perspective, it seems like a
 waste of everyone's time to roll a 2.0.55 release when 2.1 is a
 perfectly good replacement (with lots of bug fixes relative to
 2.0.54).

(Pardon if this looks weird, Thunderbird is doing all kinds of weird
things to this E-mail)

Vapier in particular has backported some changes into the 2.0.54 tree
with I assume hopes to make a 2.0.55 release.  The 2.1 release is a
large change over the 2.0 series, I'd like to give people a bit more
time on 2.0.  For a while this may mean 2.0 and 2.1 stable at the same
time, although there is no harm in that either.  We haven't had a new
2.0 release in a while, and there are features worth backporting IMHO.

Remember that while most of the development community runs portage-2.1
many of the users do not; and they have not seen a 2.0 release in some
time.  I think we can stable 2.0.55 faster than 2.1, as 2.1 will
probably need a series of _rc releases before being considered stable.

-Alec Warner (antarus)

-- 
gentoo-portage-dev@gentoo.org mailing list