Limitations of Ports System

[Aryeh M. Friedman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Danny Pansters wrote:
> On Thursday 13 December 2007 19:17:34 Warren Block wrote:
>> On Thu, 13 Dec 2007, Steven Kreuzer wrote:
>>> This thread was called "results of ports re-engineering survey" but I
>>> figured I would start a new thread.
>> Rightly so.
>>
>>> On Dec 12, 2007, at 6:45 AM, Ade Lovett wrote:
>>>> We *know* it can be done better.  We *know* the scaling limits of the
>>>> current system, and most of us are completely amazed it even still
>>>> works.
>>>>
>>>> If y'all want to make a difference, concepts and ideas we have plenty
>>>> of. Code talks.
>>> Out of curiosity, are any of these shortcomings documented anywhere? I
>>> have been using ports on my home machine for a long time and I've never
>>> had any problems with it. I assume the issues come into play when you
>>> work with multiple systems you are trying to keep in sync, etc.
>>>
>>> I would be interested in reading about some of the limitations people
>>> have run into when using ports.
>> Notable with the new modular Xorg is the speed of changes
>> (install/deinstall/clean) when there are a lot of ports installed.
>> Before modular xorg, 400 ports installed was a lot.  700 now is not
>> surprising.
>>
>> Some profiling looking for areas which could benefit from speed
>> optimization would be useful.  That may have already been done but not
>> publicized.
>>
>
> Well, I can tell you what I think:
>
> If we don't want thousands of global knobs, then it's either splitting
up in
> almost atomic micro ports which inflates the number of ports or using port
> OPTIONS... BUT... we currently have no standard mechanism to actually use
> another port's OPTIONS in a somewhat generic way.
>
> It's all about where and how you want to have your granularity (sp?) I
think.

An other option is keep the knobs in a centeral DB but only ask for
ones the port being currently being compiled requires and all other
values are cached.  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.
>
> In the longer run, being able to specify a port's options when specifying
> DEPENDS would probably be a very useful and not very invasive change
for the
> better (or maybe if that's simpler -- doubt it -- some sort of
OPT_DEPENDS).
>
> If someone wants to work specifically on addressing - to put it bluntly -
> the "debianizing-ports-versus-optionifying-properly" issue I'm
interested in
> chipping in or if needed leading such an effort. The scope should be only
> that and it must be backwards compatible.

There is enough dependancy (and alt versioning) issues they must be
addressed also.   The alt versioning alone will require a complete
redesign I think thus we mightest well throw in port/package
interchangability.  So I am leaning towards a ground up rewrite unless
some can show how to get real dependancy management and alt. versions
into the existing framework.   Note neither should complicate the
current system any more then absulutely needed and any such
compilcation should be on the maintainers and portmgr only (hopefully
none).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYfnizIOMjAek4JIRAisNAKCQ2VZ2wibSFinuKAztxJlvI6dbPQCdEgbQ
SnHPQr+mrf9aImgj8iL7ZMI=
=RuoC
-----END PGP SIGNATURE-----