[gentoo-dev] Portage: good news and bad news

[gentoo-dev] Portage: good news and bad news

[Daniel Robbins]

Hi Devs:

Bad news: I found a significant bug in Portage 2.0.10 and earlier that
could cause masking to work improperly, particularly if a package has a
~ entry in the profile's packages file.

Good news: I've fixed the problem in Portage 2.0.11 by rewriting
portage.py's portdbapi xmatch() and visible() methods.  This has
resulted in a 44% speed-up in dependency calculations over Portage
2.0.10.  If you thought things were fast before...

More good news: I've improved repoman to differentiate between
user-visible ebuilds with bad dependencies and masked ebuilds with bad
dependencies.  When checking dependencies, user-visible ebuilds'
dependencies are only matched against user-visible ebuilds. But when
masked ebuilds are checked, deps are satisfied using *all* available
ebuilds.  This should eliminate virtually all false positives in the
repoman DEPEND and RDEPEND QA tests. Type "repoman --help" for more
information on these new changes.

Enjoy!

-- 
Daniel Robbins
Chief Architect, Gentoo Linux
http://www.gentoo.org

Re: [gentoo-dev] Portage: good news and bad news

[Terje Kvernes]

Daniel Robbins <drobbins@gentoo.org> writes:

> Bad news: I found a significant bug in Portage 2.0.10 and earlier
> that could cause masking to work improperly, particularly if a
> package has a ~ entry in the profile's packages file.

  ick.  this means users might have gotten masked packages
  installed?
 
> Good news: I've fixed the problem in Portage 2.0.11 by rewriting
> portage.py's portdbapi xmatch() and visible() methods.  This has
> resulted in a 44% speed-up in dependency calculations over Portage
> 2.0.10.  If you thought things were fast before...

  well, I've never really thought much about the time it takes to do
  dependency calculations.  there are other issues I'd rather look at.
 
> More good news: I've improved repoman to differentiate between
> user-visible ebuilds with bad dependencies and masked ebuilds with
> bad dependencies.  When checking dependencies, user-visible ebuilds'
> dependencies are only matched against user-visible ebuilds. But when
> masked ebuilds are checked, deps are satisfied using *all* available
> ebuilds.  This should eliminate virtually all false positives in the
> repoman DEPEND and RDEPEND QA tests. Type "repoman --help" for more
> information on these new changes.

  hm. I haven't seen repoman before, seems nice.  also, somone[tm]
  introduced the "mirror://sourceforge"-syntax.  when was this done?

  I am trying to contribute ebuilds and fiddle with portage, but there
  doesn't seem to be to much information about internal changes coming
  down from gentoo-core.  I've been trying to get the internals of
  portage into my head, but changes happen and I'm not totally sure
  what ends those changes are about, hence it is difficult to really
  contribute.

  and I can't really subscribe to gentoo-core now, can I?  :-)

-- 
Terje

Re: [gentoo-dev] Portage: good news and bad news

[Chad M. Huneycutt]

Terje Kvernes wrote:
>   hm. I haven't seen repoman before, seems nice.  also, somone[tm]
>   introduced the "mirror://sourceforge"-syntax.  when was this done?

It has been in since around May.  I think when sourceforge changed all 
their URL's for http downloads, drobbins threw it in to address that. 
There is a file /usr/portage/thirdpartymirrors where you can set up 
other mirrors.

> 
>   I am trying to contribute ebuilds and fiddle with portage, but there
>   doesn't seem to be to much information about internal changes coming
>   down from gentoo-core.  I've been trying to get the internals of
>   portage into my head, but changes happen and I'm not totally sure
>   what ends those changes are about, hence it is difficult to really
>   contribute.

Daniel does most of the portage hacking, and he does quite a lot.  He 
has been making some major tweaks with the code lately (if you hadn't 
noticed), and he does keep track of the major changes in the portage 
Changelog.  Well, it looks like you have to look in the gentoo-src tree 
to see the "real" portage Changelog.  If you don't want to check it out 
of CVS, you can look at it here:

