> -----Original Message----- > From: owner-freebsd-po...@freebsd.org > [mailto:owner-freebsd-po...@freebsd.org] On Behalf Of Erwin Lansing > Sent: Friday, 4 October 2013 4:58 PM > To: Baptiste Daroussin > Cc: po...@freebsd.org; Fernando Apesteguía > Subject: Re: [HEADSUP] Staging, packaging and more > > 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. > > Erwin > > > -- > Erwin Lansing http://droso.dk > er...@freebsd.org http:// www.FreeBSD.org >
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. _______________________________________________ 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"
