Re: [gentoo-dev] Gentoo's problems

2007-03-16 Thread Jason Stubbs
On Friday 16 March 2007 18:58, Luca Barbato wrote:
 Jason Stubbs wrote:
  That's not entirely true. The main trouble with refactoring portage code
  is that there is no defined public API and so even the littlest changes
  are likely to break things in gentoolkit and several of the portage gui
  front end packages.

 What about branching, doing the dirty stuff and let others fix their code?

I've worked on a branch in the past as has Brian and a lot of the code that
went into 2.1.0 was done in a seperate branch. However, a lot of bugs that got 
fixed in the release branch never got fixed in the development branches and 
so switching wasn't really viable. For 2.1.0, a lot of the work that was done 
ended up being completely redone in the release branch.

In hindsight, if the team had have worked together as a team on a dev branch 
and only critical bug fixes went into the release branch while the dev branch 
was being readied it would have worked. Proper coordination would be needed 
but I guess it still could...

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



Re: [gentoo-dev] Gentoo's problems

2007-03-15 Thread Jason Stubbs
On Friday 16 March 2007 02:47, Ciaran McCreesh wrote:
 On Thu, 15 Mar 2007 18:40:05 +0100 Jakob Buchgraber

 [EMAIL PROTECTED] wrote:
  So why don't you start rewriting, refactoring and improving the
  portage source? It definitely doesn't make sense to create a
  competing package management system.

 Because it's far simpler to start from scratch. Refactoring is only
 possible if the initial design is at least vaguely sane. With things as
 they are now, making a change is nigh on impossible because there's no
 way of evaluating the impact.

That's not entirely true. The main trouble with refactoring portage code is 
that there is no defined public API and so even the littlest changes are 
likely to break things in gentoolkit and several of the portage gui front end 
packages.

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



Re: [gentoo-dev] gentoo-dev vs lkml?

2007-03-15 Thread Jason Stubbs
Rearranging and snipping a bit to clarify my points.

On Friday 16 March 2007 09:17, Daniel Drake wrote:
 Jason Stubbs wrote:
  2) Each technical area usually has a clear authority - ie. a spokesman
  whom is listened to and usually has one's posts challenged with clear
  respect.

  1) There is a fairly clear chain of command.

[between those technical areas]

 I've seen a few people make this kind of comment recently, and I'm never
 sure whether they mean it as it sounds or not.

 What I think people mean to say is that for the major subsystems, there
 is a fairly clear structure to the technical contribution flow and the
 review process. But there is also a huge amount of code which is not
 'maintained' in this way, where the only realistic patch-target is
 Andrew Morton, the lead maintainer of the whole kernel.

This is exactly what I meant.

 But in my opinion this structure doesn't really relate to the flaming.

 I don't really understand how this relates to the question why linux
 kernel flamewars don't appear to harm the kernel community in the way
 that gentoo-dev flamewars appear to harm the Gentoo community.

Andrew Morton doesn't get involved in the flamewars. From what I've seen,
his responses are usually I don't understand why you are doing this so
please explain further, I think doing it this way would be better than
doing it that way and I need this, this and this before this patch can
move forward. I imagine things work mostly the same in the seperable 
subsystems too.

How does that relate to the difference in flamewar harm? I think that the
transparent workflow makes it easy to see that the flamewars have relatively 
little effect on the amount achieved. I also think that the workflow helps
assure users that the flamewars don't affect the end product other than to
perhaps delay some specific feature.

 Here are my thoughts, and I think there are several answers here:

snip about flamewars leading to uninformed press coverage
snip about flamewars being driven by people outside the community

Both very good points.

 I also feel that the community is more mature, in that people truly with
 a grasp on the community generally do not get involved with the heated
 discussions when they go beyond the point of technical review. By this I
 mean simply: people don't have the apparent urge to respond to mails in
 the way that people do here -- kernel developers don't seem to take bait
 from trolls.

This was what I was trying to get at in the 3rd point of my first email.
I probably shouldn't have lumped it under paid devs, eh? The urge to
respond problem is probably one of our biggest downfalls here. Not only
in taking flamebait though. It is also in replying to a thread that is not
really in one's domain - devs acting like users reading uninformed press 
coverage, if you will.

 In general threads also seem to stay on topic more than they do here as
 well. Steve Long's initial reply to the thread here didn't add anything
 to the discussion Grant was trying to start, and he even admitted so!
 I'd say on the LKML replies like this generally don't happen, or if they
 do, they get 0 responses.

Also part of the maturity point. Perhaps we all just need to grow up? ;)

 Another factor: think about the level of ratio of developers to users on
 both lists. Even if most posts here are by developers, there are a
 comparatively large number of non-developer readers, plus the
 discussions make good reading material linked from the GWN and forums etc.

 Now look at the LKML. It's often hard to find general discussion behind
 the truckloads of patches and river of technical review emails. A large
 proportion of the content is not understandable unless you have a good
 knowledge of C, operating systems, and the technical area in question.
 This isn't a place that users hang out, users dont really read it
 either, and you need to be a decent developer to get involved in the
 first place.

This is an important point that I hadn't considered. It kind of resembles
the affect of bad press coverage you mentioned earlier. I'm not sure that 
there's much that can be done about it though - at least not in the short 
term.

Perhaps a code of conduct should be created that discusses how one should 
behave rather than how one should not. Taking cues from member of LKML that
show maturity as well as other communities that do well, it could cover what
is expected in the situations where we are failing and extended as needed.
What do you think?

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



Re: [gentoo-dev] gentoo-dev vs lkml?

2007-03-14 Thread Jason Stubbs
On Thursday 15 March 2007 00:59, Grant Goodyear wrote:
 Underlying the draft code of conduct is an assumption that aggressive
 and less-than-nice behavior on gentoo-dev is seriously harming Gentoo.
 On the other hand, LKML is famous for its flamewars, and nobody claims
 that Linux is in serious trouble.  Does anybody have a good feeling for
 where the difference lies?

The main differences I see are:

1) There is a fairly clear chain of command.

2) Each technical area usually has a clear authority - ie. a spokesman whom is 
listened to and usually has one's posts challenged with clear respect.

3) Many contributors are paid to do it and thus have the time to spend 
isolating the technical merits of a post from the flames or, more 
importantly, time to develop a work ethic that allows that to do such 
separation habitually.

 Are we sure that we're solving the right problem?  (That's not a rhetorical 
 question; I really don't know the answer.) 

Good question. I wouldn't have a clue as to the best resolution either.

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



Re: [gentoo-dev] Some council topics for March meeting

2007-03-03 Thread Jason Stubbs
On Saturday 03 March 2007 23:14, Ciaran McCreesh wrote:
 On Sat, 3 Mar 2007 05:57:35 -0800 Brian Harring [EMAIL PROTECTED]

  Two angles on the behaviour BS; either related to the fact I'm dead
  set on the spec reflecting portage behaviour, and being finished, or
  it's related to the fact the paludis devs generally speaking would be
  the first group of folks lining up to kick me in the balls.

To Ciaran: even though my following statements could be considered retorts,
I'm not agreeing or disagreeing with the above.

 No, it's that you're dead set on derailing it and being as unhelpful as
 possible.

My experience with Brian has always been that he's genuinely intent on being
helpful. The issue, I would think, is that you find is manner (as illustrated
by the above quote) to be irritating. That leads to his intention of helping
to being unrealized.

For the record, I've found his manner irritating at times in the past as
 well, although arguments have always been limited to IRC.

 You have absolutely nothing to contribute,

As Alec mentioned, Brian definitely has a lot to offer in terms of knowledge.

 as evidenced by every previous time you've gotten involved with anything
 I've done, and given how badly you tried to screw up GLEP 42 and how much
 of my time you wasted doing so,

I'm not sure about other instances. There seems to be a lot that I didn't
see - perhaps on IRC? But if I recall the mailing list discussions correctly,
if anybody can be accused of trying to derail it that person would be me.
However, I wasn't trying to derail it. As with Brian and yourself above,
I found your manner to be irritating which led to my intent on being helpful
being unrealized.

It might be helpful to the current discussion of PMS so I'll go a little into
what I think went wrong there. You had an idea of how multiple repositories
would function as did myself and Brian (the two most active portage devs at
the time). These ideas were developed independently and neither were
implemented or even rfc'd.

There were two separate specifications - glep42 and multiple repositories -
that should have been discussed seperately. On a seperate thread, Marius said
something to the effect of specs are much easier to extend than to alter.
Having read that, I think we were both wrong - specification of a repository
should probably have been left out completely until repositories had been
hashed out.

To sidetrack just a little more, I think this illustrates one of the reasons
why having PMS (aka EAPI-0 spec) completed is so important. Not only would it
allow for Gentoo package manager(s) to be interchanged/replaced, it would
provide a incontrovertible context for discussion of new features.

 I really don't want to deal with your noise ever again.

I'll address this in my last retort.

 You also have a lot to gain by wrecking the process,

Quite the contrary. Brian is in exactly the same position as you - other than
having a representative of his project helping to prepare PMS (unless these
threads have misled me). Any loss you suffer from not having a complete
EAPI-0 specification is his loss too.

 and your past behaviour has shown that you'll stoop to any kind of dirty
 trickery and abuse of the system that you think you can get away with
 rather than having a proper technical discussion.

 Frame it any way you want, but so far as I'm concerned there is nothing
 of value you can possibly provide that would make up for the headache
 of having to handle your own unique form of input.

 But hey, it's up to spb, not me. Try emailing him if you want access. I
 couldn't give you svn access even if I wanted to.

This is really irrelevant. It's not matter of if he gets access but only as
to when. After the initial work is done and the team is ready to go public
all his noise will come out. I can only think of two choices here:
1) whether you and he both continue to be visceral or instead try to build a
   good working relationship; and
2) whether you discuess any issues with the spec now or when it goes public.

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



Re: [gentoo-dev] Some council topics for March meeting

2007-03-03 Thread Jason Stubbs
On Sunday 04 March 2007 02:05, Ciaran McCreesh wrote:
 On Sun, 4 Mar 2007 01:51:39 +0900 Jason Stubbs [EMAIL PROTECTED]

 wrote:
  There were two separate specifications - glep42 and multiple
  repositories - that should have been discussed seperately. On a
  seperate thread, Marius said something to the effect of specs are
  much easier to extend than to alter. Having read that, I think we
  were both wrong - specification of a repository should probably have
  been left out completely until repositories had been hashed out.

 Which is what I was pushing for all along. I was trying to leave
 multiple repositories entirely out of it -- despite Paludis making use
 of them -- because the GLEP had nothing to do with multiple
 repositories.

I don't remember the specifics, but I remember that there was something that 
didn't seem to go along with our vision. But yes, I do remember you pushing 
for keeping multiple repositories out of it. In general I try to look at 
everything as my fault (ie. what could I have done different?) and in that 
case I probably should have moved to remove whatever it was that didn't sit 
right rather than pushing to have it adjusted to my vision.

  To sidetrack just a little more, I think this illustrates one of the
  reasons why having PMS (aka EAPI-0 spec) completed is so important.
  Not only would it allow for Gentoo package manager(s) to be
  interchanged/replaced, it would provide a incontrovertible context
  for discussion of new features.

 There aren't going to be any new features in PMS. The only package
 manager changes that we want to come about as a result of it are bug
 fixes.

Yep and that's a good thing.

 Incidentally... Side note on PMS vs EAPI-0: the way PMS is written,
 it's deliberately very easy to integrate EAPI-1, EAPI-2 or whatever
 into the document. Consider PMS to be a document that is capable of
 holding all EAPIs, with EAPI-0 being the only one that's actually there
 for now. Once EAPI-1 is agreed upon, it can be added to PMS rather than
 having to be a whole new document.

That also sounds like a good thing as it gives new ebuild authors a single 
authoritative source on what to expect from a package manager. Although 
EAPI-0 will still be defined, even if it is only as revision XYZ of PMS. 

Also, as a leading dev to a (for a? on a? i've spent too long in Japan :/)
not an official Gentoo project package manager, I hope you realize the 
danger of not having explicit versions of the document. Take, for example, 
the lack of acceptance of some changes to the dev guide that have been 
somewhat controversial...

  This is really irrelevant. It's not matter of if he gets access but
  only as to when. After the initial work is done and the team is
  ready to go public all his noise will come out. I can only think of
  two choices here: 1) whether you and he both continue to be visceral
  or instead try to build a good working relationship; and
  2) whether you discuess any issues with the spec now or when it goes
  public.

 That's a fairly big difference. If it's later on, there won't be lots
 of holes that we know are there that he can use as some kind of twisted
 proof that PMS sucks.

That's a yep again to it being a fairly big difference although I won't
back your justifications. It's something you as a team and ultimately Stephen 
needs to decide. Either way, I'm just reminding all that you're not 
preventing Brian from having a say.


Anyway.. Unless your reply has either something that I don't agree with or 
that is really exciting, I'll let you have the last say. (Why is it that 
those that are technically minded always want to have the last say? ;)

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



Re: [gentoo-dev] Reliance upon || ( use? ( ) ) behaviour

2007-02-23 Thread Jason Stubbs
On Friday 23 February 2007 06:18, Ciaran McCreesh wrote:
 On Thu, 22 Feb 2007 22:05:56 +0100 Thomas de Grenier de Latour

 [EMAIL PROTECTED] wrote:
 | On Thu, 22 Feb 2007 19:08:48 +, Ciaran McCreesh
 |
 | [EMAIL PROTECTED] wrote:
 |  As has been discussed in the past, the only correct way of handling
 |  this from an ebuild perspective is lots of use  has_version calls
 |
 | Which sounds like trying to mimic whatever the deps solver logic may
 | have been, no?  So, why not just let the dep solver itself give the
 | right answer to the ebuild?  It could well set a resolved DEPEND
 | variable (lets call it $RESOLVED_DEPEND for instance) in the ebuild
 | env, that one could query with some helper functions.

This is the best solution that I could come up with in the past as well.

 That strikes me as another large complication. Something that
 complicated shouldn't be necessary.

 Also, I'd like an EAPI-0-able solution :)

