Port system "problems"

[Marcus von Appen]

On, Tue Jun 26, 2012, Florent Peterschmitt wrote:

> 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.

I can't see that from the rough outline given earlier. What I understood
is that some stagedir is used to build mono, then packages (-lib, -doc,
-whatever) are created and installed.
If you do not use downloaded packages, but install them yourself, you'd
need to rebuild the complete mono port on an update.

Happy to be corrected here
Marcus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20120626/dc8bf376/attachment.pgp