http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-src/portage/

As to gentoo-core, we are working on defining exactly what should and 
should not go on there.  It is mainly developer introductions and 
pre-discussions about various issues that will either be shot down or 
opened up to gentoo-dev once they have matured a little.

Chad (chadh@gentoo.org)

Re: [gentoo-dev] Portage: good news and bad news

[Paul de Vrieze]

On 7 Jul 2002, Daniel Robbins wrote:

> Hi Devs:
>
> Bad news: I found a significant bug in Portage 2.0.10 and earlier that
> could cause masking to work improperly, particularly if a package has a
> ~ entry in the profile's packages file.
>
> Good news: I've fixed the problem in Portage 2.0.11 by rewriting
> portage.py's portdbapi xmatch() and visible() methods.  This has
> resulted in a 44% speed-up in dependency calculations over Portage
> 2.0.10.  If you thought things were fast before...
>
> More good news: I've improved repoman to differentiate between
> user-visible ebuilds with bad dependencies and masked ebuilds with bad
> dependencies.  When checking dependencies, user-visible ebuilds'
> dependencies are only matched against user-visible ebuilds. But when
> masked ebuilds are checked, deps are satisfied using *all* available
> ebuilds.  This should eliminate virtually all false positives in the
> repoman DEPEND and RDEPEND QA tests. Type "repoman --help" for more
> information on these new changes.
>
> Enjoy!
>

I still cannot get the new portage when I sync.

Does someone have the same problem?

Paul

Re: [gentoo-dev] Portage: good news and bad news

[Marko Mikulicic]

Paul de Vrieze wrote:
 > On 7 Jul 2002, Daniel Robbins wrote:

 >
 > I still cannot get the new portage when I sync.
 >
 > Does someone have the same problem?

yes

Marko

Re: [gentoo-dev] Portage: good news and bad news

[Terje Kvernes]

"Chad M. Huneycutt" <chad.huneycutt@acm.org> writes:

> Terje Kvernes wrote:
>
> > hm. I haven't seen repoman before, seems nice.  also, somone[tm]
> > introduced the "mirror://sourceforge"-syntax.  when was this done?
> 
> It has been in since around May.  I think when sourceforge changed
> all their URL's for http downloads, drobbins threw it in to address
> that. 

  that makes sense.  it was just that I haven't seen an announcement
  on the topic.  it might be me though.  ;-)

> There is a file /usr/portage/thirdpartymirrors where you can set up
> other mirrors.

  ITYM /usr/portage/profiles/thirdpartymirrors.  but thanks for the
  pointer.  it was a rather cute detail though, even if some of my
  ebuilds broke.  no, they're not submitted.  I'm still having issues
  with ggz-kde-stuff.  this time it's sandbox-related.  more sed to
  come it seems.  *sigh*
 
> > I am trying to contribute ebuilds and fiddle with portage, but
> > there doesn't seem to be to much information about internal
> > changes coming down from gentoo-core.  I've been trying to get the
> > internals of portage into my head, but changes happen and I'm not
> > totally sure what ends those changes are about, hence it is
> > difficult to really contribute.
> 
> Daniel does most of the portage hacking, and he does quite a lot.
> He has been making some major tweaks with the code lately (if you
> hadn't noticed), 

  I've noticed.  it has effectively kept me from doing anything with
  portage for a while.  sadly enough.  I'd like to see where the
  stability levels are going, also I really miss a reason for ebuild
  updates in the ebuild itself.  but I've ranted about this before,
  and noone seems to care.

> and he does keep track of the major changes in the portage
> Changelog.  

  my problem with portage right now is that I want to understand the
  code and the intent of the code.  I'm going to try again to produce
  a map of portage to see what really happens.  documentation with
  regards to the development of portage isn't the best thing about
  it.  but of course, it's better to have a fix, then to document the
  problem.  

> Well, it looks like you have to look in the gentoo-src tree to see
> the "real" portage Changelog.  If you don't want to check it out of
> CVS, you can look at it here:
>
> http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-src/portage/

  thanks.  I was sort of more hoping for some abstracts of portage
  itself.  how does things get called, why, what modules exist for
  what reason etc.  maybe I'll try producing something like that for
  myself as I dig in the code.
 
> As to gentoo-core, we are working on defining exactly what should
> and should not go on there.  It is mainly developer introductions
> and pre-discussions about various issues that will either be shot
> down or opened up to gentoo-dev once they have matured a little.

  my apologies, I'm just the curious guy with a bit too much time on
  my hands now and then.  things are obviously happening.  I just feel
  that now and then it comes as an "this is now done"-announcement,
  before anyone outside the core team knew about the start of the
  project.  for good or bad.  ;-)

  but please, don't take this as a criticism of the way Gentoo is
  being run.  I'm just very scared by some ideas that have come around
  -- like separate portage trees for stable / unstable release.

  the way one implements stability levels is something I care a good
  deal about, because I really don't want Gentoo to become
  "debian-by-source".  we can do so much better.

  I've ranted about my views on stability levels and ebuild update
  comments on this list before, so I'll leave it at that.  if anyone
  wants another recap I'll be happy to produce it whatever media is
  desired.