Disallowing it would be the cleaner in terms of package manager 
responsibilities, but ...

 |  So, is there a legitimate reason for this complication to exist? Or
 |  should use? blocks being direct children of || ( ) be forbidden?
 |
 | It's not clear to me what would be your prefered DEPEND syntax for the
 | ebuild(5) example you've quoted.  Something like this maybe?:
 |   sdl? ( media-libs/libsdl )
 |   !sdl? (
 |  svga? ( media-libs/svgalib )
 |  !svga? (
 | ...
 |
 | (which is not really equivalent)

 Right. It's not the same, but it's a lot more logical.

the above code - while likely to be what the ebuild author was originally 
intending when using the || ( use? () ) - is not very readable or 
maintainable.

There's also one other issue that you didn't mention in your original email. 
If an ebuild has || ( foo? ( foo/pkg ) bar? ( bar/pkg ) ) and neither foo 
or bar are set, should it be an error because there was no successful result 
among the possibilities? While my gut feeling says yes and (I think) 
portage currently says no, I can't really see any strong reason for either 
case.

Disallowing use clauses directly beneath || constructs would completely 
sidestep that issue too. ;)

But I still what TGL described even if only for EAPI-1 or beyond...

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



Re: [gentoo-dev] Reliance upon || ( use? ( ) ) behaviour

2007-02-23 Thread Jason Stubbs
On Saturday 24 February 2007 03:57, Ciaran McCreesh wrote:
 On Fri, 23 Feb 2007 22:56:19 +0900 Jason Stubbs [EMAIL PROTECTED]

 wrote:
 | Disallowing it would be the cleaner in terms of package manager
 | responsibilities, but ...

 Well, I looked through the tree.

 There is exactly one package using this construct that doesn't get it
 wrong. That package is openoffice, and it uses it to do this:

   java? ( || ( !amd64? ( =virtual/jdk-1.5* ) =virtual/jdk-1.4* )
   dev-java/ant-core )

The openoffice example above shouldn't need the !amd64? condition unless
the amd64 port of openoffice itself doesn't work with a jdk-1.5 package. 
However, if the amd64 port does in fact not work with jdk-1.5, the only
way to rewrite without losing functionality would be:

amd64? ( =virtual/jdk-1.4 )
!amd64? ( || ( =virtual/jdk-1.5* =virtual/jdk-1.4* ) )

 The other fourteen packages using it are either making the mistake
 described in the original email in the thread, or using it where no use
 flag is required at all.

 Given that the one legitimate case can easily be rewritten in another
 way with no loss of functionality, is there really a justification for
 keeping this?

The only compelling reason is aesthetic(sp?). Kevin Quinn rewrote the
example given in ebuild(5) but in doing so functionality was lost.
To rewrite it without any change in behaviour would require something like 
below.

For the 14 cases you mentioned that were making a mistake, they probably can 
be rewritten so as to force an install of the first matching
package, but when that isn't what is wanted it becomes a bit of a headache.

|| (
sdl? ( media-libs/libsdl )
svga? ( media-libs/svgalib )
opengl? ( virtual/opengl )
ggi? ( media-libs/libggi )
virtual/x
)

becomes:

sdl? (
  svga? (
opengl? (
  ggi? (
|| ( media-libs/libsdl media-libs/svgalib virtual/opengl 
 media-libs/libggi virtual/x )
  )
  !ggi? (
|| ( media-libs/libsdl media-libs/svgalib virtual/opengl 
 virtual/x )
  )
)
!opengl? (
  ggi? (
|| ( media-libs/libsdl media-libs/svgalib media-libs/libggi 
 virtual/x ) 
  )
  !ggi? (
|| ( media-libs/libsdl media-libs/svgalib virtual/x )
  )
)
  )
  !svga? (
opengl? (
  ggi? (
|| ( media-libs/libsdl virtual/opengl media-libs/libggi virtual/x ) 
  )
  !ggi? (
|| ( media-libs/libsdl virtual/opengl virtual/x )
  )
)
!opengl? (
  ggi? (
|| ( media-libs/libsdl media-libs/libggi virtual/x )
  )
  !ggi? (
|| ( media-libs/libsdl virtual/x )
  )
)
  )
)
!sdl? (
  svga? (
opengl? (
  ggi? (
|| ( media-libs/svgalib virtual/opengl media-libs/libggi virtual/x )
  )
  !ggi? (
|| ( media-libs/svgalib virtual/opengl virtual/x )
  )
)
!opengl? (
  ggi? (
|| ( media-libs/svgalib media-libs/libggi virtual/x )
  )
  !ggi? (
|| ( media-libs/svgalib virtual/x )
  )
)
  )
  !svga? (
opengl? (
  ggi? (
|| ( virtual/opengl media-libs/libggi virtual/x )
  )
  !ggi? (
|| ( virtual/opengl virtual/x )
  )
)
!opengl? (
  ggi? (
|| ( media-libs/libggi virtual/x )
  )
  !ggi? ( virtual/x )
)
  )
)

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



Re: [gentoo-dev] Reliance upon || ( use? ( ) ) behaviour

2007-02-23 Thread Jason Stubbs
On Saturday 24 February 2007 13:17, Ciaran McCreesh wrote:
 On Sat, 24 Feb 2007 13:09:40 +0900 Jason Stubbs [EMAIL PROTECTED]
 | Okay, I must be missing something here. If package foo can work with
 | either bar or baz equily as well but not both, why should it force an
 | artificial preference?

 For consistency. Installing a package with identical USE flags should
 give the same result on all systems.

 | Also, if packages should not specify dependencies based on what is
 | installed, the semantics of || ( ) would need to be changed such that
 | the first non-masked packages is always installed.

 No, || ( ) has legitimate use for switchable dependencies. For example,
 if a package can use either curl or wget, and it can switch at runtime,
 RDEPEND=|| ( curl wget ) is fine. Similarly, if a package needs
 either tetex or ptex at compile time, DEPEND=|| ( tetex ptex ) is
 correct.

 | The only reason I can see for the above is to be able to have
 | non-broken binary packages. However, that can be addressed by
 | replacing *DEPEND in binary packages with their resolved forms.

 If it affects binaries, it needs to be a USE flag.

So with your DEPEND=|| ( tetex ptex ) case, you're saying that it is valid 
because the choice of tetex or ptex doesn't affect the resultant binaries?
Extrapolating that, specifying link dependencies within an || construct is 
flat out wrong? If so, it's way out of my domain so I can't really comment 
other than you haven't given a reason for this requirement.

Having said that, I'll accept it if we're strictly talking in the EAPI-0 
domain as there is no way for a package manager to guarantee a safe
--depclean implmentation given that raw *DEPENDs are stored in the current
installed package database.

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



Re: [gentoo-dev] Re: Dependencies on system packages

2006-12-16 Thread Jason Stubbs
On Sunday 17 December 2006 10:27, Alec Warner wrote:
 If your package is 'not important' meaning it will never be in 'system' for
 any profile, you should not depend on anything in 'system', as stuff in
 system should already be installed in a given (sane) configuration.

Except if the package is fussy on what version it needs.

 If your package may be in 'system' in a given profile, you need to ensure
 your package builds in the proper order, with regards to other system
 packages.  The classic example is zlib; if you need zlib to uncompress
 something, then you should put zlib in the deps; that way when someone is
 building say, a stage1, your package will build after zlib, instead of
 before it.

Given your point above, this should only be important as far as bootstrapping
goes. After bootstrapping, stuff in system should already be installed.
However, 'system' becomes quite an extensive list of packages after enabling
all use flags that didn't begin with 'no'. I've attached the list that
results from my current tree. So are packages such as qt, nvidia-drivers,
courier-imap, samba and jack-audio-connection-kit also part of 'system' or
is 'system' only limited to the profile-defined USE flags at the time of
bootstrapping?

 You have to be careful in deciding what to specify, as doing things
 incorrectly in this case can often cause dependency loops which are
 sometimes fun to debug; perl and openssl were infamous back in the day for
 this.

This stopped applying with recent versions of portage. I'm pretty sure the
current stable version of portage detects circular deps and tries to resolve
them utilizing installed packages but I've lost track of what's made it to
stable and what hasn't. As far as I know, both palidus and pkgcore do or will
also support this, so your point here doesn't hold.

 Enterprising users would specify the 'doc' useflag. openssl requires perl
 to generate its docs and perl requires openssl for some encryption stuff.
[snipped]

This example is not a reason to leave out appropriate dependencies.

I've tried to be objective here so if my viewpoint isn't obvious I'll state
it outright. I think all packages should depend on every package that they
need to build and/or run. Whether this is done explicitly or with
meta-packages, I don't really care. The only reason for not being explicit
with deps is to cater for old sloppy versions of portage. Unless there are
other reasons not stated here?

--
Jason Stubbs
app-admin/eselect-1.0.2
app-admin/eselect-esd-20060719
app-admin/eselect-opengl-1.0.3
app-admin/gamin-0.1.7
app-admin/perl-cleaner-1.04.3
app-admin/php-toolkit-1.0-r2
app-admin/skey-1.1.5-r5
app-admin/syslog-ng-1.6.9
app-arch/bzip2-1.0.3-r6
app-arch/cpio-2.6-r5
app-arch/gzip-1.3.5-r10
app-arch/rpm-4.4.6-r3
app-arch/rpm2targz-9.0-r5
app-arch/tar-1.16-r2
app-arch/unzip-5.52-r1
app-crypt/gnupg-1.4.6
app-crypt/gnupg-1.9.21
app-crypt/hashalot-0.3-r2
app-crypt/kth-krb-1.2.2-r2
app-crypt/mhash-0.9.2
app-crypt/mit-krb5-1.4.3-r3
app-crypt/opencdk-0.5.5
app-doc/doxygen-1.4.7
app-doc/opengl-manpages-20001215
app-doc/php-docs-20050822
app-editors/emacs-21.4-r4
app-misc/ca-certificates-20050804
app-misc/mime-types-5
app-misc/pax-utils-0.1.13
app-portage/portage-manpages-20060913
app-portage/portage-utils-0.1.20
app-shells/bash-3.1_p17
app-text/aspell-0.50.5-r4
app-text/build-docbook-catalog-1.2
app-text/docbook-dsssl-stylesheets-1.79
app-text/docbook-sgml-dtd-3.0-r3
app-text/docbook-sgml-dtd-3.1-r3
app-text/docbook-sgml-dtd-4.0-r3
app-text/docbook-sgml-dtd-4.1-r3
app-text/docbook-sgml-dtd-4.2-r2
app-text/docbook-sgml-utils-0.6.14
app-text/docbook-xml-dtd-4.1.2-r6
app-text/docbook-xml-dtd-4.2-r1
app-text/docbook-xml-simple-dtd-1.0-r1
app-text/docbook-xml-simple-dtd-4.1.2.4-r2
app-text/docbook-xsl-stylesheets-1.68.1-r1
app-text/ghostscript-gpl-8.54
app-text/htmltidy-4.8.6
app-text/jadetex-3.13-r1
app-text/libpaper-1.1.20
app-text/openjade-1.3.2-r1
app-text/opensp-1.5.2-r1
app-text/poppler-0.5.3
app-text/recode-3.6-r2
app-text/rman-3.2
app-text/scrollkeeper-0.3.14-r2
app-text/sgml-common-0.6.3-r4
app-text/tetex-3.0_p1-r3
app-text/xmlto-0.0.18
dev-db/cdb-0.75-r1
dev-db/firebird-1.5.3-r1
dev-db/freetds-0.62.3
dev-db/libiodbc-3.51.2
dev-db/libpq-8.0.8
dev-db/mysql-5.0.26-r1
dev-db/postgresql-8.0.8
dev-db/qdbm-1.8.70-r1
dev-db/qt-unixODBC-3.3.6
dev-db/sqlite-2.8.16-r4
dev-db/sqlite-3.3.5-r1
dev-db/unixODBC-2.2.11-r1
dev-dotnet/libgdiplus-1.1.13.2
dev-java/blackdown-jdk-1.4.2.03-r12
dev-java/java-config-1.3.7
dev-java/java-config-2.0.30
dev-java/java-config-wrapper-0.12-r1
dev-java/java-sdk-docs-1.4.2
dev-java/java-sdk-docs-1.5.0-r1
dev-java/sun-jce-bin-1.5.0
dev-java/sun-jdk-1.5.0.08
dev-lang/lua-5.0.2
dev-lang/mono-1.1.13.8.1
dev-lang/ocaml-3.09.2
dev-lang/perl-5.8.8-r2
dev-lang/php-5.1.6-r6
dev-lang/python-2.4.3-r4
dev-lang/ruby-1.8.5_p2
dev-lang/swig-1.3.25
dev-lang/tcl-8.4.9
dev-lang/tk-8.4.9
dev-libs/DirectFB-0.9.25.1
dev-libs/apr-0.9.12
dev-libs/apr-util-0.9.12
dev-libs/atk-1.12.1
dev-libs

Re: [gentoo-dev] Re: Dependencies on system packages

2006-12-16 Thread Jason Stubbs
On Sunday 17 December 2006 16:04, Ciaran McCreesh wrote:
 On Sun, 17 Dec 2006 15:10:57 +0900 Jason Stubbs [EMAIL PROTECTED]
 wrote:
 | I've tried to be objective here so if my viewpoint isn't obvious I'll
 | state it outright. I think all packages should depend on every
 | package that they need to build and/or run. Whether this is done
 | explicitly or with meta-packages, I don't really care. The only
 | reason for not being explicit with deps is to cater for old sloppy
 | versions of portage. Unless there are other reasons not stated here?

 If you mandate that, any package using autotools will need around fifty
 new entries in DEPEND.

There's ways to manage this complexity, such as putting the dependencies into 
autotools' RDEPEND (if it can be considered correct) or by using 
meta-packages. However, your point is against requiring that packages _must_ 
specify all system dependencies. While I personally believe that packages 
should specify all dependencies, what I'm arguing against is requiring that 
packages _must not_ specify any system dependencies.

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



Re: [gentoo-dev] Re: Ignoring/overwriting IUSE from an eclass

2006-11-07 Thread Jason Stubbs
On Monday 06 November 2006 17:55, Ciaran McCreesh wrote:
 On Wed, 8 Nov 2006 02:18:41 + Jason Stubbs [EMAIL PROTECTED]

 wrote:
 | Yes, I'm also sick of this negative level of civility. If I don't
 | preempt it now, I'll likely be told that I'm taking the above two
 | quotes out of context

 Which you are, since you removed a large part of my answer and then
 used it to claim that my answer was unhelpful. Hint: read all of what I
 wrote.

I didn't claim that you were unhelpful; I merely claimed that you weren't 
civil. In fact, I acknowledged that your responses could be learned from.

 | Ciaran's analogies are always outrageous, condescending and greatly
 | accentuated.

 And a lot of people find them a pleasant change from the usual lack of
 style and humour exhibited on this list. Effective technical writing
 does not have to be boring.

Sure, but others just find them to be uncivil personal attacks.

 | Specifically, his intention is never to help the person
 | he is replying to, but rather to show them that they are wrong.

 The person is irrelevant. What matters is whether someone looks at a
 proposed incorrect solution and uses it.

 | He believes that is purely up to the person that he is replying to
 | whether they learn from it or not.

 Well yes. What is this, nursery school?

Keep these two points in mind.

 | discussing it further won't help any.

 But you still felt the need to try to throw in a cheap shot full of
 personal attacks. Right.

My intention was only to present the facts as I see them so as to reassure 
Ryan Hill that he is not alone. I can understand why you might take offense, 
but I was no more throwing in a cheap shot full of personal attacks than 
you do with your analogies. I thought that there might be a slim chance that 
you'd learn from what I said, but I left that decision up to you - after all, 
this isn't nursery school.

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



Re: [gentoo-dev] Re: Ignoring/overwriting IUSE from an eclass

2006-11-06 Thread Jason Stubbs
On Monday 30 October 2006 17:44, Piotr Jaroszyński wrote:
 E_IUSE=${E_IUSE//X}

 But that's a dirty portage-specific hack ;]

On Monday 30 October 2006 18:43, Ciaran McCreesh wrote:
 Your solution is approximately on par with fixing a wobbly chair by
 sawing off all four legs and then attaching what's left to a crocodile.

On Monday 06 November 2006 03:36, Ryan Hill wrote:
 I'm sorry, but is anyone else sick and disgusted with Ciaran talking to
 people like this?  This isn't called for and shouldn't be tolerated.

Yes, I'm also sick of this negative level of civility. If I don't preempt it 
now, I'll likely be told that I'm taking the above two quotes out of context 
and that I'm just spreading FUD, but I don't believe the context really 
changed from the outset.

Ciaran's analogies are always outrageous, condescending and greatly 
accentuated. Specifically, his intention is never to help the person he is 
replying to, but rather to show them that they are wrong. He believes that is 
purely up to the person that he is replying to whether they learn from it or 
not. There's a 100+ comment bug about this, though, which ended up with his 
dismissal so discussing it further won't help any.

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] virtuals and dependencies dispaly

2006-10-25 Thread Jason Stubbs
On Tuesday 24 October 2006 16:36, Brian wrote:
 def get_virtual_dep(atom):
 returns a resolved virtual dependency.
 contributed by Jason Stubbs, with a little adaptation
 # Thanks Jason
 non_virtual_atom = portage.dep_virtual([atom], portage.settings)[0]
 if atom == non_virtual_atom:
 # atom,is a 'new style' virtual (aka regular package)
 return atom
 else:
 # atom,is an 'old style' virtual that resolves to:
 non_virtual_atom
 return non_virtual_atom

This could be simplified to:

def get_virtual_dep(atom):
returns a resolved virtual dependency.
return portage.dep_virtual([atom], portage.settings)[0]

Hmm.. Actually, there is one problem here.

 import portage
 portage.dep_virtual(['virtual/mda'], portage.settings)
[['||', 'mail-mta/postfix', 'mail-filter/procmail']]

The values of portage.settings.virtuals are arranged in such a way
that the first value in a key's list is either an installed package
or the package that would be chosen (if no other package in the list
or new package PROVIDEing the virtual was brought in for other
reasons) so you'd probably be better off doing something like:

def get_virtual_dep(atom):
returns a resolved virtual dependency.
key = portage.dep_getkey(atom)
virtuals = portage.settings.getvirtuals()
if key in virtuals:
return atom.replace(key, virtuals[key][0])
else:
return atom

Displaying all known packages for any specific virtual is also a
possibility... I'll leave it up to you on that. ;)

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



Re: [gentoo-portage-dev] virtuals and dependencies dispaly

2006-10-23 Thread Jason Stubbs
On Monday 23 October 2006 16:26, Brian wrote:
 I've been improving portholes dependency display, adding more info to
 it.  I've run into a minor snag when virtuals are concerned.  There also
 seems to be 2 sources of virtuals.  Both are not identical to each
 other:

 /usr/portage/virtual -- which seem to be packages.

They are just regular packages.

 virtuals = portage.db[portage.root][virtuals]  from
 gentoolkit.__init__.py

I'm not sure exactly what this returns, but it's probably equivalent to 
portage.settings.virtuals.

 I've found virtuals in the tree that are not in portages virtuals and
 vice-versa.
 Is there an order to their use by portage?

atom = virtual/portage
non_virtual_atom = portage.dep_virtual([atom], portage.settings)[0]

if atom == non_virtual_atom:
print atom,is a 'new style' virtual (aka regular package)
else:
print atom,is an 'old style' virtual that resolves to',
print non_virtual_atom

 Can the ones in the tree be 
 treated as a category/package for listings, etc..  The ones in the tree
 do seem to be returned by:

 portage.db['/']['porttree'].getallnodes()[:] # copy

 The main reason I am looking at this is for indicating the dependency
 installed/needed for the virtual.  If an installed one is found I use
 it's package name. If not  where should I get it?  From the virtuals in
 portage or the tree? both? - then which order?

The ones in the tree are just regular packages - but may also exist in the 
PROVIDE attribute of associated ebuilds. As for ordering, packages with 
PROVIDE override identically named packages in the tree. If you use something 
similar to the above, it should all be taken care of though.

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



Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users

2006-10-10 Thread Jason Stubbs
On Tuesday 10 October 2006 03:45, Kari Hazzard wrote:
 On Monday 09 October 2006 6:30 pm, Alec Warner wrote:
  I concur with Donnie here; Gentoo exists not because of Users, but
  because of (a subset of active) Developers.  It isn't a statement that
  is meant to trash users (because you are quite helpful in many
  instances).  But the naive thought that Gentoo revolves around users
  iswell, naive.  Gentoo was here before there were thousands of
  users, in the unlikely event that you all switch distros, Gentoo will
  probably still be here.

 It will not, however, have anywhere near as many developers, nor will it
 have more than a fraction of the resources now available to it. Users are
 the reason people sponsor Gentoo, users are the reason people know Gentoo
 exists, whether you realise it or not.

You miss the point entirely. Unpaid software authors do it because they want 
to use the software themselves. Those authors that publish their source 
generally do so because they see it as an overall waste of time for the 
proverbial wheel to be reinvented by others. I'd say they also do it because 
they are happy in the thought that 9 times out of 10 they'll find some other 
author has published source to achieve a new goal of their own saving them 
from having to reinvent the wheel themselves.

So how does this fit in with sponsors and volumnuous resources? Well, it 
doesn't. But then, it was never meant to. So called end users that don't 
give back to the project (giving resources is a way of giving back, by the 
way) make of more than 99% of those that utilize the resources provided by 
sponsors. Sponsoring is essentially payed advertising that wasn't done with 
dollars (or yen, etc) and has a generally high risk return.

If referring to the sponsor a dev program, it's still a similar give-take 
scenario. It either falls into the above scenario (that is, a lesser funded 
dev needs highly supported hardware to continue his regular work, gets it and 
blogs about it) or it falls into the category of poorly supported hardware - 
or both categories. In the case of the latter category, the dev is likely 
just looking for the learning experience when taking the hardware and 
building up support for it. It's all about win-win situations.

I don't know what the original post was about. I only read this one because
I concur with Donnie here caught my eye. But whatever was being asked for in 
the original post (I'm assuming that this sub-thread started with somebody 
asking for something?), would the dev get anything back for satisfying the 
request other than a less stressful time perusing their inbox?

  To make another argument; if I go buy a RHEL3 box set and then complain
  because the liveCD doesn't have some key programs (lets say
  cryptsetup-luks statically compiled so I can boot off of a USB key and
  encrypt my / partition), is the onus on them to release a new CD just
  for me?  Hell I'm a paying customer!  But they don't care.

 Well, that's simply bad customer service.

 Don't constrict your support organ because someone else's support organ
 operates poorly. That doesn't help anyone, not users, not devs.

