[gentoo-dev] RFC about another *DEPEND variable

[Alin Nastac]

I'm annoyed about impossibility to fix a certain class of breakages
(other than reemerging the failing package). I am referring to the
breakages occurred when foo has been upgraded, but the bar package
cannot work with it because it was build against the old foo version.

We all had to run revdep-rebuild once in awhile, for fixing dynamic
linkage problems, but unfortunately revdep-rebuild cannot fix another
kind of incompatibility, namely dynamic version check implemented in
some packages.
For instance, the recent openssl-0.9.8* update broke dev-libs/neon (and
consequently subversion) because neon library isn't happy just by
linking with libssl.so.0.9.7 but also check the libssl version when
loads the ssl library. Another example is the subtle dependency between
the pppd version and pppd plugins (net-dialup/pptpd needs to be rebuild
every time you change PV of the net-dialup/ppp because pptpd builds a
plugin for the ppp daemon).

I reckon this could be solved by yet another *DEPEND variable. The only
atoms accepted by this variable would be "CATEGORY/PN". Every time when
a package gets updated from PV1 to PV2 (distinct versions, revisions
will not count), portage will automatically re-emerge those packages
that depend on it.

Thoughts?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Luca Barbato]

Alin Nastac wrote:

I reckon this could be solved by yet another *DEPEND variable. The only
atoms accepted by this variable would be "CATEGORY/PN". Every time when
a package gets updated from PV1 to PV2 (distinct versions, revisions
will not count), portage will automatically re-emerge those packages
that depend on it.

Thoughts?



It would require revdep resolution on emerge... how painful would be?

lu

--

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC about another *DEPEND variable

[Brian Harring]

On Thu, Sep 21, 2006 at 01:38:59PM +0200, Luca Barbato wrote:
> Alin Nastac wrote:
> >I reckon this could be solved by yet another *DEPEND variable. The only
> >atoms accepted by this variable would be "CATEGORY/PN". Every time when
> >a package gets updated from PV1 to PV2 (distinct versions, revisions
> >will not count), portage will automatically re-emerge those packages
> >that depend on it.
> >
> >Thoughts?
> >
> 
> It would require revdep resolution on emerge... how painful would be?

Off the top of my head, adding revdeps (period) for unmerge 
functionality (fex) is the harder part; slipping something of this 
sort in is just a logic tweak.

The problem with this proposal however is that it's attempting 
automatic revdep based off of version; _any_ non-rev version bump is 
way too rebuild happy.

Proposal I was pushing a while back was addition of a metadata key; 
it's not exactly .so version, but pretty close- a _manually_ 
maintained counter var in the ebuild that represents the abi 
compatibility for that packages versions.

Example would be openssl-0.9.7, you stick BINCOMPAT=0.9.7 in it, 
in openssl-0.9.8, you stick BINCOMPAT=0.9.8 in it, for a replace op 
the resolver sees that it's breaking compatibility and knows to 
rebuild any revdeps.

Why have the explicit var?  Because 0.9.7a through 0.9.7c may all be 
compatible, but 0.9.7d isn't.  If you force an automatic algo that 
tries to (effectively) guess, you get a lot of rebuilds through a,b,c, 
end result being folks likely update less because it becomes a bigger 
pain in the ass.

There is one flaw with this though; packages can provide both 
libraries _and_ binaries.  Our dependencies don't represent whether 
the dep is actual linkage, or just commandline consuming, so (using 
the openssl example) any package that invokes openssl via the 
commandline to do a few simple chksum ops gets rebuilt, despite the 
fact it wasn't affected by linkage change ups.

So... short version, at least what jstubbs/marius/myself hashed out in 
irc a long while back, need binding dependencies and actual tracking 
of the lib breakage in the metadata.

Alternative to shoving an extra key in would be extending slot rules, 
but that can be somewhat ugly.

My 2 cents, for what its worth.
~harring


pgpQ0KLtqw55W.pgp
Description: PGP signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Alin Nastac]

Luca Barbato wrote:
> Alin Nastac wrote:
>> I reckon this could be solved by yet another *DEPEND variable. The only
>> atoms accepted by this variable would be "CATEGORY/PN". Every time when
>> a package gets updated from PV1 to PV2 (distinct versions, revisions
>> will not count), portage will automatically re-emerge those packages
>> that depend on it.
>>
>> Thoughts?
>>
>
> It would require revdep resolution on emerge... how painful would be?
>
I don't know anything about portage intricacies, but I guess it would be
fairly easy to have a map of CATEGORY1/PN1 -> CATEGORY2/PN2 key-values,
where package 2 depends on package 1 (package 2 is the one that defines
the xxxDEPEND variable). In order to add such (key, value) in the map
the following assumptions must be satisfied:
   - package 2 must be installed (mandatory)
   - package 1 must be a direct or indirect RDEPEND dependency of the
package 2 (optional).




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] The Seed Project - Try 2

[Lance Albertson]

Donnie Berkholz wrote:

>> 3) Mirror storage seemed to be an issue.  There are plenty of
>> offerings from the adopt-a-dev project for bandwidth and server space
>> that I think could be utilized to suit this and let release
>> engineering utilize the official space for their releases.
> 
> Seems to me the torrent server would handle this nicely.

Only problem is that our current torrent server is lacking in storage
space. Infra should be notified before they actually release any
tarballs. I surely hope that Stuart doesn't expect to to host those
tarballs on the current overlays.g.o machine because that upstream
provider is limited on our bandwidth usage.

From my point of view, it would have been nice to have at least been
asked what infra could do to host these tarballs down the road. That
way, we have a sound plan of doing a good release when they're ready. I
don't like the idea of them springing a release and then asking us to
host it in a week. Things like this need to be planned from an infra
point of view, just like releases from releng are.

Anyways...

Stuart: When you get a chance, can you please either message me on irc
or send em an email with your thoughts on how hosting might work so we
can start planning that?

Thanks-

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] GLEP updates

[Marius Mauch]

Sorry for the late reply, had some problem with my mail setup recently.

On Sun, 3 Sep 2006 22:53:44 -0500
Grant Goodyear <[EMAIL PROTECTED]> wrote:

> Thanks to atarus, I've updated a number of GLEPs:
> 
> 40 (arch teams)   Now marked Final
> 44 (manifest2)Now marked Final

I wouldn't consider manifest2 final yet. If you look at the "Backwards
compability" section we're currently between steps 2 and 3 in the
migration process (atm about 60-70% of the tree are manifest2 ready,
see dev.gentoo.org/enone/reports/mf2 )

