[HEADSUP] Staging, packaging and more
bapt at FreeBSD.org
Fri Oct 4 13:29:51 UTC 2013
On Fri, Oct 04, 2013 at 02:22:52PM +0200, Miroslav Lachman wrote:
> 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:
> 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
> 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.
That is because you keep thinking you have to build those ports yourself, we are
here speaking of binary packages.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
More information about the freebsd-ports