The initial premise for Alec's argument above is just wrong as when you go out 
and buy a RHEL3 box set you're not actually buying the software contained 
within. What you're buying is a set of installation CDs and an X month/year 
support contract. When you purchase Gentoo CDs, you're buying a set of 
installation CDs only. When you're downloading Gentoo, you're not purchasing 
anything.

I'll try to answer your response to his invalid point, though. Whichever 
product you buy, the licenses for the software contained therein almost never 
place any requirements on the licenser, rather only on the licensee. This is 
true even when it comes to Microsoft, Apple, etc. If you actually go and read 
most of the commercial licenses, it boils down to This software is provided 
AS IS - except that you can't make copies, resell, use on more than one 
computer or by more than one person, etc.

 In any event, when was the decision made to kill the Universal LiveCD for
 x86 and replace it with the installer? I'd like to read the discussion.

I have a feeling the discussion took place about 18 months ago on -core, but 
I'm not sure as to the answer to this.

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



Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users

2006-10-10 Thread Jason Stubbs
On Tuesday 10 October 2006 03:45, Kari Hazzard wrote:
stuff/

After writing the last response, another thought came to mind that I figured I 
should post - and should probably be set out in a user's guide to posting on 
dev mailing lists.

I had the thought that users likely feel that it's okay to repeatedly post 
arguments for their point of view because they often see developers doing it. 
There is a very obvious parallel between users and developers in these 
threads in that both are lazy and thus want things done their own way in 
order to make their lives easier.

The important difference is that (usually :/) at least some of the developers 
of each point of view are willing to implement the whole lot themselves. What 
they are arguing about is how much effort they see will be needed in the long 
term. Even in the case where a developer with a conflicting point of view is 
not willing to do the work now, the developer will argue for the point of 
view as they can see themselves having to redo it later on anyway.

In the open source world, the driving theme is that there is often something 
good enough to not require reinventing the wheel but, in the end, if you 
want a job done right, you've got to do it yourself.

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



Re: [gentoo-dev] Profile masking and profiles package.mask

2006-10-01 Thread Jason Stubbs
On Saturday 30 September 2006 04:40, Diego 'Flameeyes' Pettenò wrote:
 This is a discussion to follow up bug #149508 [1].

Posted on the bug before noticing there was a -dev thread.


Just about everybody has the wrong idea here.

1) Specifying sys-libs/glibc-2.4 in packages *does* mask =sys-libs/glibc-2.4
and thus a corresponding entry in package.mask

2) What should be done is to specify =sys-libs/glibc-2.4 and leave masking 
out altogether for packages

The reason that package.mask was added to profiles was so that masking of 
atoms in packages could be killed off and it could become just a list of 
required packages.


Like Marius said, using packages to both define what's required of system 
and for masking packages is bad design. That and the hope of eventually being 
able to kill off profiles/package.mask are the only reasons package.mask was 
introduced into profiles.

snip stuff that Mike responded to correctly

 I cannot find myself any reason for such a behaviour change, but I'm open
 to be proven wrong.

The original reason for specifying masking in both packages and package.mask 
was that there were portage versions that didn't look at package.mask. That 
was a long time ago though, so masking should really be dropped from packages 
altogether at this late stage.

However, masking in packages only is still supported. If there is a reason 
that the plans for killing off that support should be suspended, that's also 
viable.

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Profile masking and profiles package.mask

2006-10-01 Thread Jason Stubbs
On Monday 02 October 2006 16:03, Jason Stubbs wrote:
 1) Specifying sys-libs/glibc-2.4 in packages *does* mask
 =sys-libs/glibc-2.4 and thus a corresponding entry in package.mask

... is redundant

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



Re: [gentoo-portage-dev] accessing portage updates through it's data structures

2006-04-18 Thread Jason Stubbs
On Tuesday 18 April 2006 13:20, Tom Hosiawa wrote:
 Anybody have any ideas how I can basically do 'emerge -puDNv' directly
 from my superkaramba python program, and get the updates available
 directly from the portage data structures?

What is needed for -uDNv is mostly locked away in emerge, unfortunately.
The following couple of lines should get you everything other than --newuse
though. As you only seem to be interested in what packages are available
for updating, the ordering shouldn't really matter.


import portage

pdb = portage.db[/][porttree].dbapi
vdb = portage.db[/][vartree].dbapi

installed_pkgs = dict([(key, vdb.match(key)) for key in vdb.cp_all()])
latest_pkgs = dict([(key, portage.best(pdb.match(key))) for key in 
installed_pkgs])
updatable_pkgs = [latest_pkgs[key] for key in latest_pkgs if latest_pkgs[key] 
not in installed_pkgs[key]]
updatable_pkgs = [pkg for pkg in updatable_pkgs if pkg]


That last line there is to kill off the None elements that end up in
updatable_pkgs when there is a package installed that has no versions
available in the rsync tree. Other than that, portage.catpkgsplit() will
split a package identifier into [cat, pkg, ver, rev].

--
Jason Stubbs
-- 
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:
 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-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] should we add userpriv and usersandox to make.globals FEATURES?

2006-04-10 Thread Jason Stubbs
On Tuesday 11 April 2006 04:28, Zac Medico wrote:
 Simon Stelling wrote:
  Zac Medico wrote:
  What do people think about adding userpriv and usersandox to
  make.globals FEATURES?  I've been using these for a long time and
  haven't had any trouble with them.  Are there any arguments against
  making them default?
 
  I didn't verify this personally, but a few days ago mkay came to
  #g-portage and asked whether FEATURES='usersandbox -sandbox' resulting
  in sandbox enabled is expected behaviour or not. Before we add
  usersandbox to the default FEATURES we should make sure that -sandbox
  always disables sandbox.
 
 Yeah, we should fix that.  In fact, usersandbox seems like a redundant
 feature to me.  Can we deprecate usersandbox and recommend sandbox as
 the sole means of toggling sandbox on and off (whether userpriv is
 enabled or not)?   

sandbox userpriv thus far has meant to prefer userpriv and fallback to
sandbox when the ebuild doesn't work with userpriv. When those two are
combined with usersandbox on the other hand, it has meant to throw
everything possible at the ebuild. I personally prefer to not use
usersandbox as the sandbox gives a sometimes-not-small performance hit
and I'm a ricer. :P

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



Re: [gentoo-portage-dev] tree dependency check

2006-03-30 Thread Jason Stubbs
On Thursday 30 March 2006 11:40, Marius Mauch wrote:
 On Thu, 30 Mar 2006 08:30:17 +0900
 Jason Stubbs [EMAIL PROTECTED] wrote:
 
  On Thursday 30 March 2006 01:21, Marius Mauch wrote:
   Marius Mauch schrieb:
So after manifest2 is in, I'll revive the other issue that IMO is
a requirement for 2.1: enforcing dependencies needed to use the
tree (see old threads or glep44 for reasoning).
  
  Can you summarise the reasoning again please?
 
 a) avoid massive breakage when certain new features are introduced
 (past examples being cascading profiles or new-style virtuals)

I can't see how massive breakage can be avoided. With your patch the only
difference is instead of partial breakage it's something like your system
is likely broken so go and visit some page to find out if it really is and
how you can fix it.

 b) similar to a) allow people to use new features without having to
 wait for a year or two

Why not just always force portage to be upgraded to at least the latest
stable version? The user can override it by masking (although there isn't
ever any need to as portage doesn't affect other software). If the ebuild
environment is properly documented, things such as new bash features can
be tied to EAPI. Using EAPI on portage ebuilds themselves, a clear upgrade
path can be designated and maintained within the tree.

With EAPI and forced portage upgrades, the only thing that isn't covered
is profile masking. However, your patch doesn't really cover that either.
Unless I'm missing how that would be covered?

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



Re: [gentoo-portage-dev] Re: User created package lists

2006-03-23 Thread Jason Stubbs
On Thursday 23 March 2006 16:23, Brian wrote:
 /etc/portage/lists/userlist1
 
 format:
 
 net-www/apache 
 www-apache/mod_perl
 ...

If you make that /etc/portage/sets and support any package atom (rather
than only cat/pkg) then I you'd pretty much have what is planned (afaik).

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



Re: [gentoo-portage-dev] Re: User created package lists

2006-03-23 Thread Jason Stubbs
On Thursday 23 March 2006 23:43, Brian wrote:
 On Thu, 2006-23-03 at 22:14 +0900, Jason Stubbs wrote:
  On Thursday 23 March 2006 16:23, Brian wrote:
   /etc/portage/lists/userlist1
   
   format:
   
   net-www/apache 
   www-apache/mod_perl
   ...
  
  If you make that /etc/portage/sets and support any package atom (rather
  than only cat/pkg) then I you'd pretty much have what is planned (afaik).
  
  --
  Jason Stubbs
 
 
 What about adding the other update config similar to package.keywords
 
 quoting me:
 Where updates could be one or more of M manual, A automatic, N
 never, K binary packages only.  Also L for license
 
 
 these examples may not be normally sane to actually do.  I'm not a
 server admin.  They are just for demonstration
 eg.
 
 /etc/portage/sets/server
 
 =net-www/apache-2.* M,K   # use my pre-built binaries only when I say
 www-servers/pound A # stay up to date
 ...
 
 /etc/portage/sets/games
 
 games-action/bombermaze 
 games-action/descent3 L # automatically accept it's license 


It seems like too much overloading to me. L is done with ACCEPT_LICENSE.
K could be done with separate repositories (not overlays). M can already
be done with profiles/masking. I can understand your motivation in
tying parameters together, but I honestly think this is not the way to
go about it.

--
Jason Stubbs


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



Re: [gentoo-dev] Making the developer community more open

2006-03-20 Thread Jason Stubbs
On Tuesday 21 March 2006 12:32, Alec Warner wrote:
 m h wrote:
  I'm not a gentoo dev (just a satisfied user), but I lurk on this list.
  
  I was at PyCon last month.  I would estimate that about 40% of the
  people there ran linux on their laptops.  The most popular distros
  were gentoo and ubuntu.  (Not this is not a scientific study, just my
  observations from talking to people there).  While I was there the
  person next to me starting hacking the ebuild classes to handles eggs
  (so he could emerge turbogears).  I talked to at least 3 others who
  were running gentoo.   I asked all of them if they had worked on
  portage.  Most said No, the code is a little scary.  (I'll concur
  with that sentiment, as the code doesn't feel very pythonic).
  
  If you want to attract more developers (python people), a few things are 
  needed:
 
 That depends on how they contribute, I personally don't want random
 python master bob contributing pieces to portage itself.  Portage things
 are not necessarily as simple as people make them out to be.  Even
 developers who know the code well make mistakes in adding and removing
 code.  As solar once pointed out the only man I trust to touch the
 resolver is Jstubbs.  I realize thats a bit elitest...but at the same
 time...I am overly cautious ;)

The resolver as it stands now is not overly difficult. One does really need
to know it back to front though. I should really make splitting it out and
documenting it my big project for 2.2.

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



Re: [gentoo-portage-dev] kudoos to all

2006-03-15 Thread Jason Stubbs
On Thursday 16 March 2006 00:24, Brian wrote:
 I just want to say that all the speedup work everyone has been doing is
 really noticeable.
 
 Porthole now can reload the entire database 10763 packages (includes
 some in PORTDIR_OVERLAY) in about 3 seconds on my system.
 
 Athlon-xp 2000 based.
 
 the cache update after a sync no longer takes as long as compiling the
 mozilla suite .)  good work! :)
 
 currently @ portage-2.1_pre6

Most of that work can be attributed to Brian Harring. For a real kicker
though, throw portdbapi.auxdbmodule = cache.metadata_overlay.database
into /etc/portage/modules and FEATURES=-metadata-transfer into make.conf.
Then rm -rf /var/cache/edb/dep. This one goes to Zac Medico, the current
release coordinator, and builds on Brian's work to cut out cache updating
altogether. New in pre6 (pre5?) and in need of testing - especially when
local modifications are made - but very promising.

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



Re: [gentoo-dev] USE_EXPAND in IUSE ( again )

2006-03-10 Thread Jason Stubbs
On Saturday 11 March 2006 14:19, Alec Warner wrote:
 Either USE_EXPAND always goes in IUSE, or USE_EXPAND never goes in IUSE.

Regardless of what is displayed, portage will eventually need to know what
USE_EXPAND env vars are modifying the behaviour of an ebuild. Consider
extending --newuse to support USE_EXPAND as well. Simply knowing the var
itself isn't quite enough. Could you imagine if every single package that
is modified by USE were recompiled when irrelevant parts of USE is changed?

 If you want USE_EXPAND that sometimes goes in IUSE and sometimes doesn't
 you better have a good plan for keeping those lists of proper USE_EXPAND
 flags and improper flags in sync.  I mean I'd love to do it that way,
 but I'll bet those lists get old and nasty and we will have people
 complaining about QA warnings that they thought were fixed or that there
 were no QA warnings when there should have been...etc..

I also committed support for a USE_EXPAND_HIDDEN. Individual flags don't
need to be added to it. USE_EXPAND_HIDDEN=USERLAND ARCH ... is enough.

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



Re: [gentoo-portage-dev] Move PORTAGE_INST_UID and PORTAGE_INST_GID to make.globals?

2006-03-10 Thread Jason Stubbs
On Saturday 11 March 2006 06:48, Kito wrote:
 
 On Mar 10, 2006, at 4:26 AM, Zac Medico wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Hello,
 
  What do people think about moving PORTAGE_INST_UID and  
  PORTAGE_INST_GID to make.globals?
 
 Would the profiles not be a more logical place to set these? If not,  
 can we twist the logic to make it so? :p

The profiles would be able to override it. In the case of non-incrementals
the first definition found is the winner in the order of:

env - make.conf - make.defaults (profile) - make.globals

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



Re: [gentoo-portage-dev] vdb-update script (for global updates) with job progress framework

