Date: Fri, 4 Oct 2013 17:21:03 +1000 From: "Dewayne Geraghty" <dewayne.geraghty@heuristicsystems.com.au> To: "'Erwin Lansing'" <erwin@freebsd.org>, "'Baptiste Daroussin'" <bapt@freebsd.org> Cc: ports@freebsd.org Subject: RE: [HEADSUP] Staging, packaging and more Message-ID: <8A93D3653EA147F3AE1B388411E9D242@white> In-Reply-To: <20131004065753.GV82824@droso.dk> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: owner-freebsd-ports@freebsd.org=20 > [mailto:owner-freebsd-ports@freebsd.org] On Behalf Of Erwin Lansing > Sent: Friday, 4 October 2013 4:58 PM > To: Baptiste Daroussin > Cc: ports@freebsd.org; Fernando Apestegu=EDa > Subject: Re: [HEADSUP] Staging, packaging and more >=20 > On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote: > > > > > > > > > > > > Please no devel packages. > > > > > > > > > > Seconded. > > > > > > > > What's wrong with devel packages? > > >=20 > > > It complicates things for developers and custom software=20 > on FreeBSD.=20 > > > The typical situation that I see on most Linux platforms=20 > is a lot of=20 > > > confusion by people, why their custom software XYZ does=20 > not properly=20 > > > build - the most common answer: they forgot to install a=20 > tremendous=20 > > > amount of dev packages, containing headers, build tools=20 > and whatnot. > > > On FreeBSD, you can rely on the fact that if you installed e.g.=20 > > > libGL, you can start building your own GL applications=20 > without the=20 > > > need to install several libGL-dev, libX11-dev, ... packages first. > > > This is something, which I personally see as a big plus of the=20 > > > FreeBSD ports system and which makes FreeBSD attractive=20 > as a development platform. > > >=20 > >=20 > > On the other ends, that makes the package fat for embedded systems,=20 > > that also makes some arbitrary runtime conflicts between packages=20 > > (because they both provide the same symlink on the .so,=20 > while we could=20 > > live with 2 version at runtime), that leads to tons of=20 > potential issue=20 > > while building locally, and that makes having sometime=20 > insane issues=20 > > with dependency tracking. Why having .a, .la, .h etc in=20 > production servers? It could greatly reduce PBI size, etc. > >=20 > > Personnaly I do have no strong opinion in one or another direction.=20 > > Should we be nicer with developers? with end users? with embedded=20 > > world? That is the question to face to decide if -devel=20 > packages is where we want to go or not. > >=20 >=20 > If we chose to go down that path, at least we should chose a=20 > different name as we've used the -devel suffix for many years=20 > for developmental versions. >=20 > I must agree that it is one of the things high on my list of=20 > things that irritate me with several Linux distributions but=20 > I can see the point for for embedded systems as well. But=20 > can't we have both? Create three packages, a default full=20 > package and split packages of -bin, -lib, and even -doc. My=20 > first though twas to make the full package a meta-package=20 > that would install the split packages in the background, but=20 > that would probably be confusing for users at the end of the=20 > day, so rather just have it be a real package. >=20 > Erwin >=20 >=20 > --=20 > Erwin Lansing http://droso.dk > erwin@FreeBSD.org http:// www.FreeBSD.org >=20 We develop embedded systems - we build a minimal FreeBSD base, stripping = out named, ntpd, heimdal, openssl, etc. We then build a complete suite of packages for each CPU type of interest: Pentium3, = Prescott, Core2, K8. The package is then "repackaged" stripping out doc, examples etc. Before client equipment is updated, the entire = package suite is rebuilt, thoroughly tested and made available for client's updating process. If a development version is required and sometimes new options are = tested, then the package suite is rebuilt for development access. But this is getting into workflow/processes, a different topic. No multiple versions of anything, if we can avoid it. Simplicity is = paramount, and the integrity of the package suite is vital for support. Regards, Dewayne. PS We've been doing this a long time, we started stripping out heimdal = when FreeBSD was at 0.6.3 and the port was 1.0.1. We've maintained the paradigm and rely upon ports, over the FreeBSD base = applications - and yes, we do loose out on somethings, like gssd.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8A93D3653EA147F3AE1B388411E9D242>