begin  quote
On Tue, 06 Jan 2004 20:02:13 +0200
Eldad Zack <[EMAIL PROTECTED]> wrote:

> On Tue, 2004-01-06 at 19:56, Eldad Zack wrote:
> > On Tue, 2004-01-06 at 14:33, Paul de Vrieze wrote:
> > 
> > > I'm sorry for that. It however can be a sign that the tree is not
> > > ready for those ebuilds, or that they are in very low demand.
> > 
> > Perhaps we can create some sort of repository for these kind of
> > ebuilds, as an outlet for the low-demand ebuilds, where a user could
> > search for an ebuild, and not reinvent the wheel, if a package he'd
> > like to install falls under this category.
> > 
> > Searching bugzilla would yield the same results, I assume, but it's
> > seems to me somewhat less inviting.
> 
> I Just noticed breakmygentoo. maybe a link with a disclaimer from
> gentoo.org would come in handy?
> 
NO DAMMIT NO!!


<soundtrack artist="sundown" cd="glimmer" track="07" title="stab">

Okay, This thread has detoriated beyond the minimum level of sanity
needed for me to allow said people to continue their breathing.

Not personal to you, Edlad, But to everyone who are involved in the
argument  "creating ebuilds"

  BMG is broken by design.  Most of the people haven't even heard
about syntax, yet lest know the basic about the few weak concepts that
are logic and case studies.  Dont get me into dependencies and quality
control here.

I have dev status, and I've got enough old time status here to take it
on me that if BMG is linked to in the current state, I will personally
maim the one who does it, and revert their links and commits.  



Second point I want to make : If anyone touches, installs or tries to
work with BMG ebuilds, their systems should be completely -Wiped- at a
low level before ever being allowed in bugzilla. preferrably they should
be blacklisted as support-impossible.    Conflicting namespaces, library
links and pkg_  time modifications of live systems all make me want to
track down and do preventive QA.

</soundtrack>



<soundtrack artist="sundown" cd="glimmer" track="04" title="prey">

Following the idea of accepting user tested ebuilds?  Don't make me
laugh. please.  I've seen the amount of complete crud , and the lack of
the even most basic concept and ideas of quality .. . "ohh, we need
gnome here gnome-base/gnome is gnome.. yeeey...  DEPEND="gtk+" is a
great way to solve it, and so is x11-libs/qt ... of coouurse.

Or the othertime favourite.. ."but you shouldn't need that cause it will
compile without it.... And then break when it is removed because
theres no dependency on it but it was linked in an update when you had
it installed" ...  Yeaaah right.  * -GAH- *




My level of frustration here is multifold..  At one point came the idea
up that ACCEPT_KEYWORDS = ~ARCH was for broken packages..  Yeahoo yahoo.
I think you should sit down and think over the documentation and
principial ideas of QA and QC for a while.  ~arch is for -testing-
builds.  For the sake of finding such nice issues like that
libao-1.8.4-r1 doesn't work with autoconf 2.57 but will work with
2.58...

Not, because libao is a fun ultrabeta that is known to eat files in
random spite, or cause complete breakage in the system.

The fact that the author who claimed that ACCEPT_KEYWORDS should be the
broken playground  is running the hard-masked version of KDE-3.2_beta, a
version which is in itself  beyond the scope of  ACCEPT_KEYWORDS , 
ought to be enough.

</soundtrack>


Others have argumented the point about "developer care" and "developer
responsibility" as well as that of "guaranteed response time"  for me
earlier in this thread, so I won't have to go into that again here, do
I?



*sigh*

//Spider

-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to