2006-02-28 Thread Jason Stubbs
On Tuesday 28 February 2006 22:28, Zac Medico wrote:
 vdb-update has the beginnings of a job progress framework that portage can 
 use to run various time consuming tasks, display progress, and interrupt 
 tasks when necessary.  When vdb-update and fixpackages are ready, I'd like 
 to make both of them into emaint modules.   

It's looking nice and clean at the moment. You might want to think twice about 
integrating it into emaint, though. Integrating the couple of things that 
emaint does into what you're working on would be much better. :)

Seriously, emaint was created in about 30 minutes to counter the regression 
of emerge warning on unsatisfiable world file entries. It was/is not meant to 
stand the test of time in its current state. Why would you want to muddy up 
your code with it? ;)

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



Re: [gentoo-dev] emerge -NDuvp world takes forever after emerge sync

2006-02-25 Thread Jason Stubbs
On Saturday 25 February 2006 18:39, Sebastian Bergmann wrote:
  For a while I am experiencing the following portage annoyance:
 
  After an emerge sync (for which the metadata/cache update takes about
  ten seconds), the first call to emerge -NDuvp world takes between
  five and ten minutes
 
emerge -NDuvp world  321.05s user 77.90s system 94% cpu 7:02.77 total
 
  I am using sys-apps/portage-2.1_pre4-r1.

Open a bug for this please.

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




Re: [gentoo-portage-dev] Config Cleanup Last Call

2006-02-24 Thread Jason Stubbs
On Saturday 25 February 2006 10:40, Alec Warner wrote:
 Please review for badness, otherwise I'll commit this soon ;)

$ grep ^\- portage-config-cleanup.patch | wc -l
58
$ grep ^\+ portage-config-cleanup.patch | wc -l
41

The unrelated PORTAGE_BINHOST chunk is -15/+1 which makes the relevant
part of the patch -43/+42.  What is the goal?

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



Re: [gentoo-portage-dev] Config Cleanup Last Call

2006-02-24 Thread Jason Stubbs
On Saturday 25 February 2006 10:40, Alec Warner wrote:
 Please review for badness, otherwise I'll commit this soon ;)

 - self.backupenv = os.environ.copy()
 - self.configlist.append(self.backupenv) # XXX Why though?
 - self.configdict[backupenv]=self.configlist[-1]
 + self.configdict[backupenv]=os.environ.copy() # XXX Why though? ( ferringb? 
)

Kill this comment altogether. Reading it, my first thought is why what?
It doesn't make the code clearer and so shouldn't be there.

 - self.configlist.append(os.environ.copy())
 - self.configdict[env]=self.configlist[-1]
 + ### backupenv maybe required to be a clone, and not just a reference
 + ### the old code did value copy we do a reference here
 + self.configdict[env]=self.configdict[backupenv]

Again, this comment doesn't make the code clearer and so shouldn't be there.
Changing functionality in a cleanup patch is also bad form. As for the
change itself, it's broken. Look at __setitem__() and reset() and then look
at the usage of those two throughout the code.

 - mydbs=self.configlist[:-1]
 + #Abuse the order of lookuplist to emulate old behavior
 + mydbs=self.lookuplist[:-1]

Same deal with this comment. A person seeing the code for the first time has
no idea what the old behaviour was. In the old code, configlist starts with
globals and ends with env. In the new (and old) code, lookuplist is the
reverse of that. I don't see any further changes to account for this.

 - if 0 and match and mykey in [PORTAGE_BINHOST]:
 - # These require HTTP Encoding
 ...

This shouldn't be in a cleanup patch either.

--
Jason Stubbs

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



Re: [gentoo-portage-dev] Deprecating 'emerge action' syntax

2006-02-16 Thread Jason Stubbs
On Thursday 16 February 2006 20:31, Marius Mauch wrote:
 Right now 'emerge action' and 'emerge --action' are both supported. But
 as we learned with the rsync case 'emerge action' has potential
 namespace conflicts with 'emerge package' I'd propose to deprecate
 'emerge action' before we hit another real conflict.
 (The alternative would be to deprecate 'emerge package' in favor of a
 to-be-written 'emerge install package', but that's even more
 problematic)
 Technically it's a no-brainer, only potential problem would be user
 confusion.
 Any objections against this for pre5?

If by deprecate you mean to detect when '--' hasn't been prepended and
either go ahead with the action or notify that the package doesn't exist
then I have no objections. Might be better to go with the latter so that
users adjust quickly.


Actions specified without a '--' prefix is no longer supported.
Please use --update instead.

emerge: there are no ebuilds to satisfy update.


Doing it that way will show exactly why it's being dropped without the
need for a written explanation (and hopefully no bug about how it's a
terrible usability regression).

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



Re: [gentoo-portage-dev] Deprecating 'emerge action' syntax

2006-02-16 Thread Jason Stubbs
On Friday 17 February 2006 05:30, solar wrote:
 On Thu, 2006-02-16 at 19:04 +0100, Marius Mauch wrote:
 
 [snip]
 
   If by deprecate you mean to detect when '--' hasn't been prepended
   and either go ahead with the action or notify that the package
   doesn't exist then I have no objections. Might be better to go with
   the latter so that users adjust quickly.
  
  You saw the attached one-line patch?

Heh. Actually I completely missed it.

  Atm it just throws a warning when an action without -- is used.
  I'm divided on ignoring the action then, on one hand it would be nice to
  get rid of this, OTOH it would be kinda rude to not have a transition
  period for people. Anyone else having an opinion on this?
 
 I agree it would be kinda rude to just deprecate a behavior and
 introduce another all in one shot. I'd give it a few releases till
 people retrain themselves.
 Maybe when emerge --world/--system/--action has worked it's way into
 at least 2 stable releases before deprecating 'action'

This brings up an interesting point. emerge --world really should fail as
not being valid as it is not an action but a target. With the goal of having
targets user configurable, treating them as options really doesn't work.

So, I'm also moving toward just printing warnings for the time being.
However, we should probably figure out exactly how it should work and then
print warnings whenever any deprecated syntax is used. Not so much for users
and scripts, of which I can't see there being much of a problem, but so that
we can redo that whole bunch of code without having to do:

if incorrect_syntax:
print warning
make correct syntax

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



Re: [gentoo-portage-dev] IUSE_DEFAULTS-v0.1

2006-02-14 Thread Jason Stubbs
On Tuesday 14 February 2006 21:44, Alec Warner wrote:
 Brian Harring wrote:
  IUSE- eapi bump it, I pushed for the var for exactly crap like this ;)
  
  The only (imo) reason to add the USE_ORDER chunks is because users use 
  -* to castrate auto-use; auto-use is dead in 2.1, so the main reason 
  for using -* is gone.
  
  So... really worth adding another chunk of metadata for this?
 
 Well that problem would be, no one wants to modify everything in
 app-portage/ :).  If my portage EAPI is 1, but my tools don't support
 processing +- in IUSE, how does EAPI help me here?  The support check is
 only for portage_const, so the tool remains sensored.  Unless I'm
 missing something.

Nah, Brian's right. Tools need to follow. Backwards compatibility isn't so
important there. The important thing is that portage keeps on living.

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



[gentoo-dev] Re: Passing the buck

2006-02-09 Thread Jason Stubbs
On Thursday 09 February 2006 15:00, Brian Harring wrote:
 On Sun, Feb 05, 2006 at 03:04:08PM +0900, Jason Stubbs wrote:
  Hi all,
  
  Time again for one of those mails; this time from me. Due to time 
  constraints, 
  real life and coming close to burning out I'm stepping down as release 
  coordinator. Brian has graciously accepted shouldering the burden until he 
  starts to burn out or some insane bugger comes along and wrestles him for a 
  slice of the action.
 
 And I suck, because I'm going to pass the buck now.
 
 The .5x release, and 2.1.pre5 realease I'll handle; if 2.1 proves 
 stable, and doesn't take forever I'll see it through, but I'm taking 
 at least a hiatus from gentoo.

I'll pull it back if you like, but it means I'll pretty much not have time
for anything else. While I've been fed up with the bullshit myself in the
past, the feeling is somewhat subdued at the moment so I can get right back
into it if you like. Not that I stopped reading through the commits anyway;
habits are hard to break. ;)

I'll have a little more time than I estimated for the time being anyway.
Dell wants us to pay $35K for the hardware and then $50K+ on top of that
for them to configure and install the redhat on it all. :/
(== SAN has been postponed)

Long term, same deal though. Perhaps it would be a good idea to get those
interested in it together and can try to get some documentation together.
That should at least make the executor less important...

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



Re: [gentoo-dev] Re: Passing the buck

2006-02-09 Thread Jason Stubbs
On Thursday 09 February 2006 20:23, Jason Stubbs wrote:
...

Wrong list :/

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



Re: [gentoo-dev] Binary packages

2006-02-08 Thread Jason Stubbs
On Thursday 09 February 2006 08:19, Mark Loeser wrote:
 Anyone that is maintaining a binary package in the tree, and requires
 libstdc++-v3, please put a rdepend in your package on
 =virtual/libstdc++-3.3.  I'd like to drop the dependency from gcc-3.4 and
 higher so that we do not needlessly force the libstdc++ package on people
 that do not need it.

It was my understanding that it is needed for the 3.3 - 3.4 upgrade.
Various packages that will build fine against either are broken until
being recompiled after the upgrade and there is currently no way to
express this with dependencies.

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



Re: [gentoo-dev] Binary packages

2006-02-08 Thread Jason Stubbs
On Thursday 09 February 2006 09:30, Mark Loeser wrote:
 Jason Stubbs [EMAIL PROTECTED] said:
  It was my understanding that it is needed for the 3.3 - 3.4 upgrade.
  Various packages that will build fine against either are broken until
  being recompiled after the upgrade and there is currently no way to
  express this with dependencies.
 
 You need either gcc-3.3 or libstdc++-v3.  I don't see forcing either upon our
 users to be a good thing.  The upgrade doc covers how to do the 3.3-3.4
 upgrade, and I think most archs are on 3.4 at this point.

Ok. If the there's an upgrade doc and 3.4 postinst points to it, no problem.
I take it the dependencies you're asking about is for binary-only (or other?)
packages that specifically depend on 3.3 then?

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



Re: [gentoo-portage-dev] confcache, final chance to ixnay it

2006-02-02 Thread Jason Stubbs
On Thursday 02 February 2006 21:12, Brian Harring wrote:
 Yo...
 
 attached is a patch enabling confcache support for portage.  Lots of 
 testing, plus fixups from comments from folks prior.
 
 So... giving it a few days, nows the time to bitch if you dislike the 
 implementation (and no, I'm not rewriting all of doebuild just for 
 this :)

Happy here. If there were no other issues, may as well go ahead with it
earlier rather than later. Spread the goodness (or something like that ;)

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



Re: [gentoo-dev] Re: Unmasking modular X

2006-01-31 Thread Jason Stubbs
On Tuesday 31 January 2006 13:49, Joshua Jackson wrote:
 Mark Loeser halcy0n at gentoo.org writes:
  Donnie Berkholz spyderous at gentoo.org said:
   Jason Stubbs wrote:
The patch now has the debugging output and x11-base/xorg-x11 check 
removed. 
   
   Excellent. Works perfectly. Since we're failing on them, perhaps we can
   say obsolete instead of deprecated?
  
  Can we put this back to being a warning?  It makes things a pain for arch
  teams that are trying to mark a completely unrelated version of the 
  package. 
 
 I will have to agree that this change has made it a pain to mark anything
 stable. I had 4 out of the 6 I did today bail out because of this. I took 
 the simple easy fix and removed the check to stabalize the packages I needed 
 to. I know we have people who want modular X yesterday, but causing trouble 
 for dev's going about business that doesn't involve the modular problems 
 directly is only going to cause resentment and frustration to all the teams 
 involved. 

Is there any need for the packages to go into stable without the X deps being 
fixed? Why not just open a bug for the package maintainer and mark it against 
whatever bug is requesting stabling of that package? Moving something to 
stable that you know is going to be broken within a relatively short 
timeframe seems like a very bad idea...

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



Re: [gentoo-dev] IUSE and LINGUAS?

2006-01-31 Thread Jason Stubbs
On Monday 30 January 2006 20:54, Ciaran McCreesh wrote:
 On Mon, 30 Jan 2006 20:46:28 +0900 Jason Stubbs [EMAIL PROTECTED]
 wrote:
 | On Monday 30 January 2006 16:43, Ciaran McCreesh wrote:
 |  On Mon, 30 Jan 2006 06:17:36 +0100 Diego 'Flameeyes' Pettenò
 |  [EMAIL PROTECTED] wrote:
 |  | Also, as repoman complain about linguas_blabla not being a valid
 |  | useflags, all the linguas_* useflags should be listed in use.desc
 |  
 |  No, part of the point of USE_EXPAND is that they shouldn't. This is
 |  a repoman bug.
 | 
 | I have yet to be enlightened on any merit of USE_EXPAND is so perhaps
 | you could explain as to why there should be
 | user-configured-yet-undocumented options for ebuilds? More precisely,
 | how should they be documented if not via use.desc?
 
 1. Because for things like LINGUAS, there are arbitrarily many legal
 values, and documenting them all and keeping the list up to date would
 be extremely difficult.

More precisely, how should they be documented if not via use.desc?

 2. Because USE_EXPAND is used for special USE things like arch and
 userland, and because we undocumented the special arch USE flags
 because they're not user settable.

These variables are internal and not meant to be user configurable.

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Unmasking modular X

2006-01-31 Thread Jason Stubbs
On Wednesday 01 February 2006 02:28, Mark Loeser wrote:
 Jason Stubbs [EMAIL PROTECTED] said:
  Is there any need for the packages to go into stable without the X deps 
  being 
  fixed? Why not just open a bug for the package maintainer and mark it 
  against 
  whatever bug is requesting stabling of that package? Moving something to 
  stable that you know is going to be broken within a relatively short 
  timeframe seems like a very bad idea...
 
 We are talking about completely unrelated versions, not what we are touching.
 For example, old imagemagick ebuilds sitting around, where the newer ebuilds
 are fixed, but old ones are not.  We have a security bug open about this
 package right now, and having an error about deps in some old version doesn't
 really help arch teams at all.

Security bugs are about the only time I can see any urgency. That's not
a good reason to completely degrade the error though. A switch similar
to --ignore-other-archs that skips certain checks for urgent fixes seems
reasonable though.

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



Re: [gentoo-dev] IUSE and LINGUAS?

2006-01-31 Thread Jason Stubbs
On Tuesday 31 January 2006 22:39, Mike Frysinger wrote:
 On Tuesday 31 January 2006 06:31, Jason Stubbs wrote:
  On Monday 30 January 2006 20:54, Ciaran McCreesh wrote:
   1. Because for things like LINGUAS, there are arbitrarily many legal
   values, and documenting them all and keeping the list up to date would
   be extremely difficult.
 
  More precisely, how should they be documented if not via use.desc?
 
 considering there's a ton more LINGUAS values than we have USE flags (just 
 run 
 `wc` on use.desc and lang.desc), bloating use.desc with LINGUAS settings 
 benefits *noone*
 
 we have lang.desc, it is quite populated, what's wrong with having portage 
 read that

Absolutely nothing. I am in no way suggesting that use.desc is the possible
fix. I wasn't even suggesting that each individual flag need be documented.
However, if lang.desc already exists (and it does) and can be renamed to
linguas.desc, it is probably a better way to manage it than use.desc. Is
having INPUT_DEVICES and the like following the same scheme
(ie, input_devices.desc) acceptable?

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



Re: [gentoo-dev] IUSE and LINGUAS?

2006-01-30 Thread Jason Stubbs
On Monday 30 January 2006 14:17, Diego 'Flameeyes' Pettenò wrote:
 [ebuild   R   ] media-tv/kdetv-0.8.8-r1  USE=-arts -debug -lirc -opengl 
 -xinerama -zvbi LINGUAS=it% -bg% -br% -ca% -cs% -cy% -da% -de% -el% 
 -en_GB% -es% -et% -fi% -fr% -ga% -gl% -hu% -is% -lt% -mt% -nb% -nl% -pa% 
 -pl% -pt% -pt_BR% -ro% -ru% -rw% -sr% [EMAIL PROTECTED] -sv% -ta% -tr% 
 -zh_CN% 0 kB

This would only be on the first installation. The % symbol indicates that 
the flags have been added. On the second run it would become:

 [ebuild   R   ] media-tv/kdetv-0.8.8-r1  USE=-arts -debug -lirc -opengl 
 -xinerama -zvbi LINGUAS=it -bg -br -ca -cs -cy -da -de -el -en_GB -es -et 
 -fi -fr -ga -gl -hu -is -lt -mt -nb -nl -pa -pl -pt -pt_BR -ro -ru -rw -sr 
 [EMAIL PROTECTED] -sv -ta -tr -zh_CN 0 kB 

Not a huge difference but not exactly minor either. And of course LINGUAS= 
wouldn't be shown at all if nothing had changed with regard to it and 
--verbose wasn't specified.

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] IUSE and LINGUAS?

