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 ?
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
