[HEADSUP] Staging, packaging and more

[Mathias Picker]

Am Samstag, den 05.10.2013, 11:57 +0200 schrieb Miroslav Lachman:
> 
> Baptiste Daroussin wrote:
> > 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:
> >> 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.
> >
> > That is because you keep thinking you have to build those ports yourself, we are
> > here speaking of binary packages.
> 
> I don't think it's about building ports. It's about the list of what I 
> need to have installed and maintained on our systems. And with this 
> split to more packages, then the list will grow and tracking of changes 
> and dependencies will become hell like on Linux distributions.

+1

Mathias

> 
> Miroslav Lachman
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"