2006-01-30 Thread Jason Stubbs
On Monday 30 January 2006 16:43, Ciaran McCreesh wrote:
 On Mon, 30 Jan 2006 06:17:36 +0100 Diego 'Flameeyes' Pettenò
 [EMAIL PROTECTED] wrote:
 | Also, as repoman complain about linguas_blabla not being a valid
 | useflags, all the linguas_* useflags should be listed in use.desc
 
 No, part of the point of USE_EXPAND is that they shouldn't. This is a
 repoman bug.

I have yet to be enlightened on any merit of USE_EXPAND is so perhaps you 
could explain as to why there should be user-configured-yet-undocumented 
options for ebuilds? More precisely, how should they be documented if not
via use.desc?

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Unmasking modular X

2006-01-25 Thread Jason Stubbs
On Wednesday 25 January 2006 17:43, Donnie Berkholz wrote:
 Jason Stubbs wrote:
  I'm not exactly sure what you mean by broken in the first paragraph nor 
  how a check can help with unmaintained (=no commits, no?) packages, but if 
  a repoman check will hasten package porting while smoothing the users' 
  ride, I'm personally all for it.
 
 By broken I mean unported. In other words, directly depending on
 either virtual/x11 or x11-base/xorg-x11. The check will help discover
 unmaintained packages by not allowing people to do flyby fixes without
 also fixing this.
 
 What can I do to speed up the process of getting this into a 2.1
 release? Keep in mind my python is beyond bad.

Perhaps not so easy. What specific states need to be checked for to regard a 
package as broken? Depending on x11-base/xorg-x11 is one. Depending on 
virtual/x11 seems to be valid looking at the porting guide though. Would 
considering a package broken if it contains virtual/x11 where the token 
immediately preceding the surrounding brackets is not || be correct?

DEPEND=x11-base/xorg-x11  # wrong
DEPEND=virtual/x11# wrong
DEPEND=|| ( x11? ( virtual/x11 ) )# wrong
DEPEND=|| ( misc/atoms virtual/x11 )  # right

There's a small possibility that broken packages will be missed by this, but 
is there any chance that valid packages will be incorrectly flagged? If this 
gets a go-ahead, it'll be easy enough to get in for the next release (which 
is likely this coming Saturday).

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



Re: [gentoo-dev] Unmasking modular X

2006-01-25 Thread Jason Stubbs
On Wednesday 25 January 2006 18:10, Donnie Berkholz wrote:
 Jason Stubbs wrote:
  DEPEND=x11-base/xorg-x11  # wrong
  DEPEND=virtual/x11# wrong
  DEPEND=|| ( x11? ( virtual/x11 ) )# wrong
  DEPEND=|| ( misc/atoms virtual/x11 )  # right
  
  There's a small possibility that broken packages will be missed by this, 
  but is there any chance that valid packages will be incorrectly flagged? 
  If this gets a go-ahead, it'll be easy enough to get in for the next 
  release (which is likely this coming Saturday).
 
 It sounds right. There should be no valid instance of virtual/x11 that
 is not within an || dep.

I've implemented and tested the check locally but haven't committed it yet. 
Repoman isn't really structured to allow for tests against a set of ebuilds 
so the checks are done on every version. There is also definitely one false 
positive (virtual/x11-6.8) so, for this and the fact that every version is 
tested, it would probably better to just make it a warning. Thoughts?

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



Re: [gentoo-dev] Unmasking modular X

2006-01-25 Thread Jason Stubbs
On Wednesday 25 January 2006 20:46, Brian Harring wrote:
 On Wed, Jan 25, 2006 at 08:27:22PM +0900, Jason Stubbs wrote:
  On Wednesday 25 January 2006 18:10, Donnie Berkholz wrote:
   Jason Stubbs wrote:
DEPEND=x11-base/xorg-x11  # wrong
DEPEND=virtual/x11# wrong
DEPEND=|| ( x11? ( virtual/x11 ) )# wrong
DEPEND=|| ( misc/atoms virtual/x11 )  # right

There's a small possibility that broken packages will be missed by 
this, but is there any chance that valid packages will be incorrectly 
flagged? If this gets a go-ahead, it'll be easy enough to get in for 
the next release (which is likely this coming Saturday).
   
   It sounds right. There should be no valid instance of virtual/x11 that
   is not within an || dep.
  
  I've implemented and tested the check locally but haven't committed it 
  yet. Repoman isn't really structured to allow for tests against a set of 
  ebuilds so the checks are done on every version. There is also definitely 
  one false positive (virtual/x11-6.8) so, for this and the fact that every 
  version is tested, it would probably better to just make it a warning. 
  Thoughts? 
 
 Curious about the mechanism you're using for this... a hardcoded set 
 of atoms in repoman doesn't sound very nice to me ;)

Get off it. There's no other way to do it given repoman's state and the 
requirements. If you'd like to make repoman pluggable, convert all the 
current checks to plugins and then make a new plugin for this one and do it 
all by this weekend, be my guest. :P

Besides, what's wrong with hardcoded atoms in repoman anyway? Repoman doesn't 
have to stand the test of time. Conversely, it should represent checks for 
whatever issues are present in the tree at the time of its release.

http://dev.gentoo.org/~jstubbs/x11_deprecation_check.diff

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



Re: [gentoo-dev] Unmasking modular X

2006-01-25 Thread Jason Stubbs
On Wednesday 25 January 2006 21:47, Brian Harring wrote:
 On Wed, Jan 25, 2006 at 09:18:28PM +0900, Jason Stubbs wrote:
  There's no other way to do it given repoman's state and the requirements.
 
 I was talking long term.  One time kludges suck (but occur), would like to 
 see something a bit less short sighted for this though- variants of this 
 request will come up sooner or later (most likely in the form of can we 
 warn/error on new commits of deprecated deps).   

 Might be wise discussing potential solutions for it.

This is off-topic now.

  If you'd like to make repoman pluggable, convert all the current checks to 
  plugins and then make a new plugin for this one and do it all by this 
  weekend, be my guest. :P 
 
 Harass antarus, he's been working on integrating swegeners rewrite of 
 repoman checks (plugins effectively) into mainline repoman. :P 
 
 Besides, a massive change to repoman with 3 days to go is a no go anyways 
 (kind of limited the choices there) ;) 

Would 10 days or 17 days really be any different?

  Besides, what's wrong with hardcoded atoms in repoman anyway?
 
 portage (by extension repoman) is used beyond gentoo.  Not everyone may be 
 at the same step as we are for mod x.  End result of hardcoding gentoo 
 specific crap into repoman is that you force derivatives of gentoo 
 (vidalinux or genux fex) to start hacking up portage source to remove said 
 hardcoding.  
 
 Portage exists beyond gentoo; thus gentoo specific hacks should be avoided 
 when possible. 

Such as warning/failing on:
* the server's repository path is /space/cvsroot
* any extensions to metadata.xml
* larger-than-20k-files
* not being copyrighted to Gentoo Foundation
* not being distributed under GPLv2

There's probably others but all of those things are Gentoo specific and cause 
no less trouble than what a virtual/x11 check might cause.

 So... long term?

Refactor/rewrite/modularize/blah repoman. In the mean time, make do with what 
we have and let Gentoo derivatives do the same.

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



Re: [gentoo-dev] Unmasking modular X

2006-01-25 Thread Jason Stubbs
On Thursday 26 January 2006 16:08, Donnie Berkholz wrote:
 It prints about 10X of crap like this:
 
 virtual/libc !virtual/xemacs berkdb? ( =sys-libs/db-1*
 =sys-libs/gdbm-1.8.0 ) =sys-libs/zlib-1.1.4 =dev-libs/openssl-0.9.6
 =media-libs/audiofile-0.2.3 gpm? ( =sys-libs/gpm-1.19.6 ) postgres? (
 =dev-db/postgresql-7.2 ) ldap? ( net-nds/openldap ) nas? (
 media-libs/nas ) dnd? ( x11-libs/dnd ) X? ( virtual/x11 ) motif? (
 =x11-libs/openmotif-2.1.30 ) athena? ( virtual/x11 ) Xaw3d? (
 x11-libs/Xaw3d ) neXt? ( x11-libs/neXtaw ) xface? ( media-libs/compface
 ) tiff? ( media-libs/tiff ) png? ( =media-libs/libpng-1.2* ) jpeg? (
 media-libs/jpeg ) canna? ( app-i18n/canna ) !amd64? ( freewnn? (
 app-i18n/freewnn ) ) =sys-libs/ncurses-5.2 !bootstrap? ( sys-devel/patch )

This was testing/debugging left in by mistake.

 Then doesn't print the one line saying
 app-editors/xemacs/xemacs-21.4.15-r3.ebuild: RDEPEND has deprecated x11
 dependencies without a full listing? That doesn't make sense -- if it
 has to be one way or the other, it should be the reverse.

That's a standard repoman thing. Details are only printed if there are less 
than 12 occurrences of a specific warning unless repoman full is run. Not 
sure why it wasn't being displayed if there was only one occurrence.

The patch now has the debugging output and x11-base/xorg-x11 check removed.

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



Re: [gentoo-dev] Unmasking modular X

2006-01-24 Thread Jason Stubbs
On Wednesday 25 January 2006 15:53, Ciaran McCreesh wrote:
 On Tue, 24 Jan 2006 22:28:09 -0800 Donnie Berkholz
 [EMAIL PROTECTED] wrote:
 |  * The clean solution is the solution originally proposed to this
 |  list, and the reason we are using new style virtuals.
 | 
 | No, this is wrong. The reason we are using new style virtuals is so we
 | could have a versioning in what provides virtual/x11. Namely, 6.8 or
 | older.
 
 Uh, given that you can do that with old style virtuals, methinks that
 isn't the case...

Only by modifying every ebuild that has a virtual/x11 dependency. The atom 
virtual/x11 cannot be limited to specific versions on its own with old 
style virtuals.

 |  * You are doing this because you believe that it is better to get
 |  every package ported over extremely quickly rather than having the
 |  odd package with extra unnecessary listed dependencies, and you do
 |  not consider the impact upon our users to be relevant.
 | 
 | I consider ~arch users to have agreed to help test and fix new things.
 | This is included. I would not do the same thing to our stable tree, or
 | if we only had a stable tree.
 | 
 | Yes, I do think it is better to have a quick solution and let some of
 | our ~arch users see a couple of blocks, for which they will file bugs.
 | Then these bugs will be fixed within a day, and those users will again
 | have working systems.
 
 ...or you could do things as originally planned, and have no
 non-working systems at all and the only consequences for end users will
 be a small number of extra packages (that they previously had installed
 anyway as part of hugeass X) being pulled in.

The premise for not doing this is that packages will never be fixed, right? 
Why not make the modular X provide virtual/x11 and just institute a policy 
that no new packages can go into stable with a virtual/x11 dependency? It 
could even be easily enforcable if necessary.

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



Re: [gentoo-dev] Unmasking modular X

2006-01-24 Thread Jason Stubbs
On Wednesday 25 January 2006 16:19, Donnie Berkholz wrote:
 Jason Stubbs wrote:
  Only by modifying every ebuild that has a virtual/x11 dependency. The atom 
  virtual/x11 cannot be limited to specific versions on its own with old 
  style virtuals.
 
 Is that so? I guess this must be wrong, then:
 
 /usr/portage/profiles/base/virtuals:# Only have this for =pam-0.78, as
 we want to make use of the 'include'
 /usr/portage/profiles/base/virtuals:virtual/pam
 =sys-libs/pam-0.78

Yep, portage simply removes the = and 0.78 parts and makes all versions of 
sys-libs/pam a provider of virtual/pam. Why there is no warning I don't know.

  The premise for not doing this is that packages will never be fixed, 
  right? Why not make the modular X provide virtual/x11 and just institute a 
  policy that no new packages can go into stable with a virtual/x11 
  dependency? It could even be easily enforcable if necessary.
 
 How does that fix the stale, unmaintained here and upstream apps that
 are in stable now and have no ~arch ebuilds?

It wouldn't, but at least there'd be fewer packages to deal with in the final 
cleanup. It was just an innocent question though; as far as I can tell, 
emerging any application (ported or not) on a clean system will not break 
even after modular X is unmasked. It's a fine line between whether packages 
needlessly not working together due to incompatible (deep) dependencies is 
considered breakage or not though...

/me steps away from the flames for fear of getting burned.

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



Re: [gentoo-portage-dev] confcache integration

2006-01-24 Thread Jason Stubbs
On Tuesday 24 January 2006 21:50, Brian Harring wrote:

+os.makedirs(mysettings[CONFCACHE_DIR], mode=0775)
+os.chown(mysettings[CONFCACHE_DIR], portage_uid, -1)

This will die when running as non-root, no? ebuild is now oft used by devs
running as normal users which will be broken by this. No clues on the bash
stuff; it seems there's an external confcache binary but I can't tell much
beyond that.

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



Re: [gentoo-dev] SuperH (sh) KEYWORD spam

2005-12-31 Thread Jason Stubbs
On Saturday 31 December 2005 18:57, Mike Frysinger wrote:
 i'm injecting sh KEYWORDS as quickly as my lantank can emerge ...

So that's one package every two weeks then? ;)

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



Re: [gentoo-dev] Multiple Repo Support

2005-12-30 Thread Jason Stubbs
On Friday 30 December 2005 21:17, Spider (DmD Lj) wrote:
 On Fri, 2005-12-30 at 10:35 +0900, Jason Stubbs wrote:
  On Friday 30 December 2005 01:35, Spider (DmD Lj) wrote:
   On Tue, 2005-12-27 at 19:06 +, Ciaran McCreesh wrote:
On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke [EMAIL PROTECTED]
  
   Thats actually viable. For -installed- ebuilds,  we simply unpack all
   RDEPEND logic, remove all use flags ( stored, but the use logic is
   removed from the RDEPEND since its already resolved, doesn't need to be
   there. The binary is static already )
  
   Then check vs. the installed SLOT of all RDEPEND packages, and lock our
   current deptree to the package of that SLOT...
 
  I suggested this last Tuesday..

 No, what you suggested was that  for the case of when you depend on a
 SLOT, then the tree is flattened.  My point was for the generic case :

 DEPEND==kde-base/kdelibs-3.0   (as many ebuilds look today)

 is then expanded to the current matching SLOT of kdelibs, so even if
 there -wasn't- a SLOT requirement beforehand, there is one afterwards.

Okay, I misinterpreted. Anyway, it looks like neither of our ideas will work:

app-text/docbook-sgml/docbook-sgml-1.0.ebuild:

RDEPEND=app-text/sgml-common app-text/openjade
=app-text/docbook-dsssl-stylesheets-1.64
=app-text/docbook-sgml-utils-0.6.6
~app-text/docbook-sgml-dtd-3.0
~app-text/docbook-sgml-dtd-3.1
~app-text/docbook-sgml-dtd-4.0
~app-text/docbook-sgml-dtd-4.1

docbook-sgml-dtd-3.0-r3.ebuild:SLOT=3.0
docbook-sgml-dtd-3.1-r3.ebuild:SLOT=3.1
docbook-sgml-dtd-4.0-r3.ebuild:SLOT=4.0
docbook-sgml-dtd-4.1-r3.ebuild:SLOT=4.1

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



Re: [gentoo-dev] Multiple Repo Support

2005-12-30 Thread Jason Stubbs
On Friday 30 December 2005 22:13, Spider (DmD Lj) wrote:
 it would block against requirement of same package with different SLOT.

 However, since the ~ atoms are explicit and separate ( this depend tree
 could as well be called :
 app-text/docbook-sgml-dtd:3.0
 app-text/docbook-sgml-dtd:3.1
 app-text/docbook-sgml-dtd:4.0
 app-text/docbook-sgml-dtd:4.1

 Which, for some reason, should be supported : )

 Either by casing out appearances where multiple SLOTs are depended on by
 -one- package, or by saying that ~ is special-cased due to its stricter
 limitations, which would make it pass by the SLOT check.

 ( no, its not an elegant solution, but it might work ;)

Inelegant solutions gets us no further than where we are now. ;)

A still inelegant solution, but one that I could live with, is to leave SLOT 
handling as it is now and to take Brian's syntax of key:slot,slot using it 
specifically for the case where a set of ebuilds must all use the same slot. 

Hence, rather than digikam and friends having || ( kdelibs:3.4 kdelibs:3.5 ) 
each would have just kdelibs:3.4,3.5. It still sounds messy given the 
current redesign of atom handling, but it would seem to offer a better chance 
of not being bug-ridden...

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



Re: [gentoo-dev] Multiple Repo Support