> I believe that GLEPs 14 (GLSA security updates), 23 (ACCEPT_LICENSE),
> and 33 (eclass ELIB) are being worked on, but it would greatly
> appreciate confirmation (and the names of the folks currently working
> on them if it's different from the GLEP authors).
> 
> I'm adding a new key, "M" for "moribund", that will identify GLEPs
> that have been accepted, but never implemented.  If there's any sign
> of life in such a GLEP, I'll happily change the "M" back to an "A".

Glep 14 currently waits for a working set implementation (the backend
code for glep 21), so it's stalled until glep 21 is finished.

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

Re: [gentoo-dev] The Seed Project - Try 2

[Lance Albertson]

Mike Frysinger wrote:

>> 3) Mirror storage seemed to be an issue.  There are plenty of offerings
>> from the adopt-a-dev project for bandwidth and server space that I think
>> could be utilized to suit this and let release engineering utilize the
>> official space for their releases.
> 
> isnt it an issue only once you have something to actually release ?  some 
> people may prefer to lay infrastructure first, but i'd rather let something 
> prove itself out so that infrastructure is laid and then not ever utilized 
> (not to imply anything about this project's future)

Except that where do you host those first few releases? I'm pretty sure
we can stick them in experimental, but for the long run infra should be
in communication with this group so that we can make an effective plan
on hosting.

Thanks-

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Notification about MD5 support

[Marius Mauch]

Ferringb recently told me that this info apparently wasn't
mentioned explicit enough in Glep 44:

Manifest2 records do not contain a MD5 checksum. The only guaranteed
checksum type there is SHA1. So once manifest1 is phased out the tree
will not contain MD5 checksums anymore.

This is just a reminder, not a request for discussion (unless you
have a *really* good reason why MD5 is still needed)

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

Re: [gentoo-dev] The Seed Project - Try 2

[Stuart Herbert]

On 9/21/06, Lance Albertson <[EMAIL PROTECTED]> wrote:

Stuart: When you get a chance, can you please either message me on irc
or send em an email with your thoughts on how hosting might work so we
can start planning that?


Lance: Will do.

Everyone else: Please stop speculating about how we're going to host
and distribute seeds.  We're a long way off from having a releasable
seed to worry about.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] The Seed Project - Try 2

[Mike Frysinger]

On Thursday 21 September 2006 09:27, Lance Albertson wrote:
> Mike Frysinger wrote:
> >> 3) Mirror storage seemed to be an issue.  There are plenty of offerings
> >> from the adopt-a-dev project for bandwidth and server space that I think
> >> could be utilized to suit this and let release engineering utilize the
> >> official space for their releases.
> >
> > isnt it an issue only once you have something to actually release ?  some
> > people may prefer to lay infrastructure first, but i'd rather let
> > something prove itself out so that infrastructure is laid and then not
> > ever utilized (not to imply anything about this project's future)
>
> Except that where do you host those first few releases? I'm pretty sure
> we can stick them in experimental, but for the long run infra should be
> in communication with this group so that we can make an effective plan
> on hosting.

we arent talking even experimental releases, we're talking internal builds
-mike


pgps88BuWqHzZ.pgp
Description: PGP signature

Re: [gentoo-dev] Notification about MD5 support

[Mike Frysinger]

On Thursday 21 September 2006 09:34, Marius Mauch wrote:
> Manifest2 records do not contain a MD5 checksum. The only guaranteed
> checksum type there is SHA1. So once manifest1 is phased out the tree
> will not contain MD5 checksums anymore.

by "guaranteed" do you mean "guaranteed to be in the records" ?  SHA1 has 
proven to be "insecure" like MD5
-mike


pgpQStoxBKwvE.pgp
Description: PGP signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Mike Frysinger]

On Thursday 21 September 2006 06:35, Alin Nastac wrote:
> For instance, the recent openssl-0.9.8* update broke dev-libs/neon (and
> consequently subversion) because neon library isn't happy just by
> linking with libssl.so.0.9.7 but also check the libssl version when
> loads the ssl library. Another example is the subtle dependency between
> the pppd version and pppd plugins (net-dialup/pptpd needs to be rebuild
> every time you change PV of the net-dialup/ppp because pptpd builds a
> plugin for the ppp daemon).

i guess you're referring to the plugins eh ?  this was proposed some time ago 
by eradicator but i dont know where that development track left off (my guess 
is nowhere significant)
-mike


pgpbSBwac2PGR.pgp
Description: PGP signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Mike Frysinger]

On Thursday 21 September 2006 07:59, Brian Harring wrote:
> Why have the explicit var?  Because 0.9.7a through 0.9.7c may all be
> compatible, but 0.9.7d isn't.  If you force an automatic algo that
> tries to (effectively) guess, you get a lot of rebuilds through a,b,c,
> end result being folks likely update less because it becomes a bigger
> pain in the ass.

if it isnt compatible then it shouldnt have the same SONAME, simple as 
that ... that is after all the point of encoding the ABI version number into 
the SONAME

forcing devs to maintain a manual var which is basically duplicating the 
SONAME smells like maintenance nightmare
-mike


pgpotWD8NW3lp.pgp
Description: PGP signature

Re: [gentoo-dev] Notification about MD5 support

[Brian Harring]

On Thu, Sep 21, 2006 at 09:49:18AM -0400, Mike Frysinger wrote:
> On Thursday 21 September 2006 09:34, Marius Mauch wrote:
> > Manifest2 records do not contain a MD5 checksum. The only guaranteed
> > checksum type there is SHA1. So once manifest1 is phased out the tree
> > will not contain MD5 checksums anymore.
> 
> by "guaranteed" do you mean "guaranteed to be in the records" ?  SHA1 has 
> proven to be "insecure" like MD5

Guranteed to be in the chksum data; iow, when manifest2 is switched 
over to fully all manifest1/digest data becomes effectively invisible 
to portage and is filtered out on commits.

So... what's guranteed in manifest2 now is just sha1.  In reality, it 
holds size/sha1/sha256/rmd160 per file entry.
~harring


pgpL4A2RE3qP4.pgp
Description: PGP signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Brian Harring]

On Thu, Sep 21, 2006 at 09:52:27AM -0400, Mike Frysinger wrote:
> On Thursday 21 September 2006 07:59, Brian Harring wrote:
> > Why have the explicit var?  Because 0.9.7a through 0.9.7c may all be
> > compatible, but 0.9.7d isn't.  If you force an automatic algo that
> > tries to (effectively) guess, you get a lot of rebuilds through a,b,c,
> > end result being folks likely update less because it becomes a bigger
> > pain in the ass.
> 
> if it isnt compatible then it shouldnt have the same SONAME, simple as 
> that ... that is after all the point of encoding the ABI version number into 
> the SONAME
> 
> forcing devs to maintain a manual var which is basically duplicating the 
> SONAME smells like maintenance nightmare

I agree; while I'm labeling it ABI, includes both bad soname handling 
and seperate sonames.

