Port system "problems"

Florent Peterschmitt fpeterscom at gmail.com
Tue Jun 26 10:22:28 UTC 2012


On 26.06.2012 11:03, Matthew Seaman wrote:
> On 26/06/2012 09:17, Andrea Venturoli wrote:
>> On 06/26/12 09:58, Matthew Seaman wrote:
>>> On 26/06/2012 08:26, Marcus von Appen wrote:
>>>>>> 1. Ports are not modular
>>>>> What do you mean by modular? if you are speaking about subpackages it
>>>>> is coming,
>>>>> but it takes time
>>>> I hope, we are not talking about some Debian-like approach here
>>>> (foo-bin,
>>>> foo-dev, foo-doc, ....).
>>> Actually, yes -- that's pretty much exactly what we're talking about
>>> here.  Why do you feel subpackages would be a bad thing?
>> Can I share my 2c?
>>
>> Because it will just multiply be three the number of ports each of us
>> has to install/maintain/upgrade/etc...
> Yes, it will multiply the number of ports.  By three is about right,
> given that most ports will only have port-docs and port-examples
> sub-ports.  However, first of all, you are assuming that the effort
> required to install each of those sub-ports is the same as it is to
> install a single port now.  That is simply not the case.
>
> If you want to install the foo/bar port, then (as now) you'ld
> essentially[+] --
>
>      # cd ${PORTSDIR}/foo/bar
>      # make
>      # make install
>
> but you'ld end up with bar-0.99, bar-doc-0.99 and bar-examples-0.99
> installed.  Unless you have a setting like NOPORTDOCS or NOPORTEXAMPLES
> (probably controlled by a dialogue menu like any other options) which
> means you don't get the associated -docs or -examples sub-ports.
>
> That's no real change in terms of what you'ld have to do compared to now.
>
> The difference is that if you install from packages, you now have the
> opportunity not to install docs or examples.
>
> Secondly, that's just one example of how sub-ports should work, and
> docs/examples will be special-cased given their ubiquity.  Most
> sub-ports would be controlled by port OPTIONS dialogues.
>
> A typical example would involve client-server apps -- so mysqlNN-server
> becomes a sub-port of mysqlNN-client.  You get to check a box saying
> 'install the server as well as the client' when you go to install
> mysqlNN.  Similarly all those php5-XYZ modules become sub-ports of
> lang/php5.  The big difference being that the port and all its sub-ports
> are compiled in one step, and just packaged separately. Which is
> probably less work overall that the current situation with ports and
> slave-ports.
>
> 	Cheers,
>
> 	Matthew
>
> [+] Or more likely you'ld use portupgrade or portmaster or similar to
> run these steps for you.
>
Hello,

It's exactly what I wanted to say. I think so that port system should 
adapt to this way of building ports. I mean that is instead of having 
vala, we have vala-bin, vala-doc, vala-lib and vala-examples, and port 
system don't untar vala archive for each port, but once and pick up 
files into this unique directory. Then no waste of time because untar is 
what takes most time for big ports.

We should still have a vala port, which is used to configure what we 
want (other subports -examples, -lib and -doc).

But where it can be very useful, it's when we have a big port made of 
many libraries, like Mono. We should be able to split it, because I 
don't want to build everything.

For the GNOME question, if an option in the GNOME configuration port 
says "[x] Yelp, will break help menus if not set", then no problem, 
don't you think ?


More information about the freebsd-ports mailing list