2005-12-29 Thread Jason Stubbs
On Friday 30 December 2005 01:35, Spider (DmD Lj) wrote:
 On Tue, 2005-12-27 at 19:06 +, Ciaran McCreesh wrote:
  On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke [EMAIL PROTECTED]
 
  wrote:
  | On Tuesday 27 December 2005 18:59, Ciaran McCreesh wrote:
  |  Nnnope. If you modify an eclass it forces a cache regen for packages
  |  using said eclass (except possibly if you're using an overlay, but
  |  that's a separate issue...).
  |
  | You're trying to solve something which is already solved, but this
  | has nothing to do with our problem. The question is not listen the
  | possible valid KDE versions or a change of the eclass, but the need
  | to know actual used KDE version. You'd need to call e.g. kde-config
  | to get it. And this breaks caching.
 
  So you RDEPEND upon the version of KDE against which you were built,
  and use the || ( ) flattening feature that's already been proposed.

 Thats actually viable. For -installed- ebuilds,  we simply unpack all
 RDEPEND logic, remove all use flags ( stored, but the use logic is
 removed from the RDEPEND since its already resolved, doesn't need to be
 there. The binary is static already )

 Then check vs. the installed SLOT of all RDEPEND packages, and lock our
 current deptree to the package of that SLOT...

I suggested this last Tuesday.. 

 I can smell sooo much breakage from this solution. Even though it could
 work  : )

I'm not sure to interpret this as yet another snide remark or not so I'll 
give you the benefit of the doubt and assume you're referring to sets of 
ebuilds that require several slots. Before implementing the above, the tree 
will be checked for any cases where the above idea will fail.

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



Re: [gentoo-dev] Multiple Repo Support

2005-12-27 Thread Jason Stubbs
On Tuesday 27 December 2005 12:08, Brian Harring wrote:
 On Tue, Dec 27, 2005 at 03:54:38AM +0100, Carsten Lohrke wrote:
  On Tuesday 27 December 2005 03:40, Brian Harring wrote:
   The version of digikam being merged requires slot=3.5- it should be
   depending on libk* slot=3.5, also, no?
 
  No! It (and also its dependencies) can be built against each 3.x slot.
 
   As long as the information is represented dependency wise, portage
   should be able to handle it fine.  Just need to have that info there.
 
  It can't be handled dependency wise, because what is interesting is
  against which KDE version the relevant ebuilds are actually installed.

 So note the comment in the email you are responding to about locking
 down the used dep/rdeps for an install.

 Via that, could lock down the slot it was compiled against.  Bit more
 to it then that, but the concerns your raising *again* are not
 use/slot based, your pointing at other portage faults (thus please
 seperate those concerns from use/slot).

I may be missing something, but I can't see how this will resolve Carsten's 
issue. From what I can tell, the ebuilds would be laid out something like:

digikam:DEPEND=|| ( kdelibs:3.5 kdelibs:3.4 ) libkipi libkexif
libkipi:DEPEND=|| ( kdelibs:3.5 kdelibs:3.4 )
libkexif:DEPEND=|| ( kdelibs:3.5 kdelibs:3.4 )

If all three of those packages were first built against kdelibs:3.4 and then 
kdelibs:3.5 became available then rebuilding any one of them without 
rebuilding the others will break digikam. I can't see how it's directly 
represented in the metadata unless you want to overload the meaning of SLOT.

If overloading, dependencies would be flattened (meaning || ( kdelibs:3.5 
kdelibs:3.4 ) would have became kdelibs:3.4 for the original install) 
within the installed package database but there's also there's the 
implication that only one slot of a package be allowed in a connected set of 
nodes. Is that what you're getting at?

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



Re: [gentoo-dev] Multiple Repo Support

2005-12-27 Thread Jason Stubbs
On Tuesday 27 December 2005 22:45, Carsten Lohrke wrote:
 On Tuesday 27 December 2005 14:00, Jason Stubbs wrote:
  If all three of those packages were first built against kdelibs:3.4 and
  then kdelibs:3.5 became available then rebuilding any one of them without
  rebuilding the others will break digikam. I can't see how it's directly
  represented in the metadata unless you want to overload the meaning of
  SLOT.

 It's not possible to represent that via dependencies. What is needed is
 some sort of introspection which relevant ebuild is built against which KDE
 version and if those _installed_ ebuild:kdever combinations match the one
 the _actual_ ebuild to emerge.

Do you mind reading and replying to the second paragraph (which happens to be 
the only new information I brought to this thread). Underlining words to 
emphasize a point to me that I've opened by agreeing is really not necessary.

 But you're right about the overloading of the meaning of slots, because
 that's happening right now. Slots are used to install several versions of a
 package side by side. The idea Ciaranm and Brian are proposing to lock
 ebuilds depending on slotted packages down to a single slot is the
 redefinition. And once again: This doesn't match reality.

You've misunderstand what is meant by locking ebuild dependencies. I gave 
you a definition in my second paragraph. Please have a re-read.

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



Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

2005-12-26 Thread Jason Stubbs
On Monday 26 December 2005 20:01, Jakub Moc wrote:
  Currently there are quite a few ebuilds in the tree that execute dodoc
  or dohtml for files that do not exist. I think it would be nice to have
  ebuilds die if this is the case. To not break current ebuilds this would
  only happen with FEATURES=stricter.

 Sigh... There are already bugs flowing in for TEXTRELs/executable stacks
 checks implemented in recent portage versions. Some of these bugs are
 completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc.
 etc.

Sigh... None of these issues have made there way to dev-portage.

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



Re: [gentoo-portage-dev] portage-2.1_pre2 and new use flag showing with emerge -p

2005-12-26 Thread Jason Stubbs
On Monday 26 December 2005 07:18, Petteri Räty wrote:
 I propose we improve the emerge -pv output to be something like the
 following:

 [ebuild U ] media-sound/alsa-driver-1.0.10-r1 [1.0.10] NEW=-debug
 OLD=-doc oss 0 kB

 This would keep the functionality with --verbose.

The NEW and OLD variables have no meaning. USE have been put there because any 
USE_EXPAND flags found in IUSE are represented separately. For example:

[ebuild   R   ] x11-base/xorg-x11-6.8.2-r6  USE=-bitmap-fonts cjk -debug 
-dlloader -dmx -doc font-server -insecure-drivers -ipv6 -minimal -nls -nocxx 
opengl -pam -sdk -static truetype-fonts -type1-fonts -xprint xv 
INPUT_DEVICES=-synaptics -wacom 44,520 kB

I doubt that the NEW and OLD would really be visible in the --verbose output 
in the general case anyway. How about just making added flags green to match 
the output of changed flags?

--
Jason Stubbs

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



Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

2005-12-25 Thread Jason Stubbs
On Monday 26 December 2005 08:14, Brian Harring wrote:
 On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote:
  Currently there are quite a few ebuilds in the tree that execute dodoc
  or dohtml for files that do not exist. I think it would be nice to have
  ebuilds die if this is the case. To not break current ebuilds this would
  only happen with FEATURES=stricter. This is what I currently do in my
  bashrc. Obviously when integreted to portage one can use helper
  functions like hasq which are not available in bashrc.
 
 
  if [[ ${FEATURES/stricter} != ${FEATURES} ]]; then
 
  _makefail() {
  bin=/usr/lib/portage/bin/${1}
  shift 1
  ${bin} [EMAIL PROTECTED] || die ${bin} [EMAIL PROTECTED] failed
  }
 
  dodoc() {   _makefail ${FUNCNAME} [EMAIL PROTECTED]; }
  dohtml() {  _makefail ${FUNCNAME} [EMAIL PROTECTED]; }

 Seems like more of a -dev discussion imo, since they're the ones
 affected by it (for us it's just an api change).

As a side note, dodoc didn't return non-zero when specified files don't exist 
up until a month or two ago. dohtml was updated yesterday. Hence, up until 
now the above was not possible.

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] per ebuild distdir symlinking

2005-12-25 Thread Jason Stubbs
On Monday 26 December 2005 07:12, Brian Harring wrote:
 Hola.

 Continuing the tradition of being a lazy bugger and raiding from my
 previous work instead of doing something new, attached is a patch that
 forces unpack to go through a level of indirection.
...
 Either way, it's attached.  Comments?

No problems on my part. As Mike said, it'll only catch the standard unpack 
usage but that's not really an issue as far as I can see.

By the way, now that we've got -commit mail, confirming with the ML isn't 
really necessary. Of course, if it's something you want to confirm...

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



Re: [gentoo-dev] Multiple Repo Support

2005-12-24 Thread Jason Stubbs
On Saturday 24 December 2005 12:58, Ciaran McCreesh wrote:
 On Sat, 24 Dec 2005 12:50:33 +0900 Jason Stubbs [EMAIL PROTECTED]

 wrote:
 | SLOT is currently an arbitrary string (without spaces) so general
 | matching of * might be useful. Of course, there's no restriction of
 | not using * in SLOTs at the moment either...

 *shrug* SLOT will have to be tightened up anyway. Otherwise
 SLOT=[foo] will cause terrible confusion.

Heh. Yep, that's another one. Checking with a quick script, it seems that 
there are 478 unique SLOTs and the regex [a-zA-Z0-9\._\-]* matches them all. 
Perhaps it would be worthwhile locking it down to those characters in repoman 
in preparation? Anybody see a need for characters beyond those?

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



Re: how to contribute to use/slot deps: was Re: [gentoo-dev] Multiple Repo Support

2005-12-24 Thread Jason Stubbs
On Sunday 25 December 2005 02:33, Ciaran McCreesh wrote:
 On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring [EMAIL PROTECTED]

 wrote:
 | It's really pretty simple- get off your butt and chip in if you want
 | it, else you're on _our_ timeline (eg, we implement it when we deem
 | it sane/ready to go).

 Is Portage development done to support the needs of those of us who
 provide the tree, or is the tree expected to be restricted to whatever
 Portage developers feel like implementing?

Neither. At least for myself, portage development is done to prioritized 
according to what I see as the needs of users. Needs of those of us who 
provide the tree are prioritized by how much benefit will be translated
to end users combined with how much work will be required.

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



[gentoo-dev] pkg_{pre,post}inst misusage

2005-12-23 Thread Jason Stubbs
Here's what we have:

app-office/qhacc/qhacc-3.4.ebuild:  [ -n ${PF} ]  rm -rf 
/usr/share/doc/${PF}
net-fs/samba/samba-3.0.14a-r2.ebuild:   rm -rf 
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.14a-r3.ebuild:   rm -rf 
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.20-r1.ebuild:rm -rf 
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.20a.ebuild:  rm -rf 
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.20b.ebuild:  rm -rf 
${ROOT}/usr/share/doc/${PF}
net-print/cups/cups-1.1.23-r3.ebuild:   rm -fR /usr/share/doc/${PF}
net-print/cups/cups-1.1.23-r4.ebuild:   [ -n ${PN} ]  rm -fR 
/usr/share/doc/${PN}-*
net-print/cups/cups-1.1.23-r5.ebuild:   [ -n ${PN} ]  rm -fR 
/usr/share/doc/${PN}-*


I'll let others do the yelling.

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



Re: [gentoo-dev] pkg_{pre,post}inst misusage

2005-12-23 Thread Jason Stubbs
On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
 Well, you should know that those are because of portage bugs or some
 portage peculiarity, read the corresponding bugs for example for cups
 to find out more.

Can you point me to a bug? There's no mention in the ChangeLog that I can see 
nor in the ebuilds themselves...

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



Re: [gentoo-dev] pkg_{pre,post}inst misusage

2005-12-23 Thread Jason Stubbs
On Friday 23 December 2005 21:39, Harald van Dijk wrote:
 On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote:
  On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
   Well, you should know that those are because of portage bugs or some
   portage peculiarity, read the corresponding bugs for example for cups
   to find out more.
 
  Can you point me to a bug? There's no mention in the ChangeLog that I can
  see nor in the ebuilds themselves...

 Bug #99375 is mentioned in the changelog for samba.

It still doesn't explain why it's necessary.

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] pkg_{pre,post}inst misusage

2005-12-23 Thread Jason Stubbs
On Friday 23 December 2005 21:39, Harald van Dijk wrote:
 On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote:
  On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
   Well, you should know that those are because of portage bugs or some
   portage peculiarity, read the corresponding bugs for example for cups
   to find out more.
 
  Can you point me to a bug? There's no mention in the ChangeLog that I can
  see nor in the ebuilds themselves...

 Bug #99375 is mentioned in the changelog for samba.

Okay. It appears to be something related to symlinks. Can you show me the bug 
assigned to portage that reports this and/or shows how to reproduce it?

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] pkg_{pre,post}inst misusage

2005-12-23 Thread Jason Stubbs
On Friday 23 December 2005 22:13, Harald van Dijk wrote:
 On Fri, Dec 23, 2005 at 10:00:20PM +0900, Jason Stubbs wrote:
  On Friday 23 December 2005 21:39, Harald van Dijk wrote:
   On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote:
On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
 Well, you should know that those are because of portage bugs or
 some portage peculiarity, read the corresponding bugs for example
 for cups to find out more.
   
Can you point me to a bug? There's no mention in the ChangeLog that I
can see nor in the ebuilds themselves...
  
   Bug #99375 is mentioned in the changelog for samba.
 
  Okay. It appears to be something related to symlinks. Can you show me the
  bug assigned to portage that reports this and/or shows how to reproduce
  it?

 Don't know if it's been reported as a portage bug, but this would show
 it:

 KEYWORDS=~x86
 src_install() {
   dodir /test
   dosym /usr/bin /test
 }

 When unmerging, portage won't remove /test/bin because its target still
 exists.

Seeing that there's no bug filed for this, discussion can go here; that's no 
existance of a portage bug is of itself no reason to put an ugly workaround 
in the ebuilds themselves mind you.

Symlinks are handled within portage differently to regular files. Regular 
files get an mtime check and are removed if it matches. Symlinks don't get an 
mtime check (even thought the mtime is stored) and are only removed if the 
symlink's target doesn't exist. Hence, it seems to be this way by design. Why 
it's this way? Who knows. It's been that way for longer than anyone can 
remember which is why _it's so important that bugs get filed_.

A quick patch makes symlinks handled similarly to regular files and solves the 
issue. I'll put it into testing unless anybody can come up with a reason not 
to. The case that will be broken by the patch is when two different packages 
install the same symlink. PackageA is installed, PackageB is installed, 
PackageB is uninstalled - PackageA is broken. Does this case exist?

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] pkg_{pre,post}inst misusage

2005-12-23 Thread Jason Stubbs
On Saturday 24 December 2005 02:52, Harald van Dijk wrote:
 On Sat, Dec 24, 2005 at 02:22:06AM +0900, Jason Stubbs wrote:
  Symlinks are handled within portage differently to regular files. Regular
  files get an mtime check and are removed if it matches. Symlinks don't
  get an mtime check (even thought the mtime is stored) and are only
  removed if the symlink's target doesn't exist. Hence, it seems to be this
  way by design. Why it's this way? Who knows. It's been that way for
  longer than anyone can remember which is why _it's so important that bugs
  get filed_.

 Honestly, I thought it was supposed to be like that, since
 collision-protect also doesn't protect against packages overwriting
 each other's symlinks (package A and package B can both create
 /dummy - bin without any problems from portage).

As far as portage source goes, it is meant to be like that. But as far as 
portage source goes, installed package information isn't necessary for dep 
calculation (including depclean)... Most code has been reviewed and the major 
issues are known by at least one person, but there is still some code that 
hasn't suffered a close examination (yet alone reworking) such as the code 
that the above bug hits.

 Do you want a bug report for that?

Yes, please.

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Multiple Repo Support

2005-12-23 Thread Jason Stubbs
On Saturday 24 December 2005 02:57, Paul de Vrieze wrote:
 On Friday 16 December 2005 18:54, Ciaran McCreesh wrote:
  On Fri, 16 Dec 2005 10:00:02 +0100 Danny van Dyk [EMAIL PROTECTED]
 
  wrote:
  | Just one remark: What about making the syntax a bit more familiar to
  | C++ users:
  |
  | ~  DEPENDS=gentoo-foo::foo-bar/baz-2.1
 
  That was my original thought when I started playing with it. I switched
  to postfix to make it more consistent with the way :slot and [use]
  restrictions work. *shrug* I guess it's down to whether you consider a

 Do those already work then? I'd like to be able to use them.

:slot and [use]? Not yet. I'm sure that once they do the shouts will be 
resounding across the globe such that it would not be possible for you to be 
unaware of it... ;)

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



Re: [gentoo-dev] Re: pkg_{pre,post}inst misusage