Re: forcing devs... the request was to fold revdep-rebuild into 
resolution; in other words, 3 options
1) situation gets ignored, stays as is
2) all packages are somehow fixed (ultra restrictive deps) to never 
require revdep-rebuild
3) revdep-rebulid capabilities get inline into resolution.

Feel free to point out a 4th option if I'm missing it, but for the 
request, that's what exists afaict; meanwhile, stating that pkgs are 
being stupid, while true, doesn't actually solve the issue :)

~harring


pgpj0tlMIO7jl.pgp
Description: PGP signature

Re: [gentoo-dev] Notification about MD5 support

[Mike Frysinger]

On Thursday 21 September 2006 10:00, Brian Harring wrote:
> On Thu, Sep 21, 2006 at 09:49:18AM -0400, Mike Frysinger wrote:
> > On Thursday 21 September 2006 09:34, Marius Mauch wrote:
> > > Manifest2 records do not contain a MD5 checksum. The only guaranteed
> > > checksum type there is SHA1. So once manifest1 is phased out the tree
> > > will not contain MD5 checksums anymore.
> >
> > by "guaranteed" do you mean "guaranteed to be in the records" ?  SHA1 has
> > proven to be "insecure" like MD5
>
> Guranteed to be in the chksum data; iow, when manifest2 is switched
> over to fully all manifest1/digest data becomes effectively invisible
> to portage and is filtered out on commits.
>
> So... what's guranteed in manifest2 now is just sha1.  In reality, it
> holds size/sha1/sha256/rmd160 per file entry.

ok, but it just seems silly to go cutting MD5 but leaving SHA1 ... if we're 
going to be leaving an insecure format, we might as well keep the one that is 
a virtual standard in and of itself (MD5)
-mike


pgpUZchLpMQ0h.pgp
Description: PGP signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Donnie Berkholz]

Mike Frysinger wrote:

On Thursday 21 September 2006 07:59, Brian Harring wrote:

Why have the explicit var?  Because 0.9.7a through 0.9.7c may all be
compatible, but 0.9.7d isn't.  If you force an automatic algo that
tries to (effectively) guess, you get a lot of rebuilds through a,b,c,
end result being folks likely update less because it becomes a bigger
pain in the ass.


if it isnt compatible then it shouldnt have the same SONAME, simple as 
that ... that is after all the point of encoding the ABI version number into 
the SONAME


forcing devs to maintain a manual var which is basically duplicating the 
SONAME smells like maintenance nightmare


Not adding it into the ebuild means that it's impossible to show in 
advance what packages will actually be installed, because you don't know 
whether the sover will bump.


Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] gnutls-1.4.4 unmasked and becoming stable

[Daniel Black]

As previously mentioned versions prior to gnutls-1.4.4 have an outstanding 
security bug https://bugs.gentoo.org/show_bug.cgi?id=147682.

This package (gnutls-1.4.4), and (libtasn1-0.3.5), have now been unmasked and 
some are stabled.

After emerging these packages a revdep-rebuild will be required for packages 
that link against gnutls (and libtasn1) to work.

If any package fails to build against the newer gnutls please file a bug at 
bugs.gentoo.org.

-- 
Daniel Black <[EMAIL PROTECTED]>
Gentoo Foundation
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC about another *DEPEND variable

[Alin Nastac]

Brian Harring wrote:
> On Thu, Sep 21, 2006 at 01:38:59PM +0200, Luca Barbato wrote:
>   
> There is one flaw with this though; packages can provide both 
> libraries _and_ binaries.  Our dependencies don't represent whether 
> the dep is actual linkage, or just commandline consuming, so (using 
> the openssl example) any package that invokes openssl via the 
> commandline to do a few simple chksum ops gets rebuilt, despite the 
> fact it wasn't affected by linkage change ups.
>   
I like BINCOMPAT proposal but it solves only half of the problem. You
assume that all dependent packages cares about binary compatibility.
Why not using a BDEPEND var in those dependent packages affected by the
BINCOMPAT values of their dependencies?

For instance, I would set the following:
 - in net-dialup/ppp ebuild: BINCOMPAT=${PV}
 - in net-dialup/pptpd ebuild:   BDEPEND="net-dialup/ppp"




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Mike Frysinger]

On Thursday 21 September 2006 10:14, Donnie Berkholz wrote:
> Not adding it into the ebuild means that it's impossible to show in
> advance what packages will actually be installed, because you don't know
> whether the sover will bump.

sometimes you dont know as the ABI bump may be arch or feature specific ... 
pathological case i agree ;)

you would certainly know between the time you merge the new one and unmerge 
the old one though ... but now we tread into the territory of "portage should 
not unmerge ABI libraries until all consumers have been destroyed" which is 
better than the current craptastic situation of "you gotta revdep-rebuild 
after the fact with a broken system"
-mike


pgpAf6pcdhThy.pgp
Description: PGP signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Mike Frysinger]

On Thursday 21 September 2006 10:04, Brian Harring wrote:
> I agree; while I'm labeling it ABI, includes both bad soname handling
> and seperate sonames.

those people should be smacked (for the interest of disclosure, i have 
violated the "bad soname" rule for the sake of following upstream)

> Feel free to point out a 4th option if I'm missing it, but for the
> request, that's what exists afaict; meanwhile, stating that pkgs are
> being stupid, while true, doesn't actually solve the issue :)

4) portage maintains a list of ABI SONAMEs in use and does not unmerge the 
library until all consumers are gone

i'm referring to the specific file of course, not anything else in the 
package ... so integrating the hack eutils.eclass:preserve_old_lib() into 
portage so it isnt a hack (not a knock against the current implementation 
here; it's always going to be a hack until portage manages proper unmerging 
of the ABI library)
-mike


pgpkGngJWrBQP.pgp
Description: PGP signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Mike Frysinger]

On Thursday 21 September 2006 10:38, Alin Nastac wrote:
> Brian Harring wrote:
> > There is one flaw with this though; packages can provide both
> > libraries _and_ binaries.  Our dependencies don't represent whether
> > the dep is actual linkage, or just commandline consuming, so (using
> > the openssl example) any package that invokes openssl via the
> > commandline to do a few simple chksum ops gets rebuilt, despite the
> > fact it wasn't affected by linkage change ups.
>
> I like BINCOMPAT proposal but it solves only half of the problem. You
> assume that all dependent packages cares about binary compatibility.
> Why not using a BDEPEND var in those dependent packages affected by the
> BINCOMPAT values of their dependencies?
>
> For instance, I would set the following:
>  - in net-dialup/ppp ebuild: BINCOMPAT=${PV}
>  - in net-dialup/pptpd ebuild:   BDEPEND="net-dialup/ppp"

