Baptiste Daroussin wrote:
On Fri, Oct 04, 2013 at 08:00:43AM +0100, Matthew Seaman wrote:
On 04/10/2013 07:32, Baptiste Daroussin wrote:
On the other ends, that makes the package fat for embedded systems, that also
makes some arbitrary runtime conflicts between packages (because they both
provide the same symlink on the .so, while we could live with 2 version at
runtime), that leads to tons of potential issue while building locally, and
that makes having sometime insane issues with dependency tracking. Why having
.a, .la, .h etc in production servers? It could greatly reduce PBI size, etc.

Personnaly I do have no strong opinion in one or another direction. Should we be
nicer with developers? with end users? with embedded world? That is the question
to face to decide if -devel packages is where we want to go or not.

Can't we have the best of both worlds?

We're already planning on creating sub-packages for eg. docs and
examples.  The default will be to install docs etc. sub-packages
automatically unless the user opts out in some way.  I imagine there
will be a global switch somewhere -- in pkg.conf or similar[*].

Couldn't we work devel packages in the same way? Install by default
alongside the main package unless explicitly requested not to.

I think having the capability to selectively install parts of packages
like this is important and useful functionality and something that will
be indispensible for eg. embedded platforms.  But not an option that the
vast majority of ordinary users will need to exercise.

        Cheers,

        Matthew

[*] The precise mechanism for choosing which sub-package bits to install
has not yet been written.  If anyone has any bright ideas about how this
should all work, then I'd be interested to hear them.


That is another possiblity, I do prefer Erwin's idea about the -full, but this
also makes a lot of sense.

I really like the current state with full packages. Disk space is cheap, full packages is default for whole FreeBSD existence and it is easy to maintain the system with it. If I want portA and portB, I just install portA and portB and if I want to see installed ports, I see two ports installed and not a bunch of lines like:
portA-bin
portA-doc
portA-dev
portB-bin
portB-doc
portB-dev

When I need to update those ports, I will update two ports, not six or more ports / sub ports.

Embedded systems are corner case, where many things need to be tweaked anyway.

So I like the idea of default full packages with possibility to optionally select and install sub parts for those who really need the fine grained list of packages.

Miroslav Lachman
_______________________________________________
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"

Reply via email to