2005-12-23 Thread Jason Stubbs
On Saturday 24 December 2005 03:43, Duncan wrote:
 Jason Stubbs posted [EMAIL PROTECTED], excerpted

 below,  on Sat, 24 Dec 2005 02:22:06 +0900:
  A quick patch makes symlinks handled similarly to regular files and
  solves the issue. I'll put it into testing unless anybody can come up
  with a reason not to. The case that will be broken by the patch is when
  two different packages install the same symlink. PackageA is
  installed, PackageB is installed, PackageB is uninstalled - PackageA is
  broken. Does this case exist?

 Yikes!  That's not going to remove /lib or /usr/lib or the like, for us on
 amd64, where that's a symlink to lib64, will it?

 equery b /lib
 [ Searching for file(s) /lib in *... ]
 net-analyzer/macchanger-1.5.0-r1 (/lib)
 sys-apps/baselayout-1.12.0_pre12 (/lib)
 sys-boot/grub-0.97 (/lib)
 sys-devel/gcc-4.0.2-r1 (/lib)
 sys-devel/gcc-3.4.4-r1 (/lib)
 sys-fs/device-mapper-1.01.05 (/lib)
 sys-fs/lvm2-2.01.14 (/lib)
 sys-fs/udev-078 (/lib)
 sys-libs/glibc-2.3.6 (/lib)

 There's a similar, longer list, for  /usr/lib.  Obviously, not all of
 those will own it as a symlink, but it is one, and if removing one happens
 to remove the symlink...

I'm not familiar with equery so I don't know what this output means. By the 
look of it, it is only a list of packages that own stuff in that directory.

 Also consider the effect where a former dir is now a symlink or a former
 symlink is now a dir.  The recent xorg directory moves come to mind.

With the patch I've done, recorded symlinks will continue to be ignored if the 
target is not a symlink.

 You are /sure/ the new code won't screw anything of that sort up, right?
 Maybe that's the reason nobody seems to have been around to know about.
 It just sounds like it /could/ be dangerous to me.  For some reason, I
 don't like the idea of something that could hose a system that badly!  =8^\

*Please* don't tell me you run ~arch.

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



Re: [gentoo-dev] pkg_{pre,post}inst misusage

2005-12-23 Thread Jason Stubbs
On Saturday 24 December 2005 03:42, Thomas de Grenier de Latour wrote:
 On Sat, 24 Dec 2005 02:22:06 +0900

 Jason Stubbs [EMAIL PROTECTED] wrote:
  PackageA is installed, PackageB is installed, PackageB is
  uninstalled - PackageA is broken. Does this case exist?

 Found two on my system:

  * /usr/lib/X11/app-defaults - /etc/X11/app-defaults is
 installed by several X11 apps (media-gfx/xfig, x11-misc/seyon,
 x11-misc/xvkbd, and i would not be surprised there are others)

This looks like something that a lower level X ebuild should be installing. 
The problem here is that there's also a bit of funny business going on when 
portage encounters a merge of some filetype being blocked by a different 
filetype. In the above case, if some X11 package installs 
the /usr/lib/X11/app-defaults symlink and all other apps install 
to /etc/X11/app-defaults then everything should be fine.

  * /usr/share/cups/model/foomatic-ppds - /usr/share/ppd is
 installed by both net-print/foomatic-db and net-print/hplip.

Again, given the name of the symlink, net-print/hplip should probably be 
installing directly to /usr/share/ppd.

 Maybe this particular packages could be hacked to avoid need for
 the symlinks (or the symlinks should be installed only by some
 lower level, depended-on, packages?), but anyway it would be hard
 to do a strict sanity check of the whole tree. And letting that to
 collision-protect feature doesn't sound really like a short term
 solution neither. So, basically, i don't see how you could safely
 change this portage behavior atm (although i agree it would be a
 good thing once done).

Yep, it seems that changing the behaviour will lead to some breakage. However 
repoman is definately not capable of handling this sort of stuff. Also, none 
of the breakage (that you've revealed here at least) is that bad. Putting the 
relevant collision-protect changes into ~arch and following up with the 
actual unmerge changes should lead to minimal disruption on the user's side.

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



Re: [gentoo-dev] Multiple Repo Support

2005-12-23 Thread Jason Stubbs
On Saturday 24 December 2005 05:45, Spider (DmD Lj) wrote:
 On Sat, 2005-12-24 at 03:37 +0900, Jason Stubbs wrote:
  On Saturday 24 December 2005 03:23, Paul de Vrieze wrote:
   On Friday 23 December 2005 19:12, Ciaran McCreesh wrote:
On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze [EMAIL PROTECTED]
   
| Do those already work then? I'd like to be able to use them.
   
Not in anything end users should be using. The syntax is pretty much
decided upon though...
  
   Glad that they are comming though. Even though I'd probably not hold my
   breath.
 
  Trolling?

 Erm..  No, I don't think he is. We've been asking / waiting for the
 [use] syntax to appear since before you joined the project. It's been on
 the list for so long that many of us have given up... ; )

Yep, bug 2272.

 I don't think its trolling when we've been let down on it in the past,
 had it postponed to the great redesign  ( project baghira,  I think,
 too)   And so on.

Even though I'd probably not hold my breath? It's something that many people 
want but most are not evening willing to attempt implementing it. What was 
the purpose of that comment?

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



Re: [gentoo-portage-dev] [RFC] making the tree depend on portage

2005-12-20 Thread Jason Stubbs
On Tuesday 20 December 2005 01:49, Marius Mauch wrote:
 Also not talking about implementation details yet, just after comments
 about the general idea of forced portage updates.

I gave it a go anyway... ;)

# emerge -up kde-base/kde
Checking for mandatory system updates...  Done.

The following packages can't be merged until your system is updated:

   kde-base/kde

The following important packages are either not up to date or not installed:

   virtual/baselayout sys-apps/coreutils sys-apps/debianutils
   sys-apps/diffutils sys-apps/file sys-apps/findutils sys-apps/gawk 
   sys-apps/grep sys-apps/groff sys-apps/kbd sys-apps/man sys-apps/man-pages 
   sys-apps/net-tools =sys-apps/portage-2.0.51.22 sys-apps/sed 
   sys-apps/shadow sys-apps/texinfo sys-apps/which virtual/modutils 
   virtual/pager sys-apps/busybox sys-apps/hdparm sys-apps/util-linux 
   sys-apps/linux32 =sys-apps/baselayout-1.9.4-r7

Please retry your command after updating your system.


These are the packages that I would merge, in order:

Calculating system dependencies ...done!

[ebuild  N] sys-apps/sandbox-1.2.17
[ebuild  N] sys-apps/sed-4.1.4  USE=-bootstrap -build -nls -static
[ebuild  N] sys-apps/debianutils-2.15  USE=-build -static
[ebuild  N] sys-apps/portage-2.1_pre1  USE=-build
*** Portage will stop merging at this point and reload itself,
recalculate dependencies, and complete the merge.
You may avoid the remerging of packages by updating portage on its own.
[ebuild  N] sys-apps/help2man-1.35.1  USE=-nls
[ebuild  N] sys-apps/coreutils-5.3.0-r2  USE=-acl -build -nls -static
[ebuild  N] sys-apps/sysvinit-2.86-r3  USE=-bootstrap -build -ibm 
-static
[ebuild U ] sys-libs/readline-5.1 [5.0-r2]
[ebuild  N] sys-apps/baselayout-1.12.0_pre11-r3  USE=unicode -bootstrap 
-build -static
[ebuild  N] sys-apps/diffutils-2.8.7-r1  USE=-nls -static
[ebuild  N] sys-apps/file-4.16  USE=python -build
...
...


* Portage is moved to the top of both system and world
* All system atoms are checked that they are matched by installed packages
  and emerge refuses to do anything until unsatisfied atoms are installed 
  and/or updated.
* EMERGE_INSANITY_OK is provided for bootstrap.sh (and emerge itself) to 
  bypass the checks when the system is known to be in an incomplete state.

Reasoning on checking all system atoms is that other groups are just as likely 
to need the functionality as we are. Combining that with how rarely versions 
are actually updated for system packages, it shouldn't cause any more bother 
to users than it needs to.

--
Jason Stubbs
Index: bin/emerge
===
--- bin/emerge	(revision 2414)
+++ bin/emerge	(working copy)
@@ -1418,6 +1418,14 @@
 
 			mylist = sysdict.keys()
 
+		newlist = []
+		for atom in mylist:
+			if portage.dep_getkey(atom).split(/)[-1] == portage:
+newlist.insert(0, atom)
+			else:
+newlist.append(atom)
+		mylist = newlist
+		
 		for mydep in mylist:
 			try:
 if not self.select_dep(portage.root, mydep, raise_on_missing=True):
@@ -2501,6 +2509,73 @@
 if --debug in myopts:
 	edebug=1
 
+
+def check_and_update_system():
+	if os.environ.get(EMERGE_INSANITY_OK) or myaction == system:
+		return
+	rsync_timestamp = open(portage.settings[PORTDIR]+/metadata/timestamp).read().strip()
+	last_check = portage.mtimedb.get(last_system_check, )
+	if rsync_timestamp == last_check:
+		return
+	print Checking for mandatory system updates... ,
+	system_atoms = getlist(system)
+	vdb = portage.db[/][vartree].dbapi  # This check only applies to /
+	unsatisfied_atoms = [atom for atom in system_atoms if not vdb.match(atom)]
+	print Done.
+	if unsatisfied_atoms:
+		if myfiles:
+			allowed_keys = [portage.dep_getkey(atom) for atom in system_atoms]
+			virtuals = portage.settings.virtuals
+			for key in allowed_keys:
+if key in virtuals:
+	allowed_keys.extend(virtuals[key])
+			allowed_files = []
+			for myfile in myfiles:
+key = portage.dep_getkey(myfile)
+if key in allowed_keys:
+	allowed_files.append(myfile)
+	continue
+if / in myfile:
+	continue
+for category in portage.settings.categories:
+	if category+/+key in allowed_keys:
+		allowed_files.append(myfile)
+		break
+			disallowed_files = [myfile for myfile in myfiles if myfile not in allowed_files]
+			if disallowed_files:
+print red(\nThe following packages can't be merged until your system is updated:)
+width = 80
+for myfile in disallowed_files:
+	width += len(myfile) + 1
+	if width = 76:
+		width = 2
+		print \n  ,
+	print myfile,
+	myfiles.remove(myfile)
+print
+			if myfiles:
+return
+		print red(\nThe following important packages are either not up to date or not installed:)
+		width = 80
+		for atom in unsatisfied_atoms:
+			width += len(atom) + 1
+			if width = 76:
+width = 2
+print \n  ,
+			print atom,
+		print yellow(\n\nPlease retry your command

Re: [gentoo-portage-dev] [RFC] making the tree depend on portage

2005-12-20 Thread Jason Stubbs
On Tuesday 20 December 2005 23:15, Jason Stubbs wrote:
 On Tuesday 20 December 2005 01:49, Marius Mauch wrote:
  Also not talking about implementation details yet, just after comments
  about the general idea of forced portage updates.

 I gave it a go anyway... ;)

Also needed:

Index: portage.py
===
--- portage.py  (revision 2414)
+++ portage.py  (working copy)
@@ -6742,7 +6742,7 @@
 mtimedbkeys=[
 updates, info,
 version, starttime,
-resume, ldpath
+resume, ldpath, last_system_check
 ]
 mtimedbfile=root+var/cache/edb/mtimedb
 try:

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



Re: [gentoo-portage-dev] PATCH: parallel-fetch

2005-12-16 Thread Jason Stubbs
On Friday 16 December 2005 19:01, Brian Harring wrote:
 On Fri, Dec 16, 2005 at 12:09:10PM +0900, Jason Stubbs wrote:
  On Thursday 15 December 2005 20:06, Brian Harring wrote:
   This is the only blocker for merging parallel-fetch as far as I can
   tell- so... my vote is nuking the wait out of portage.portageexit
   (it's exec subsystem crap, belong in exec's atexit (where it exists)).
   Assuming no complaints there, issues with parallel-fetch going into
   svn?
 
  Nuking the wait is fine if things will still work the same.. I'm kind of
  wondering if ctrl-c'ing behaviour will change - how gets the ctrl-c
  first?

 ctrl-c doesn't come in play here- just triggers exithandler, which
 calls portageexit.  What's stupid about this code is that exithandler
 has it's *own* set of kill calls in it (nothing like 101 duplicated
 bits).

 Either way... exit, or nothing left to execute, python will then
 trigger atexit registered callbacks in a lifo manner.  So all
 exithandler really _should_ have to do is just sys.exit.

I mean for when a sub-process is running such as ebuild or rsync. Will portage 
get the SIGINT before or at the same time as the sub-process causing portage 
to then SIGKILL it while it's trying to exit cleanly? Given that portage's 
atexit handler is registered after portage_exec's, the subprocess reaping 
code would not have been doing anything in the past. I guess the question is 
more a general one rather than specifically related to background fetching.

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



Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

