Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Oct 2013 09:50:43 +0200
From:      =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= <fernando.apesteguia@gmail.com>
To:        Baptiste Daroussin <bapt@freebsd.org>
Cc:        ports@freebsd.org
Subject:   Re: [HEADSUP] Staging, packaging and more
Message-ID:  <CAGwOe2ZPbyNoF=0pDCdJfbbua8cCihguwBDURs0BtwesG5viVQ@mail.gmail.com>
In-Reply-To: <20131004070158.GE72453@ithaqua.etoilebsd.net>
References:  <20131003084814.GB99713@ithaqua.etoilebsd.net> <524D6059.2000700@FreeBSD.org> <524DD120.4000701@freebsd.org> <20131003203501.GA1371@medusa.sysfault.org> <CAGwOe2Ye2MLz3QpyMW3wyN9ew%2BiNnTETS1oOi_%2B8dPehUcWa0w@mail.gmail.com> <20131004061833.GA1367@medusa.sysfault.org> <20131004063259.GC72453@ithaqua.etoilebsd.net> <20131004065753.GV82824@droso.dk> <20131004070158.GE72453@ithaqua.etoilebsd.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 4, 2013 at 9:01 AM, Baptiste Daroussin <bapt@freebsd.org> wrote:

> On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote:
> > On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote:
> > > > > > >
> > > > > > > Please no devel packages.
> > > > > >
> > > > > > Seconded.
> > > > >
> > > > > What's wrong with devel packages?
> > > >
> > > > It complicates things for developers and custom software on
> > > > FreeBSD. The typical situation that I see on most Linux platforms is
> a
> > > > lot of confusion by people, why their custom software XYZ does not
> > > > properly build - the most common answer: they forgot to install a
> > > > tremendous amount of dev packages, containing headers, build tools
> and
> > > > whatnot.
> > > > On FreeBSD, you can rely on the fact that if you installed e.g.
> libGL,
> > > > you can start building your own GL applications without the need to
> > > > install several libGL-dev, libX11-dev, ... packages first.
> > > > This is something, which I personally see as a big plus of the
> FreeBSD
> > > > ports system and which makes FreeBSD attractive as a development
> platform.
> > > >
> > >
> > > 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.
> > >
> >
> > If we chose to go down that path, at least we should chose a different
> > name as we've used the -devel suffix for many years for developmental
> > versions.
> >
> > I must agree that it is one of the things high on my list of things that
> > irritate me with several Linux distributions but I can see the point for
> > for embedded systems as well.  But can't we have both?  Create three
> > packages, a default full package and split packages of -bin, -lib,
> > and even -doc.  My first though twas to make the full package a
> > meta-package that would install the split packages in the background,
> > but that would probably be confusing for users at the end of the day, so
> > rather just have it be a real package.
> >
> I do like that idea very much, and it is easily doable with stage :)
>

+1

If I'm going to install a FreeBSD system for normal PC use (firefox, media
player, etc) I don't need all the .h and developing stuff.

OTOH onn my machine I would like everything.

Would this increase a lot the number of packages/the time to build a new
repository?


>
> regards,
> Bapt
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGwOe2ZPbyNoF=0pDCdJfbbua8cCihguwBDURs0BtwesG5viVQ>