> -----Original Message----- > From: owner-freebsd-po...@freebsd.org > [mailto:owner-freebsd-po...@freebsd.org] On Behalf Of Ulrich Spörlein > Sent: Sunday, 6 October 2013 11:20 PM > To: Bryan Drewery > Cc: po...@freebsd.org; Baptiste Daroussin; Fernando Apesteguía > Subject: Re: [HEADSUP] Staging, packaging and more > Importance: Low > > 2013/10/4 Bryan Drewery <br...@shatow.net>: > > On Fri, Oct 04, 2013 at 09:01:58AM +0200, Baptiste Daroussin 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 to splitting packages for embedded usage. > > -1 for the split, as it will not fix anybody's problem. > > On regular machines, disk space is cheap and having to > install more packages is just annoying to users. Think of the > time wasted that people are told to apt-get libfoo-dev before > they can build anything from github, or similar. > > If you actually *are* space constricted on your tiny embedded > machine, what the fuck are you doing with the sqlite database > and all the metadata about ports/packages anyway? Just rm > /usr/include and /usr/share/doc, /usr/share/man, etc. when > building your disk image. > But you are doing that already anyway, so this solves no > actual problem for you. > > My two cents > Uli > _______________________________________________ > 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"
Concur with Uli, sans expletive. If you don't care about /var/db/pkg or sqlite then its easier to remove the unnecessary files after the build process and repackage the packages (tar --exclude), leaving the clients' servers to pkg_add -r -f And yes some ports require parts of share or (unbelievably) examples to function correctly. Pre-deployment testing or deployment is consistent because there's only one executable image to "track". Dewayne. _______________________________________________ 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"