2005-12-14 Thread Jason Stubbs
On Wednesday 14 December 2005 09:52, Ciaran McCreesh wrote:
 On Wed, 14 Dec 2005 09:11:51 +0900 Jason Stubbs [EMAIL PROTECTED]

 wrote:
 | newsdir=$(portageq envvar PORTDIR)/metadata/news
 | newsdir=$(portageq newsdir gentoo)
 |
 | Both have one level of indirection. The first has two hard coded
 | elements. The first has one. Where is the massive over-indirection?
 |
 | The second allows future changes. The first does not. Where does the
 | specification come into it? All that would be needed is to allow a
 | user a method to name overlays and it'd be useful straight off the
 | bat.

 The former relies upon existing, widely used functionality together
 with a well-defined path. The latter has some magic hard-coded name
 voodoo (what's a 'gentoo'?) and is still stuck only supporting a single
 location.

What's a 'PORTDIR'? What's a 'metadata'? Outside of portage, these are also 
magic name voodoo. But I've grown tired of your imperfect circles. I think 
your design sucks and you think that my solution to making it not suck is too 
soon. The solution to that seems simple to me. Rather than have 'package 
manager' do anything, just have it provide hooks that will allow you to do 
your thing at the times you want. Good luck with solving the news in 
overlays bug when it comes in.

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



Re: [gentoo-dev] GLEP XX: Fix the GLEP process

2005-12-14 Thread Jason Stubbs
On Wednesday 14 December 2005 06:16, Grant Goodyear wrote:
 Jason Stubbs wrote: [Mon Dec 12 2005, 08:06:54PM CST]

  The purpose of GLEPs is to coordinate several teams into providing an
  overall enhancement to Gentoo. However, the GLEP itself is written by
  a single person rather than a cooperative effort between the teams.

 You know, there's no reason that GLEPs need to be written by a single
 person.  It's often true, though, that it is a single person's idea,
 initially at least.

Definitely. Ideas usually are a single person's eureka even if it comes 
through discussion with others.

  Specification
 
  Rather than coming to the ML with a completed GLEP and then asking for
  feedback, a GLEP author should look at the teams involved and then
  select a solicit a member from each team to be responsible for that
  area of the GLEP.  The GLEP author may represent any teams they belong
  to.

 Throwing out the initial GLEP amounts to the same thing, in my opinion,
 since any interested parties are urged to provide feedback, and ideally
 the next revision will include that feedback, either to accept it or
 reject it.

This is where it is falling down. The assumption is that somebody from each 
affected team happens to notice the post and have the time to reply before 
the GLEP goes too far. It also means that the goals and direction of the 
teams affected have no bearing on the initial revision of the GLEP. With the 
initial revision of the GLEP setting the direction in which it will head (or 
fizzle), the GLEP author is essentially handing tasks to various teams (which 
may conflict with their goals) if the initial revision draws enough support.

  Rationale
 
  Rather than doing lots of hard work and having it thrown away once it
  is found to be unacceptable by the teams involved, the teams involved
  share the hard work and come up with something acceptable to everybody
  right from the outset.

 Yes, of course, GLEP authors should talk to the folks who are likely to
 be affected beforehand, but if they fail to do so then the GLEP process
 is likely to be rather protracted for that GLEP.  I have to admit that I
 have no problem with people doing hard work for little gain, if that's
 what people want to do.  *Shrug*

Why go through all that stress? Given GLEP 41, how much effort should infra 
need to put into defending why the tasks initially set out by the GLEP author 
are impractical? Is a single email enough? Is a battle with the GLEP author 
required if the GLEP author disagrees? That's assuming of course that a 
response was quick enough. It's not only the GLEP authors whom are doing 
extra unnecessary work.

In addition as I missed out the signing off part from the inital post, should 
council members all be continually polling the lists for disagreement and 
marking it down in a notebook to be pulled out in time for when the GLEP is 
put to a vote? Or is it all just down to how convincingly the GLEP author 
speaks in the meeting where it is voted upon? Because there is no mechanism 
to ensure otherwise, the latter is inevitably the case.

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



Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

2005-12-13 Thread Jason Stubbs
On Tuesday 13 December 2005 11:45, Andrew Muraco wrote:
 Jason Stubbs wrote:
 On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote:
 On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs [EMAIL PROTECTED]
 
 wrote:
 | So what are you going to do? I asked already but you didn't answer.
 | How are you going to find $PORTDIR/metadata/news?
 
 At present, by using portageq with a hardcoded suffix. If in the future
 Portage introduces new functionality, then clients and the
 specification can easily be updated to handle said functionality.
 
 And how can that be adapted to work with overlays, completely ignoring the
 possibility of distinct repositories. Overlays is something that exists
 already and news support for them is a request that will appear as soon as
 news support is added.

 Your Point is Moot ... 

Interesting use of capitals.

 because an overlay (at present) is going to be exprimental software, 

or a repository from a non-English speaking community Gentoo site...

 (unsupported offically anyways) and so you _should_ know what risks your 
 taking,

except if your a new non-English-speaking user utilizing such a repository.

 this GLEP is to warn you about supported updates/changes which you _need_ to 
 know about.

This GLEP is about getting news regarding a set of ebuilds to the user. Making 
it only about the Gentoo supported tree serves no purpose.

 Why should an overlay need to have news if the user has the consciensely 
 update and maintain it to begin it.  

Because they already support package.mask, thirdpartymirrors, eclasses and 
just about anything else that exists in the supported tree.

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



Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

2005-12-13 Thread Jason Stubbs
On Tuesday 13 December 2005 11:48, Ciaran McCreesh wrote:
 On Tue, 13 Dec 2005 11:39:14 +0900 Jason Stubbs [EMAIL PROTECTED]

 wrote:
 | And how can that be adapted to work with overlays, completely
 | ignoring the possibility of distinct repositories. Overlays is
 | something that exists already and news support for them is a request
 | that will appear as soon as news support is added.

 Overlays don't contain metadata directories

There's nothing preventing this.

 and don't get synced,

As Zac pointed out, esync exists.

 so they don't contain news items.

Neither of the points above prevent an overlay from containing news items.

 Supporting news from multiple sources is something that's tied to supporting 
 packages from multiple sources, which overlay doesn't permit. 

Overlays are used for getting packages from multiple sources every day. The 
only thing preventing them from supporting getting news from multiple sources 
is your stubborness against adding a single level of indirection - a level of 
indirection that has absolutely no cost to readers.

 Fixing that would require fixing portage to support multiple repositories 
 rather than using overlay, which is an issue for a different GLEP.

I'll say it again. It wouldn't require a GLEP because the changes wouldn't go 
beyond portage. At least they wouldn't if you'd allow portage to keep its 
internals internal.

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



Re: [gentoo-dev] GLEP XX: Fix the GLEP process

2005-12-13 Thread Jason Stubbs
On Tuesday 13 December 2005 11:58, Ciaran McCreesh wrote:
 On Tue, 13 Dec 2005 11:39:49 +0900 Jason Stubbs [EMAIL PROTECTED]

 wrote:
 |  So... If, hypothetically speaking, someone were to write a GLEP
 |  saying move developer documentation into the QA group, restructure
 |  said documentation to this new format etc etc, and the QA group
 |  were in favour, and the developer community in general were in
 |  favour, and the council were in favour, and the people proposed by
 |  the GLEP to manage the new documentation were in favour, but the
 |  existing owners of the developer documentation were not, you're
 |  saying that it shouldn't be approved?
 |
 | Yes.

 Unworkable. Your proposal would allow a small group of obstinate
 developers to hold back progress. The problem here is that the council
 isn't acting as a decent last line of quality control when the GLEP
 authors fail to do their jobs properly. Your GLEP is trying to solve
 the wrong thing...

Wrong. I'll expand on the Yes now that I've got a few minutes... Actually, 
I'll turn that into a No. I misread the people proposed by the GLEP to 
manage the new documentation in my rush to leave for work this morning. The 
existing owners don't matter to the GLEP. They can continue to maintain the 
existing documentation if they wish. If you didn't have new people to 
maintain the new documentation however...

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



Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

2005-12-13 Thread Jason Stubbs
On Wednesday 14 December 2005 07:12, Grant Goodyear wrote:
 Jason Stubbs wrote: [Mon Dec 12 2005, 07:51:51PM CST]
   | As I said already, there will immediately be a bug asking for overlay
   | support. Portage already supports multiple in a form whether anybody
   | likes it or not. How they are supported and how they will change
   | should be of no concern to the glep. What should be of concern is
   | establishing a robust API between the readers and portage such that
   | future changes won't cause breakage.

 Wouldn't it suffice for the GLEP to simply have a statement that it will
 query portage for a list of repositories, once there's a way to do that,
 but until then the default repo will be assumed?

Modifications are required to portage anyway. Why postpone it until after 
several readers are written and force all of them become broken?

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



Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

2005-12-13 Thread Jason Stubbs
On Wednesday 14 December 2005 08:54, Ciaran McCreesh wrote:
 On Wed, 14 Dec 2005 08:44:39 +0900 Jason Stubbs [EMAIL PROTECTED]

 wrote:
 | Modifications are required to portage anyway. Why postpone it until
 | after several readers are written and force all of them become broken?

 Because there isn't a specification saying what the future changes to
 Portage will be, so supporting said future changes straight off would
 require a massively over-generalised, over-indirected solution.

newsdir=$(portageq envvar PORTDIR)/metadata/news
newsdir=$(portageq newsdir gentoo)

Both have one level of indirection. The first has two hard coded elements. The 
first has one. Where is the massive over-indirection?

The second allows future changes. The first does not. Where does the 
specification come into it? All that would be needed is to allow a user a 
method to name overlays and it'd be useful straight off the bat.

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



Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

2005-12-12 Thread Jason Stubbs
On Monday 12 December 2005 09:20, Ciaran McCreesh wrote:
 On Mon, 12 Dec 2005 09:11:53 +0900 Jason Stubbs [EMAIL PROTECTED]

 wrote:
 | Regardless of what you think about the current plans for multiple
 | repository support, the details that readers will need to know wont
 | change.

 Incorrect. Right now, readers should ignore news-blah.unread and only
 pay attention to news.unread. Readers will have to be updated to deal
 with multiple repositories whenever the multiple repositories GLEP is
 approved.

Incorrect. There needs to be no GLEP regarding multiple repository support in 
portage. There may need to be a GLEP regarding splitting up the portage tree 
into separate repositories, but that is nothing to do with the issue I'm 
talking about.

 |  | Even before multiple respositories are properly supported, I
 |  | guarantee bugs about support for this in portage overlays. With
 |  | the above, we would be able to add that support. Without it, all
 |  | we can do is put a big CANTFIX.
 | 
 |  Overlay is not the same as multiple repository support.
 |
 | There's no difference as far as readers go.

 Sure there is. there's no metadata/ directory in overlays.

Again, why I really don't like this design. You're asking portage to do crap 
to support external tools without looking to provide compatibilty with future 
portages. How are you planning to find the metadata directory in the first 
place?

 | Nope, which is why news.read shouldn't be specified.

 news.read is specified because there was demand for it the last time
 around. It's staying specified because the reasons given were based
 upon convincing use cases rather than random speculation.

Can you show a use case that crosses several readers?

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



Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

2005-12-12 Thread Jason Stubbs
On Tuesday 13 December 2005 02:16, Ciaran McCreesh wrote:
 On Mon, 12 Dec 2005 23:49:31 +0900 Jason Stubbs [EMAIL PROTECTED]

 wrote:
 | No need for a glep as far as portage support goes anymore than Ciaran
 | needs a glep to change or add syntax highlighting in vim.

 The difference is, Vim syntax scripts are well established, and there
 aren't any design issues to solve. Multiple repository support clearly
 *isn't* obvious, because the solution you've described is the wrong one.

Blah, blah, blah.

 | There doesn't need to be a debate. This whole proposal doesn't care
 | about portage compatibility whatsoever and it's exactly this style of
 | thinking that slows down portage development (which everybody loves
 | to complain about so much).

 Sure it does. It cares about the way Portage is currently, and it cares
 about any reasonable future Portage changes.

Bullshit.

 | As I said already, there will immediately be a bug asking for overlay
 | support. Portage already supports multiple in a form whether anybody
 | likes it or not. How they are supported and how they will change
 | should be of no concern to the glep. What should be of concern is
 | establishing a robust API between the readers and portage such that
 | future changes won't cause breakage.

 Ok, give me a list of every single future enhancement to Portage and
 I'll make sure the GLEP will be compatible with them.

Without a list of future features, you think the best way to go must be the 
least agile? As Zac said, all that matters to keep full compatibility on the 
side of the readers is to add a level of indirection. All your reasoning 
above falls apart in the face of that simple *logical* request.

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



[gentoo-dev] GLEP XX: Fix the GLEP process

2005-12-12 Thread Jason Stubbs
Abstract

The purpose of GLEPs is to coordinate several teams into providing an overall 
enhancement to Gentoo. However, the GLEP itself is written by a single person 
rather than a cooperative effort between the teams.


Motivation

Recent GLEPs have attempted to force things on other teams. This just doesn't 
work.


Specification

Rather than coming to the ML with a completed GLEP and then asking for 
feedback, a GLEP author should look at the teams involved and then select a 
solicit a member from each team to be responsible for that area of the GLEP. 
The GLEP author may represent any teams they belong to.


Rationale

Rather than doing lots of hard work and having it thrown away once it is found 
to be unacceptable by the teams involved, the teams involved share the hard 
work and come up with something acceptable to everybody right from the 
outset.


Backwards Compatibility

Nothing


Reference Implementation

Just do it.


Copyright

Public Domain
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP XX: Fix the GLEP process

2005-12-12 Thread Jason Stubbs
On Tuesday 13 December 2005 11:06, Jason Stubbs wrote:
 Abstract

 The purpose of GLEPs is to coordinate several teams into providing an
 overall enhancement to Gentoo. However, the GLEP itself is written by a
 single person rather than a cooperative effort between the teams.


 Motivation

 Recent GLEPs have attempted to force things on other teams. This just
 doesn't work.


 Specification

 Rather than coming to the ML with a completed GLEP and then asking for
 feedback, a GLEP author should look at the teams involved and then select a
 solicit a member from each team to be responsible for that area of the
 GLEP. The GLEP author may represent any teams they belong to.

A GLEP should list whom has been solicited and provide evidence that each has 
given their explicit approval of the GLEP. A GLEP without explicit approval 
of all teams involved cannot receive managerial approval.

 Rationale

 Rather than doing lots of hard work and having it thrown away once it is
 found to be unacceptable by the teams involved, the teams involved share
 the hard work and come up with something acceptable to everybody right from
 the outset.


 Backwards Compatibility

 Nothing


 Reference Implementation

 Just do it.


 Copyright

 Public Domain
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

2005-12-12 Thread Jason Stubbs
On Tuesday 13 December 2005 11:11, Ciaran McCreesh wrote:
 On Tue, 13 Dec 2005 10:51:51 +0900 Jason Stubbs [EMAIL PROTECTED]

 wrote:
 | Without a list of future features, you think the best way to go must
 | be the least agile? As Zac said, all that matters to keep full
 | compatibility on the side of the readers is to add a level of
 | indirection. All your reasoning above falls apart in the face of that
 | simple *logical* request.

 Every problem can be solved by adding another layer of indirection,
 except for the problem of having too many layers of indirection. This
 layer you are proposing is not going to do anything useful. It's merely
 adding indirection for the sake of it. There's no more need for this
 than there is need for a two thousand line XML DTD which allows us to
 specify the author's date of birth using an ancient Sumerian calendar.

 Come up with a full specification of how Portage will handle multiple
 repositories, and get that specification agreed upon by the people who
 will end up having to use it. *Then* come back and ask me to add in
 more complexity. I'm not going to over-complicate things to deal with
 random hypothetical half-baked speculation.

So what are you going to do? I asked already but you didn't answer.
How are you going to find $PORTDIR/metadata/news?

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



Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

2005-12-12 Thread Jason Stubbs
On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote:
 On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs [EMAIL PROTECTED]

 wrote:
 | So what are you going to do? I asked already but you didn't answer.
 | How are you going to find $PORTDIR/metadata/news?

 At present, by using portageq with a hardcoded suffix. If in the future
 Portage introduces new functionality, then clients and the
 specification can easily be updated to handle said functionality.

And how can that be adapted to work with overlays, completely ignoring the 
possibility of distinct repositories. Overlays is something that exists 
already and news support for them is a request that will appear as soon as 
news support is added.

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



Re: [gentoo-dev] GLEP XX: Fix the GLEP process

2005-12-12 Thread Jason Stubbs
On Tuesday 13 December 2005 11:24, Ciaran McCreesh wrote:
 On Tue, 13 Dec 2005 11:15:43 +0900 Jason Stubbs [EMAIL PROTECTED]

 wrote:
 | A GLEP should list whom has been solicited and provide evidence that
 | each has given their explicit approval of the GLEP. A GLEP without
 | explicit approval of all teams involved cannot receive managerial
 | approval.

 So... If, hypothetically speaking, someone were to write a GLEP saying
 move developer documentation into the QA group, restructure said
 documentation to this new format etc etc, and the QA group were in
 favour, and the developer community in general were in favour, and the
 council were in favour, and the people proposed by the GLEP to manage
 the new documentation were in favour, but the existing owners of the
 developer documentation were not, you're saying that it shouldn't be
 approved?

Yes.

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



Re: [gentoo-dev] The deal with epkgmove

2005-12-10 Thread Jason Stubbs
On Sunday 11 December 2005 00:56, Luca Barbato wrote:
 svn so far was good but I don't know which big projects had it deployed.

KDE uses subversion, depending on what you call big of course.

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



Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

2005-12-10 Thread Jason Stubbs
On Sunday 11 December 2005 10:35, Ciaran McCreesh wrote:
 Whenever relevant unread news items are found, the package manager will
 create a file named ``/var/lib/portage/news/news.unread`` (if it does not
 already exist) and append the news item identifier (eg
 ``2005-11-01-yoursql-updates``) on a new line.

 .. Note:: Future changes to Portage involving support for multiple
 repositories may require one news list per repository. Assuming
 repositories have some kind of unique identifier, this file could be named
 ``news-repoid.unread``.

Repositories will definitely have a unique identifier. Perhaps it would be 
better to use the repository-identifing format from the beginning so that 
readers are forced to be forwards-compatible? Assuming the readers would then 
output the repository name, labeling it gentoo should work well...

 When a news item is read, its name should be removed from the
 ``news.unread`` file. News clients may add the name to a ``news.read`` file
 in the same directory with the same file format.

news.read should either be mandatory or not created at all. Should a user 
change from a reader that creates and uses the file to one that doesn't and 
then change back again the results will be unexpected.

 * Important: there are 5 unread news items.
 * Type emerge --help news to learn how to read news files.
[...]
 An ``eselect`` [#eselect]_ module shall be created as the 'suggested'
 display tool; other display tools (for example, a news to email forwarder,
 which would be ideal for users who sync on a ``cron``) are left as options
 for those who desire them.

By suggested you mean that it should be referenced in the news help?

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



Re: [gentoo-portage-dev] DepSet

2005-12-08 Thread Jason Stubbs
On Thursday 08 December 2005 16:44, Zac Medico wrote:
 The middle hunk fixes a problem with block atoms that do not match any 
 packages.  Previously, these atoms would not make it into the okay_atoms set 
 which caused unresolved dependencies.  

Are you sure about this? For reference:

@@ -58,12 +58,19 @@
all_atoms.union_update(atomset)
okay_atoms = sets.Set()
for atom in all_atoms:
+   have_blocker=False
for child in self.pkgs:
if atom.key != child.key:
continue
-   if atom.match(child) ^ atom.blocks:
-   okay_atoms.add(atom)
+   if atom.match(child):
+   if atom.blocks:
+   have_blocker=True
+   else:
+   okay_atoms.add(atom)
break
+   if atom.blocks and not have_blocker:
+   # block atom that does not match any 
packages
+   okay_atoms.add(atom)
for choice in self.pkgs[pkg][0]:
if choice.issubset(okay_atoms):
break


if atom.match(child) ^ atom.blocks:
okay_atoms.add(atom)
break

is the same as:

if (atom.match(child) and not atom.blocks) or \
(not atom.match(child) or atom.blocks):
okay_atoms.add(atom)
break


have_blocker = False
...
if atom.match(child):
if atom.blocks:
have_blocker=True
else:
okay_atoms.add(atom)
break
if atom.blocks and not have_blocker:
okay_atoms.add(atom)

Therefore:

have_blocker = atom.blocks and atom.match(child)

which makes the last check:

if atom.blocks and not (atom.blocks and atom.match(child)):
okay_atoms.add(atom)

which is equivalent to:

if atom.blocks and (not atom.blocks or not atom.match(child)):
okay_atoms.add(atom)

Removing the impossibility of atom.blocks and not atom.blocks:

if atom.blocks and not atom.match(child):
okay_atoms.add(atom)

Within the loop you have:

if atom.match(child):
if atom.blocks:
...
else:
okay_atoms.add(atom)
break

Which could be represented as:

if atom.match(child) and not atom.blocks:
okay_atoms.add(atom)

Combining those two gives:

if atom.blocks and not atom.match(child) or \
atom.match(child) and not atom.blocks:
okay_atoms.add(atom)

Which is exactly the same thing as the original except seven lines longer...

--
Jason Stubbs

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



  1   2   3   >