Date: Mon, 7 Oct 2013 13:16:11 +1100 From: "Dewayne Geraghty" <dewayne.geraghty@heuristicsystems.com.au> To: "'Bryan Drewery'" <bryan@shatow.net> Cc: ports@freebsd.org Subject: RE: [HEADSUP] Staging, packaging and more Message-ID: <7D0F44D08D6643B9AA3EA3FD2E5DB255@white> In-Reply-To: <CAJ9axoSF2%2BRys6MG078XCEkKEs2kEpVJegGgqFN3b2t2%2BR80kw@mail.gmail.com> 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> <20131004111256.GC98118@admin.xzibition.com> <CAJ9axoSF2%2BRys6MG078XCEkKEs2kEpVJegGgqFN3b2t2%2BR80kw@mail.gmail.com>
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 Ulrich = Sp=F6rlein > Sent: Sunday, 6 October 2013 11:20 PM > To: Bryan Drewery > Cc: ports@freebsd.org; Baptiste Daroussin; Fernando Apestegu=EDa > Subject: Re: [HEADSUP] Staging, packaging and more > Importance: Low >=20 > 2013/10/4 Bryan Drewery <bryan@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=20 > Daroussin wrote: > >> > > > > > > > >> > > > > > > Please no devel packages. > >> > > > > > > >> > > > > > Seconded. > >> > > > > > >> > > > > What's wrong with devel packages? > >> > > > > >> > > > It complicates things for developers and custom software on=20 > >> > > > FreeBSD. The typical situation that I see on most Linux=20 > >> > > > platforms is a lot of confusion by people, why their custom=20 > >> > > > software XYZ does not properly build - the most=20 > common answer:=20 > >> > > > they forgot to install a tremendous amount of dev packages,=20 > >> > > > containing headers, build tools and whatnot. > >> > > > On FreeBSD, you can rely on the fact that if you=20 > installed e.g.=20 > >> > > > libGL, you can start building your own GL=20 > applications without=20 > >> > > > the need to install several libGL-dev, libX11-dev,=20 > ... packages first. > >> > > > This is something, which I personally see as a big=20 > plus of the=20 > >> > > > FreeBSD ports system and which makes FreeBSD=20 > attractive as a development platform. > >> > > > > >> > > > >> > > On the other ends, that makes the package fat for embedded=20 > >> > > systems, that also makes some arbitrary runtime=20 > conflicts between=20 > >> > > packages (because they both provide the same symlink=20 > on the .so,=20 > >> > > while we could live with 2 version at runtime), that leads to=20 > >> > > tons of potential issue while building locally, and that makes=20 > >> > > having sometime insane issues with dependency=20 > tracking. Why having .a, .la, .h etc in production servers?=20 > It could greatly reduce PBI size, etc. > >> > > > >> > > Personnaly I do have no strong opinion in one or another=20 > >> > > direction. Should we be nicer with developers? with end users?=20 > >> > > with embedded world? That is the question to face to=20 > 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=20 > >> > different name as we've used the -devel suffix for many=20 > years for=20 > >> > developmental versions. > >> > > >> > I must agree that it is one of the things high on my=20 > list of things=20 > >> > that irritate me with several Linux distributions but I=20 > can see the=20 > >> > point for for embedded systems as well. But can't we=20 > have both? =20 > >> > Create three packages, a default full package and split=20 > packages of=20 > >> > -bin, -lib, and even -doc. My first though twas to make=20 > the full=20 > >> > package a meta-package that would install the split=20 > packages in the=20 > >> > background, but that would probably be confusing for=20 > users at the=20 > >> > 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=20 > with stage :) > > > > +1 to splitting packages for embedded usage. >=20 > -1 for the split, as it will not fix anybody's problem. >=20 > On regular machines, disk space is cheap and having to=20 > install more packages is just annoying to users. Think of the=20 > time wasted that people are told to apt-get libfoo-dev before=20 > they can build anything from github, or similar. >=20 > If you actually *are* space constricted on your tiny embedded=20 > machine, what the fuck are you doing with the sqlite database=20 > and all the metadata about ports/packages anyway? Just rm=20 > /usr/include and /usr/share/doc, /usr/share/man, etc. when=20 > building your disk image. > But you are doing that already anyway, so this solves no=20 > actual problem for you. >=20 > My two cents > Uli > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to=20 > "freebsd-ports-unsubscribe@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7D0F44D08D6643B9AA3EA3FD2E5DB255>