i think you're merging the two issues you brought up ... there is binary ABI 
issues (which should not require a new DEPEND variable as portage can extract 
that information out at runtime) and there is runtime plugin issues with 
packages using dlopen() (which portage cannot extract as the dependency 
cannot ever be extracted)

or did i not read your original e-mail incorrectly ?
-mike


pgpzT9ZX7vRoe.pgp
Description: PGP signature

Re: [gentoo-dev] Notification about MD5 support

[Vlastimil Babka]

Mike Frysinger wrote:
ok, but it just seems silly to go cutting MD5 but leaving SHA1 ... if we're 
going to be leaving an insecure format, we might as well keep the one that is 
a virtual standard in and of itself (MD5)

-mike


GLEP 44 says:

For compability though we have to rely on at least one hash function to 
always be present, this proposal suggest to use SHA1 for this purpose 
(as it is supposed to be more secure than MD5 and currently only SHA1 
and MD5 are directly available in python, also MD5 doesn't have any 
benefit in terms of compability).



Although the "more secure than MD5" part is now questionable, I suppose 
the "directly available in python" part still holds? One point of the 
GLEP is to make tree smaller, so why keep more insecure formats when the 
room they would occupy can be used for more secure formats like 
sha256/512, although those can't be deemed the mandatory ones because 
they're not directly in python.
So if both MD5 and SHA1 are now insecure but one of them needs to be the 
mandatory one, the question is, is it still harder to crack SHA1 than 
MD5? If yes, then just forget MD5.


--
Vlastimil Babka (Caster)
Gentoo/Java
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC about another *DEPEND variable

[Donnie Berkholz]

Mike Frysinger wrote:

On Thursday 21 September 2006 10:14, Donnie Berkholz wrote:

Not adding it into the ebuild means that it's impossible to show in
advance what packages will actually be installed, because you don't know
whether the sover will bump.


sometimes you dont know as the ABI bump may be arch or feature specific ... 
pathological case i agree ;)


you would certainly know between the time you merge the new one and unmerge 
the old one though ... but now we tread into the territory of "portage should 
not unmerge ABI libraries until all consumers have been destroyed" which is 
better than the current craptastic situation of "you gotta revdep-rebuild 
after the fact with a broken system"


Yes, I agree with you. For example, take expat. The maintainers have 
refused to allow both versions to exist simultaneously on a system 
because it apparently causes more breakage than just breaking every app 
on your system by removing .so.0.


Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC about another *DEPEND variable

[Duncan Coutts]

On Thu, 2006-09-21 at 09:52 -0400, Mike Frysinger wrote:
> On Thursday 21 September 2006 07:59, Brian Harring wrote:
> > Why have the explicit var?  Because 0.9.7a through 0.9.7c may all be
> > compatible, but 0.9.7d isn't.  If you force an automatic algo that
> > tries to (effectively) guess, you get a lot of rebuilds through a,b,c,
> > end result being folks likely update less because it becomes a bigger
> > pain in the ass.
> 
> if it isnt compatible then it shouldnt have the same SONAME, simple as 
> that ... that is after all the point of encoding the ABI version number into 
> the SONAME
> 
> forcing devs to maintain a manual var which is basically duplicating the 
> SONAME smells like maintenance nightmare

There are various kinds of ABI. Certainly for C libs the SONAME is
probably the most common. If we go for some kind of ABI reverse deps
feature I would beg for something a little more general - though
certainly with SONAME as a common case.

Other languages have similar problems. For example Python has
incompatible ABIs for each major release 2.2, 2.3 etc. They have a
similar solution to the revdep-rebuild: python-updater.

As lead of the Haskell team my interest in this is that our primary
Haskell compiler GHC has ABI incompatibility between versions too. We've
made a ghc-updater similar in style to the python one but this is
clearly an unsatisfactory situation. It's more acute for us as even
minor revisions are ABI-incompatible.

So for it's something like:
# for C:
ABI=${SONAME}

# for python
ABI=${PY_PV}

# for haskell:
ABI=${GHC_PV}

paludis has something going in this direction but I don't think it'd
quite solve the python/ghc abi issue. It was aimed more at cases like
mips with it's multiple abis.

If we do go in this direction it'd be great to be able to slot on the
ABI and still have dependencies resolved correctly. For example imagine
having parallel python-2.3 and 2.4 installations with some libs
installed for both. Crucially, deps need to be resolved to the version
of a lib with the right ABI.

debian solves this problem in an ad-hoc way by tacking extra components
into the package name:

pyfoo-py22.deb which deps on pybar-py22.deb
pyfoo-py23.deb which deps on pybar-py23.deb

so all can be installed at once and deps are resolved within the right
ABI. Now this is obviously not in the Gentoo tradition. We much prefer
cleaner solutions like SLOTing. I would love to see this extended to
allow us to SLOT on the abi and then correctly resolve based on that
abi.

If we just SLOTed at the moment we'd get the sitation where
dev-python/bar built for py 2.2 would be considered ok to satisfy a
dependency of dev-python/foo that is being built for py 2.3.

We want some kind of extra component to be able to resolve on:

dev-python/foo-1.0.ebuild:

SLOT="${PV}-${PY_PV}"
ABI="${PY_PV}"
DEPEND="dev-python/bar @ ${PY_PV}"

Actually for Haskell the situation is even more fun; we have multiple
haskell implementations, so we would like to install a lib and SLOT upon
and correctly resolve deps for multiple haskell compilers.

Fun stuff. :-)

If portage people are interested in moving in this direction we have an
experimental emerge-compatible mini dep-resolver which might be useful
to prototype an extended ABI/SLOTing system.

Duncan Coutts

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC about another *DEPEND variable

[Mike Frysinger]

On Thursday 21 September 2006 10:54, Donnie Berkholz wrote:
> Yes, I agree with you. For example, take expat. The maintainers have
> refused to allow both versions to exist simultaneously on a system
> because it apparently causes more breakage than just breaking every app
> on your system by removing .so.0.

that is the exact case portage should be handling for you

it would go "oh hey, check out libexpat.so.0 ... some things seem to want 
it ... HEY USER, you need to rebuild: " ... once all the packages 
still consuming libexpat.so.0 are rebuilt, portage could silently trim it 
from the system

complicated ?  not really, scanelf can produce all this information in an 
easily digestable format
-mike


pgpHM7hO3h7Iv.pgp
Description: PGP signature

Re: [gentoo-dev] Notification about MD5 support

[Mike Frysinger]

On Thursday 21 September 2006 10:49, Vlastimil Babka wrote:
> GLEP 44 says:

touche
-mike


pgpy7mqcfngBq.pgp
Description: PGP signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Brian Harring]

On Thu, Sep 21, 2006 at 05:38:08PM +0300, Alin Nastac wrote:
> Brian Harring wrote:
> > On Thu, Sep 21, 2006 at 01:38:59PM +0200, Luca Barbato wrote:
> >   
> > There is one flaw with this though; packages can provide both 
> > libraries _and_ binaries.  Our dependencies don't represent whether 
> > the dep is actual linkage, or just commandline consuming, so (using 
> > the openssl example) any package that invokes openssl via the 
> > commandline to do a few simple chksum ops gets rebuilt, despite the 
> > fact it wasn't affected by linkage change ups.
> >   
> I like BINCOMPAT proposal but it solves only half of the problem. You
> assume that all dependent packages cares about binary compatibility.
> Why not using a BDEPEND var in those dependent packages affected by the
> BINCOMPAT values of their dependencies?
> 
> For instance, I would set the following:
>  - in net-dialup/ppp ebuild: BINCOMPAT=${PV}
>  - in net-dialup/pptpd ebuild:   BDEPEND="net-dialup/ppp"

BDEPEND was actually a seperate proposal/idea, intention there was to 
have that be the deps that *must* be CHOST (gcc would be an example); 
bits that are used to actually build the pkg, not data it consumes in 
building (headers would be data).

Meanwhile, for this I don't see the point in using a seperate metadata 
key.  Overload DEPEND and add a marker char that is used to indicate 
that a particular dependency is 'binding', ie, it is linkage.

~harring


pgpTdTMlvzIuz.pgp
Description: PGP signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Brian Harring]

On Thu, Sep 21, 2006 at 10:43:11AM -0400, Mike Frysinger wrote:
> On Thursday 21 September 2006 10:04, Brian Harring wrote:
> > I agree; while I'm labeling it ABI, includes both bad soname handling
> > and seperate sonames.
> 
> those people should be smacked (for the interest of disclosure, i have 
> violated the "bad soname" rule for the sake of following upstream)
> 
> > Feel free to point out a 4th option if I'm missing it, but for the
> > request, that's what exists afaict; meanwhile, stating that pkgs are
> > being stupid, while true, doesn't actually solve the issue :)
> 
> 4) portage maintains a list of ABI SONAMEs in use and does not unmerge the 
> library until all consumers are gone
> 
> i'm referring to the specific file of course, not anything else in the 
> package ... so integrating the hack eutils.eclass:preserve_old_lib() into 
> portage so it isnt a hack (not a knock against the current implementation 
> here; it's always going to be a hack until portage manages proper unmerging 
> of the ABI library)

The reason folks aren't talking about using NEEDED is that NEEDED data 
is generated _after_ building; getting the info into the resolver 
up front allows for a helluva lot more options, and makes stuff like 
ensuring you have all sources required downloaded *prior* actually 
simple to do, rather then inserting recalculating hacks into the 
resolver.

Clarifying the 'recalculating', what you're suggesting is effectivelly 
unbounded resolution, re-calculating at each step.  That route is 
*very* nasty since you can't gurantee up front the resolution will 
work, let alone ensuring the bugger doesn't go cyclic.
~harring


pgpoVTJpTCkcq.pgp
Description: PGP signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Simon Stelling]

Duncan Coutts wrote:
> So for it's something like:
> # for C:
> ABI=${SONAME}
> 
> # for python
> ABI=${PY_PV}
> 
> # for haskell:
> ABI=${GHC_PV}
> 
> paludis has something going in this direction but I don't think it'd
> quite solve the python/ghc abi issue. It was aimed more at cases like
> mips with it's multiple abis.

It's all about multilib and has (except for the unfortunate name)
nothing to do with this issue.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC about another *DEPEND variable

[Mike Frysinger]

On Thursday 21 September 2006 10:56, Duncan Coutts wrote:
> If we do go in this direction it'd be great to be able to slot on the
> ABI and still have dependencies resolved correctly. For example imagine
> having parallel python-2.3 and 2.4 installations with some libs
> installed for both. Crucially, deps need to be resolved to the version
> of a lib with the right ABI.

ugh, no ... we are not a binary distribution so we should not have to worry 
about ABI baggage

we SLOT based upon API, not ABI
-mike


pgpPmPiAwyWo0.pgp
Description: PGP signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Duncan Coutts]

On Thu, 2006-09-21 at 11:11 -0400, Mike Frysinger wrote:
> On Thursday 21 September 2006 10:56, Duncan Coutts wrote:
> > If we do go in this direction it'd be great to be able to slot on the
> > ABI and still have dependencies resolved correctly. For example imagine
> > having parallel python-2.3 and 2.4 installations with some libs
> > installed for both. Crucially, deps need to be resolved to the version
> > of a lib with the right ABI.
> 
> ugh, no ... we are not a binary distribution so we should not have to worry 
> about ABI baggage

So we can't ever install two versions of python or ghc at once? That
seems a shame.

> we SLOT based upon API, not ABI

Here's another example; I'm not sure if it passes the ABI/API test:

We would like to support 3 Haskell implementations:
  * GHC which compiles to native code (ELF binaries & static .a libs)
  * Hugs which is an interpreter so installation is .hs source files
  * YHC which compiles to portable bytecode

A single Haskell library is likely to work with all three
implementations. So that's API.

Once installed however each implementation is very different. So that's
incompatible ABI.

This could be 'solved' by having dev-haskell/foo-ghc,
dev-haskell/foo-hugs, dev-haskell/foo-yhc, but that's obviously not the
Gentoo way (though it's pretty much what debian does).

These multiple impls is pretty similar to multiple versions of the same
compiler.

So my point is, I don't think it can be simply dismissed as ABI nonsense
that we don't have to deal with. Being able to SLOT on the compiler
flavour (and possibly version) would allow us to do useful things that
we cannot currently do.

Duncan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC about another *DEPEND variable

[Alin Nastac]

Brian Harring wrote:
> BDEPEND was actually a seperate proposal/idea, intention there was to 
> have that be the deps that *must* be CHOST (gcc would be an example); 
> bits that are used to actually build the pkg, not data it consumes in 
> building (headers would be data).
>   
Well, until now I didn't thought at the build compatibility.
My concern was only the runtime compatibility.
> Meanwhile, for this I don't see the point in using a seperate metadata 
> key.  Overload DEPEND and add a marker char that is used to indicate 
> that a particular dependency is 'binding', ie, it is linkage.
>   
Lets suppose we use & as 'binding' dependency marker. What sense would
DEPEND="&net-dialup/ppp" have in a context of an ebuild. It certainly
don't specify the necessity of package rebuild whenever net-dialup/ppp
version is changed.
Unless you save the specific compatibility version of the net-dialup/ppp
used by net-dialup/pptpd for building the package, I don't see how can
it help me.
Judging after /var/db/pkg content, I have no such information.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Alin Nastac]

