Limitations of Ports System

[David Southwell]

On Friday 14 December 2007 14:20:24 Remko Lodder wrote:
> David Southwell wrote:
> > On Friday 14 December 2007 08:08:54 Paul Schmehl wrote:
> >> --On Friday, December 14, 2007 12:19:06 +0000 RW
> >>
> >> <fbsd06 at mlists.homeunix.com> wrote:
> >>> On Thu, 13 Dec 2007 22:34:58 -0500
> >>>
> >>> "Aryeh M. Friedman" <aryeh.friedman at gmail.com> wrote:
> >>>> Namely if I build abc with options 123 and 345 and
> >>>> def with 345 and 678 then 345 will be cached for def since we already
> >>>> set it for abc.
> >>>
> >>> How do you know the user wants 345 set on both ports?
> >>>
> >>> It might be a useful stable feature on "abc", but causes lock-ups on
> >>> "def"
> >>
> >> SInce I've already killfiled Aryeh, I can only infer what you are
> >> responding to and respond to him.  But let me state this emphatically in
> >> the hopes it will get through his thick skull.
> >
> > I do wish you could acquire the maturity to distinguish between the
> > advantages that could come arguing your case clearly and collegially and
> > the disadvantages that acrue from being personally antagonistic towards
> > someone with whose analysis you happen to disagree.
> >
> > For me when someone becomes abusive they destroy their own credibility
> > and get to sound as though they believe their opinions antitle them to be
> > hateful and that their own views are somehow godgiven.
> >
> >> IT IS NOT THE JOB OF PORTS
> >> TO MAKE DECISIONS FOR USERS.
> >
> > IMHO Shouting make you less rather than more credible.
> >
> >> \Please repeat that one hundred times until it
> >> gets through.
> >
> > Endless repetition does not add strength to analysis!!
> >
> >> No port should *ever* make decisions on a users behalf.  Suggestions,
> >> yes (e.g. OPTIONS that are enabled by default.)  Decisions, no.  If you
> >> depend on another port *and* on certain knobs in that dependency being
> >> enabled, then *tell* the user that during your port's install and let
> >> them decide how to handle it.  DO NOT enable those knobs yourself, no
> >> matter how tempting it may be.
> >
> > IMHO You would sound more credible if you used the IMHO a bit more!! You
> > might also gain some respect if you followed your own advice. Make
> > suggestions for others to consider - do not decide, in advance, they are
> > thick skulled if they do not agree with you!!
> >
> >> It is beyond impossible for anyone to know what every user who is
> >> installing ports already has on their boxes or what they might want to
> >> add or ***what you might break***.  Once you begin making decisions for
> >> them, you could well stomp all over something that was functioning
> >> perfectly normally and break a critical box.
> >>
> >> DON'T DO IT.  That is so Microsoftian it's not funny.
> >
> >  IMHO Shouting, hectoring and lecturing does not add weight to anyones
> > point of view.
>
> These threads have gone far enough, please consider taking this off the
> FreeBSD mailinglists and discuss this privately. The majority does not
> like the current ideas and want to see something usefull first. People
> like Aryeh and David are not really persons that one would see as the
> persons generating the ports-infrastructure-ng till they have code.
>
> If you both keep pissing off people that have a fair share in the ports
> collection already, please do it by other means, dont crowd the
> mailinglists with it. Your ideas might be perfect in your world but they
> aint in ours (till you have shown working code).

This world (the ports mailing list) is our world as much as it is your world. 
Think about collegial coexistence or use the delete key. Otherwise please 
stay on topic and stop trolling. This thread is about the limitations of 
ports system not "Why we should not talk about trhe limitations of the Ports 
System". 
1. Stay on topic
2. Start a separate thread if you want - I am sure there will be those who 
would like to discuss why the limitations of the ports system should not be 
discussed.
3. Otherwise please make some technical responses to the thread.
>
Thank you