Limitations of Ports System

Garrett Cooper youshi10 at
Fri Dec 14 15:39:08 PST 2007

Aryeh M. Friedman wrote:
> Hash: SHA1
> Remko Lodder wrote:
>> Aryeh M. Friedman wrote:
>>> 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> wrote:
>>>>>>> On Thu, 13 Dec 2007 22:34:58 -0500
>>>>>>> "Aryeh M. Friedman" <aryeh.friedman at> 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.
>>>>> 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). So
>>>> please stfu till you have some code and be done with it <DOT>.
>>> Developing in a vacuum is a recipe for disaster.... we are making
>>>  fairly good progress believe it or not I only see an other 1 or
>>> 2 threads being needed before actual coding starts, *BUT*
>>> producing a system no one wants is pointless thus it is wise to
>>> gather as much input as possible...  why is it that everyone who
>>> sees the whole concept as being negative has offered no input
>>> what so ever about what should be done (even saying "the current
>>> system is fine" is useful to us)
>> simply because we have seen it failing a lot of times. Please take
>> this offlist,discuss this and generate a nice PoC, then get back to
>> us, till that time, DONT bother the ports list with it or any other
>> list. You are the single reason for a HIGH S/N ration on MOST lists
>> I am subscribed to that is a REALLY -BAD- thing.
> Perhaps one reason it has failed is because there was not a wide
> enough front end effort to decide what was really needed vs. what some
> individual thought was needed... as to the s/n thing there would be
> lot less if you actually debated on the technical merits of the
> proposal and not the meta discussion of does something belong here or
> list b or where ever... unless you think community input is completely
> pointless I invite you to suggest an other medium that allows for it
> without making is semi-obscure and hard to find.
>> You Simply dont understand the way it works here and I can
>> understand that till a certain point of view; take the advise;
>> discuss it elsewhere, and get back with working code (yeah I repeat
>> it twice because nobody seems to get through to you, and MANY
>> people tried it already).
> Oh I hear the message loud and clear and just happen to not agree with
> the thinking behind it.   Namely ivory tower development has its place
> but not here.
> Version: GnuPG v2.0.4 (FreeBSD)
> Comment: Using GnuPG with Mozilla -
> iD8DBQFHYwY+zIOMjAek4JIRAj/NAJ0aTnHnDejwXlujkc8AITtGqGxgywCgmoeh
> FcWtuCJqPmepfIUCgA87+lM=
> =S9wo
> _______________________________________________
> freebsd-ports at mailing list
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at"
Relating what happened with my work project to this type of an idea, 
definitely proposing something is good in the beginning, and obtaining a 
quick idea of what needs to be done is a good thing. But I think that 
overall what should be done is more like a iterative step such as this:

1. Make plan.
2. Ask limited group for sanity check.
3. Code, code code. Go back to 2. if necessary. Continue to 4. when "done".
4. Ask larger group for sanity check and testing. Go back to 3. if 
necessary. Continue to 5. when "done".
5. Release.

We're still at 1., and while I think that the problem to 1. can be 
established and thought out via email, perhaps the stakeholders need to 
brainstorm and research more about 1. on the lists, as this topic has 
been brought up a few times already (see the ports@ and hackers@ 
archives in particular).


More information about the freebsd-ports mailing list