Mike Frysinger wrote:
> i think you're merging the two issues you brought up ... there is binary ABI 
> issues (which should not require a new DEPEND variable as portage can extract 
> that information out at runtime) and there is runtime plugin issues with 
> packages using dlopen() (which portage cannot extract as the dependency 
> cannot ever be extracted)
>   
Okay, maybe I hijacked BINCOMPAT purpose. As I said in a previous reply,
my original message was about runtime compatibility, not compilation
compatibility.
I want to be able to save in a package metadata that it was build using
some version (as in compatibility version, not necessarily PV) of
another package and I want emerge to automatically rebuild my package
whenever this version is changed.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] seeds, GLEPs, and projects

[Grant Goodyear]

For whatever it's worth, I rather like the Gentoo Seeds project,
although I'm more interested in nice tools to make the seeds, than
in having pre-existing seeds.

Ciaranm has argued that the project really should have been GLEPped.
Although I wouldn't have opposed such a GLEP, it's not clear to me that
a GLEP is the right format here.  Underlying a GLEP is the notion that
somebody is going to have to approve it.  By our current policies,
anybody is welcome to start a new project (we welcome innovation, after
all), and if the effort underway doesn't involve other projects then the
only approval needed would be the project leader, which would be the
person who created the project, which would seem a bit silly.
Of course, nothing would stop somebody from posting an RFC to -dev
essentially in the same format as a GLEP, however.

Of course, what ciaranm and others are really suggesting is that before
there's an announcement that Gentoo has an official project to do blah,
it might be nice to get some feedback from the community first.  If we
(being Gentoo) say that we're going to do something, and then things
fall through, it might make us look bad, after all.  In this case,
though, it's not clear to me what stuart should have done differently.
He didn't issue a press release (unless I'm missing something), he sent
an e-mail to -dev announcing that he had created a new project and
described the purpose of that project.  If it had been me, I probably
would have sent an e-mail letting people know that I was seriously
thinking about creating such a project, pointed out that it was
experimental, and given people a (brief!) period of time to complain
before went ahead and pushed the button, but it's not clear to me that
any of that was actually required.  (I would like to suggest that it is
more courteous, though, not to surprise our devs w/ something new if a
more gentle introduction can be managed.)

To some extent, we're back to determining what the word "official" means
in these cases.  My goal in making projects easy to create was to
support innovative ideas.  Most innovative ideas don't pan out, however,
so a corollary has to be that just because a project exists (and thus is
somehow "official") doesn't mean that anything useful will come out of
it, nor that what does come out of it will be supported by the community
as a whole.  If we need to change things to make that reality more clear, I'm
certainly willing to listen to suggestions. 

-g2boojum-
-- 
Grant Goodyear  
Gentoo Developer
[EMAIL PROTECTED]
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76


pgpFHSWMM48ya.pgp
Description: PGP signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Luca Barbato]

Duncan Coutts wrote:



So my point is, I don't think it can be simply dismissed as ABI nonsense
that we don't have to deal with. Being able to SLOT on the compiler
flavour (and possibly version) would allow us to do useful things that
we cannot currently do.


what about making them build what you want depending on useflags?

lu

--

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] seeds, GLEPs, and projects

[Simon Stelling]

Grant Goodyear wrote:
> If we
> (being Gentoo) say that we're going to do something, and then things
> fall through, it might make us look bad, after all.

Maybe it's just me being stupid, but what exactly do we have to loose?
(This is a serious question, I'd appreciate serious answers.)

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New project: Gentoo Seeds

[Nick Rout]

On Wed, 20 Sep 2006 23:53:39 +0100
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:

> On Wed, 20 Sep 2006 18:42:13 -0400 Alec Warner <[EMAIL PROTECTED]>
> wrote:
> | As Donnie said; if this is the thanks one gets for trying out a new
> | idea; then why try at all.
> 
> The complaints are not that Stuart tried a new idea. Stop trying to
> spin things that way. The complaints are that he allegedly did it
> without consultation, and that he sprang this unexpectedly.
> 
> -- 
> Ciaran McCreesh
> Mail: ciaranm at ciaranm.org
> 
> 


I am replying here at no particular point in the thread because its
hard to find the right spot to interject. 

I am a lurker on this list, I joined it a few years ago because I was
interested in the development process for gentoo, and because I like to
early adopt and be aware of impending changes.

I am a long time user of gentoo, a strong gentoo advocate, almost to
the point of zealotry. I have introduced many people to gentoo, and
have given talks to my local LUG, run gentoo installfests and
contributed to the -users list, the forums and the bugzilla.

However the behaviour displayed in this list, and in particular this
thread are downright embarassing. I used to be proud of being a gentoo
user and following a group of dedicated and clever developers. Now I
just want to find a quick and easy way to get rid of it. You have had
your antics displayed to the world via a thrashing on slashdot, and
most of you thoroughly deserve the public outing.

Its time you people had a good look at yourselves. Start behaving like
adults, not children fighting over the toys in the sandpit. You make it
hard to promote gentoo when you are arguing over the wording of people
announcing a new project. 

Nick.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC about another *DEPEND variable

[Brian Harring]

On Thu, Sep 21, 2006 at 08:15:48PM +0300, Alin Nastac wrote:
> Brian Harring wrote:
> > BDEPEND was actually a seperate proposal/idea, intention there was to 
> > have that be the deps that *must* be CHOST (gcc would be an example); 
> > bits that are used to actually build the pkg, not data it consumes in 
> > building (headers would be data).
> >   
> Well, until now I didn't thought at the build compatibility.
> My concern was only the runtime compatibility.
> > Meanwhile, for this I don't see the point in using a seperate metadata 
> > key.  Overload DEPEND and add a marker char that is used to indicate 
> > that a particular dependency is 'binding', ie, it is linkage.
> >   
> Lets suppose we use & as 'binding' dependency marker. What sense would
> DEPEND="&net-dialup/ppp" have in a context of an ebuild. It certainly
> don't specify the necessity of package rebuild whenever net-dialup/ppp
> version is changed.
>
> Unless you save the specific compatibility version of the net-dialup/ppp
> used by net-dialup/pptpd for building the package, I don't see how can
> it help me.
> Judging after /var/db/pkg content, I have no such information.

Any such implementation would require storing some extra data in the 
vdb

For this, would just walk the *DEPEND collecting 'binding' 
dependencies, and storing their BINCOMPAT in a simple mapping.

~harring



pgpOEVz6DdaZV.pgp
Description: PGP signature

Re: [gentoo-dev] New project: Gentoo Seeds

[Alec Warner]

However the behaviour displayed in this list, and in particular this
thread are downright embarassing. I used to be proud of being a gentoo
user and following a group of dedicated and clever developers. Now I
just want to find a quick and easy way to get rid of it. You have had
your antics displayed to the world via a thrashing on slashdot, and
most of you thoroughly deserve the public outing.

Its time you people had a good look at yourselves. Start behaving like
adults, not children fighting over the toys in the sandpit. You make it
hard to promote gentoo when you are arguing over the wording of people
announcing a new project. 


Nick.



Recall that the majority of developers barely respond on this list and 
just *develop*; I wouldn't suggest lumping everyone in that category; 
although I'm sure I fall into it from time to time.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] seeds, GLEPs, and projects

[Joshua Jackson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Simon Stelling wrote:
> Grant Goodyear wrote:
>> If we
>> (being Gentoo) say that we're going to do something, and then things
>> fall through, it might make us look bad, after all.
>
> Maybe it's just me being stupid, but what exactly do we have to loose?
> (This is a serious question, I'd appreciate serious answers.)
>
Well, I'd probably say. The respect of others both in and out of the
open source community.

Secondarily I'd say that we lose a bit of the corporate ready
appearance that some are working towards (which I don't oppose).

Third, we lose the respect of each other in the project. Seriously,
its not something to be thought of lightly. If a project you announce
fails, people will remember oh Simon started so and so, and it failed
utterly.

/me considers these to be serious replies ^.^;; <--the face however
isn't *wink*
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFEvAUSENan+PfizARAmQ7AJ97BwzV4MNl9PRAmOsGqFf9N0DgvwCeP4rS
4TeCV+6i3Zus8sufzz4LN0k=
=tIif
-END PGP SIGNATURE-

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] seeds, GLEPs, and projects

[Ciaran McCreesh]

On Thu, 21 Sep 2006 20:28:46 +0200 Simon Stelling <[EMAIL PROTECTED]>
wrote:
| Grant Goodyear wrote:
| > If we
| > (being Gentoo) say that we're going to do something, and then things
| > fall through, it might make us look bad, after all.
| 
| Maybe it's just me being stupid, but what exactly do we have to loose?
| (This is a serious question, I'd appreciate serious answers.)

Huge amounts of time, effort and users. How much arch team time was
spent fixing genkernel? How much time was spent fixing the OS X mess?
How many users did we lose as a result of all the QA screwups?

As much as I hate relying upon slashdot for anything reasonable at all,
an awful lot of people in that thread were suggesting that more time be
spent on QA and fixing existing bugs and much less on fancy new
things...

-- 
Ciaran McCreesh
Mail: ciaranm at ciaranm.org



signature.asc
Description: PGP signature

Re: [gentoo-dev] seeds, GLEPs, and projects

[Simon Stelling]

Ciaran McCreesh wrote:
> Huge amounts of time, effort and users. How much arch team time was
> spent fixing genkernel? How much time was spent fixing the OS X mess?
> How many users did we lose as a result of all the QA screwups?

Eh, I wanted answers, not more questions :P

> As much as I hate relying upon slashdot for anything reasonable at all,
> an awful lot of people in that thread were suggesting that more time be
> spent on QA and fixing existing bugs and much less on fancy new
> things...

These users are ignoring the fact that time is not the only and most
important factor. Motivation is far more important IMO, and it's pretty
hard to get the motivation together to test 60 packages instead of
tinkering around with a new idea. At least for me it often is.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] seeds, GLEPs, and projects

[Mike Pagano]

On 9/21/06, Simon Stelling <[EMAIL PROTECTED]> wrote:

Ciaran McCreesh wrote:
> Huge amounts of time, effort and users. How much arch team time was
> spent fixing genkernel? How much time was spent fixing the OS X mess?
> How many users did we lose as a result of all the QA screwups?

Eh, I wanted answers, not more questions :P

> As much as I hate relying upon slashdot for anything reasonable at all,
> an awful lot of people in that thread were suggesting that more time be
> spent on QA and fixing existing bugs and much less on fancy new
> things...

These users are ignoring the fact that time is not the only and most
important factor. Motivation is far more important IMO, and it's pretty
hard to get the motivation together to test 60 packages instead of
tinkering around with a new idea. At least for me it often is.

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list




Maybe a recruiting drive to help with the maintenance.  A typical
business brings on new blood and assigns them just that role to free
up more senior developers for more complicated projects.

New developers should definitely meet a standard, but the possibility
of bringing developers with energy and potential to assist in
maintenance might be worth a consideration.
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] seeds, GLEPs, and projects

[Lance Albertson]

Grant Goodyear wrote:

> To some extent, we're back to determining what the word "official" means
> in these cases.  My goal in making projects easy to create was to
> support innovative ideas.  Most innovative ideas don't pan out, however,
> so a corollary has to be that just because a project exists (and thus is
> somehow "official") doesn't mean that anything useful will come out of
> it, nor that what does come out of it will be supported by the community
> as a whole.  If we need to change things to make that reality more clear, I'm
> certainly willing to listen to suggestions. 

I really like the idea that people can create new projects w/o some
overseeing board, but I don't like new projects that don't announce an
RFC before they say "here we are". I'd like to keep this process easy,
and I do agree with you that this particular case may not have fallen
under the GLEP area. So that being said, what's the harm in requiring
folks to send an RFC to -dev a few weeks prior to making some kind of
public announcement? I know that several people will argue that a lot of
things in a project may not be drawn out completely, but I think
encouraging people wanting to create new projects to try and at least go
through most of the process before announcing it to the world is a good
ideal.

I'm not implying that an RFC needs to be as drawn out as a GLEP, but it
certainly should lay out the goals, plans, some implementation details.
Who knows, maybe you'll get a few folks interested right off and that's
a plus for you in the long run. You'll of course have the few who will
flame the idea and you'll just have to take what they say as a grain of
salt. We're all knowledgeable about various things, why can't we utilize
that asset?

If people like this idea, I'd like to propose the council to add an
addendum to our "new projects" policy to include the requirement of some
kind of RFC before a public announcement saying 'we're ready' is done.
Its kind of a 'peer' review type of thing and it also builds
trust/communication between all of us.

This whole issue boils down to accountability and communication. We want
to make sure that We (gentoo) as a whole can be accountable for a
project that is created. We also want to be informed so that we can
either comment or become involved in a new project during its formation.

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC about another *DEPEND variable

[Duncan Coutts]

On Thu, 2006-09-21 at 20:27 +0200, Luca Barbato wrote:
> Duncan Coutts wrote:
> 
> > 
> > So my point is, I don't think it can be simply dismissed as ABI nonsense
> > that we don't have to deal with. Being able to SLOT on the compiler
> > flavour (and possibly version) would allow us to do useful things that
> > we cannot currently do.
> 
> what about making them build what you want depending on useflags?

Aye, for the implementation flavours that's probably the way to go once
we have use-deps. We'll have to hold off on multiple versions of the
same compiler though.

It might get a bit hairy though :-)

DEPEND="ghc?  ( dev-haskell/foo @ ghc )
hugs? ( dev-haskell/foo @ hugs )
yhc? ( dev-haskell/foo @ yhc )
jhc? ( dev-haskell/foo @ jhc )"

(I've not looked up what the use-dep syntax is, I'm just guessing)

Duncan

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: seeds, GLEPs, and projects

[Peter]

On Thu, 21 Sep 2006 17:01:02 -0400, Mike Pagano wrote:
> Maybe a recruiting drive to help with the maintenance.  A typical
> business brings on new blood and assigns them just that role to free up
> more senior developers for more complicated projects.
> 
> New developers should definitely meet a standard, but the possibility of
> bringing developers with energy and potential to assist in maintenance
> might be worth a consideration.

That's a laugh! Problem is that no devs seem to get approved in a timely
fashion. And, any potential devs would be rather turned off by the goings
on here. You guys seem to try and stifle innovation at every turn --
trying to turn Gentoo into GLEPtoo. Instead of progress, you have
arguments. Instead of innovation, you have arguments. Instead of new
blood, you lose people.

You (collectively meaning the critics of new projects) are so worried
about the perception of Gentoo that you can't see the forest for the
trees. The fact that every new proposal gets a 100 message thread as a
response looks really silly. Having developers submit ebuild quizzes and
then not hear for 6 weeks is silly.

Here's my take on what wrong with leadership and the process in
Gentoo-land . Many people have ideas, and some make attempts to implement
them. That's great. However, some then think it's not right or not proper
or not proposed the right way. Some of the critics may be right, but who's
the arbiter? Who's to say, "STFU, this project is going ahead" or "You've
got a point, let's discuss it." No one. There's no one person or group who
seems to have the authority to step up and take control of a situation. No
one who can say to bashers, "You're out of line." Oh I know, there's the
council, but really, I've yet to see them exert any authority. Look at the
calamity that surrounded Paludis or Sunrise.

Instead, you have a dozen people jerking around over the propriety of the
manner in which a project was proposed! All trying, with good intent,
to influence the future direction of Gentoo. Good god. It's like third
grade.

So, my unofficial 2 cents are: Encourage development at every turn.
Accelerate approval of developers (hint, kloeri, christel?), and, instead
of flaming and arguing all the time, maybe offer assistance! And lastly,
for goodness sakes, someone take control. You really need an authority
figure here who is respected and whose word is final. Otherwise, every
tom, dick, and harry with an opinion is going to chime in and say "Oh no,
you can't do that."

-- 
Peter

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New project: Gentoo Seeds

[Nick Rout]

On 9/21/2006, "Alec Warner" <[EMAIL PROTECTED]> wrote:



>> However the behaviour displayed in this list, and in particular this

>> thread are downright embarassing. I used to be proud of being a gentoo

>> user and following a group of dedicated and clever developers. Now I

>> just want to find a quick and easy way to get rid of it. You have had

>> your antics displayed to the world via a thrashing on slashdot, and

>> most of you thoroughly deserve the public outing.

>>

>> Its time you people had a good look at yourselves. Start behaving like

>> adults, not children fighting over the toys in the sandpit. You make it

>> hard to promote gentoo when you are arguing over the wording of people

>> announcing a new project.

>>

>> Nick.

>>

>

>Recall that the majority of developers barely respond on this list and

>just *develop*; I wouldn't suggest lumping everyone in that category;

>although I'm sure I fall into it from time to time.



Ahh thats a fair point indeed.







>--

>gentoo-dev@gentoo.org mailing list

>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC about another *DEPEND variable

[Luca Barbato]

Duncan Coutts wrote:

On Thu, 2006-09-21 at 20:27 +0200, Luca Barbato wrote:

Duncan Coutts wrote:


So my point is, I don't think it can be simply dismissed as ABI nonsense
that we don't have to deal with. Being able to SLOT on the compiler
flavour (and possibly version) would allow us to do useful things that
we cannot currently do.

what about making them build what you want depending on useflags?


Aye, for the implementation flavours that's probably the way to go once
we have use-deps. We'll have to hold off on multiple versions of the
same compiler though.

It might get a bit hairy though :-)

DEPEND="ghc?  ( dev-haskell/foo @ ghc )
hugs? ( dev-haskell/foo @ hugs )
yhc? ( dev-haskell/foo @ yhc )
jhc? ( dev-haskell/foo @ jhc )"

(I've not looked up what the use-dep syntax is, I'm just guessing)


as now, you can handle that with an eclass that takes deps, checks those 
deps with certain use if the use has been enabled and dies if those 
criterions aren't meet (asking you to falling back to hc-updater to keep 
 those applications in shape)


pretty hacky and itchy but that's probably the best you can do w/out 
use-deps. (PS can you slot on use now?)


lu

--

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] waimea needs to be fixed or removed

[Joe Sapp]

Hi all,

As upstream is pretty dead [1][2] and bug #127241 [3] is still
applicable, I'd like to request that somebody more knowledgeable take
over the work I started on fixing the waimea window manager (see [3]
for files and info), if possible.  If nobody lets me know to the
contrary, I'll remove x11-wm/waimea and the only package depending on
it (x11-misc/wampager) in 30 days.  For now though, they're in
package.mask.

--
Joe Sapp

[1]
http://lists.freedesktop.org/archives/waimea/2006-January/000190.html
[2] http://lists.freedesktop.org/archives/waimea/2006-June/thread.html
[3] http://bugs.gentoo.org/show_bug.cgi?id=127241




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New project: Gentoo Seeds

[Dice R. Random]

On 9/21/06, Wernfried Haas <[EMAIL PROTECTED]> wrote:

Please keep in mind that only a few of the approximately 300 Gentoo
developers are taking part in this discussion and only a few of them
actually seem to get a bit more heated than it should be.
If you think they are behaving poorly, feel free to think so, but
remember that they do not entirely represent Gentoo.


I agree entirely, however I also think that the actions of a few can
be magnified in the public's eye and reflect upon a the whole group.

I think that many (most?) people would agree that in both this
discussion and the one surrounding the Sunrise project lines have been
crossed.  The Etiquette Policy [1] specifies that "... as a developer,
what you say and do reflects upon Gentoo and the project as a whole.
We just require you to be equally respectful to developers and users
alike, and to value the opinion of everybody - even if you think it's
totally wrong."

[1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=2

What control mechanisms are there within the Gentoo community to keep
a few bad apples from spoiling the whole barrel, as it were?  I do not
wish to name any names, but it seems to me from having skimmed this
list for the past few years that there are a couple people who are
continually embroiled in flame wars and, in my opinion, are bringing
discredit to Gentoo in general and the developers in particular.
--
gentoo-dev@gentoo.org mailing list