-- 
Terje - a very happy, but slightly worried, Gentooer.

Re: [gentoo-dev] Portage: good news and bad news

[Rigo]

After updating portage to 2.0.11 I seem to get more errors that before
Daniel ;-)...

Info:

lappy distfiles # emerge --update world
Calculating world dependencies ...done!
>>> emerge media-libs/jpeg-mmx-1.1.2-r1 to /
!!! No message digest found for .
!!! Type "ebuild foo.ebuild digest" to generate a digest.
!!! emerge aborting on 
/usr/portage/media-libs/jpeg-mmx/jpeg-mmx-1.1.2-r1.ebuild .

lappy distfiles # ebuild
/usr/portage/media-libs/jpeg-mmx/jpeg-mmx-1.1.2-r1.ebuild digest

>>> Generating digest file...
Traceback (most recent call last):
  File "/usr/sbin/ebuild", line 33, in ?
    a=portage.doebuild(pargs[0],x,getroot(),debug=debug)
  File "/usr/lib/python2.2/site-packages/portage.py", line 1130, in
doebuild
    digestgen(checkme,overwrite=1)
  File "/usr/lib/python2.2/site-packages/portage.py", line 955, in
digestgen
    mymd5=perform_md5(myfile)
  File "/usr/lib/python2.2/site-packages/portage.py", line 1368, in
perform_md5
    return perform_checksum(x)[0]
  File "/usr/lib/python2.2/site-packages/portage.py", line 39, in
perform_checksum
    return fchksum.fmd5t(filename)
IOError: [Errno 21] Is a directory: '/usr/portage/distfiles/'


Regards, Rigo


Op zo 07-07-2002, om 06:38 schreef Daniel Robbins:
> Hi Devs:
> 
> Bad news: I found a significant bug in Portage 2.0.10 and earlier that
> could cause masking to work improperly, particularly if a package has
a
> ~ entry in the profile's packages file.
> 
> Good news: I've fixed the problem in Portage 2.0.11 by rewriting
> portage.py's portdbapi xmatch() and visible() methods.  This has
> resulted in a 44% speed-up in dependency calculations over Portage
> 2.0.10.  If you thought things were fast before...
> 
> More good news: I've improved repoman to differentiate between
> user-visible ebuilds with bad dependencies and masked ebuilds with bad
> dependencies.  When checking dependencies, user-visible ebuilds'
> dependencies are only matched against user-visible ebuilds. But when
> masked ebuilds are checked, deps are satisfied using *all* available
> ebuilds.  This should eliminate virtually all false positives in the
> repoman DEPEND and RDEPEND QA tests. Type "repoman --help" for more
> information on these new changes.
> 
> Enjoy!
> 
> -- 
> Daniel Robbins
> Chief Architect, Gentoo Linux
> http://www.gentoo.org
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev