[HEADSUP] Staging, packaging and more

[Dewayne Geraghty]

> -----Original Message-----
> From: owner-freebsd-ports at freebsd.org 
> [mailto:owner-freebsd-ports at freebsd.org] On Behalf Of Ulrich Spörlein
> Sent: Sunday, 6 October 2013 11:20 PM
> To: Bryan Drewery
> Cc: ports at freebsd.org; Baptiste Daroussin; Fernando Apesteguía
> Subject: Re: [HEADSUP] Staging, packaging and more
> Importance: Low
> 
> 2013/10/4 Bryan Drewery <bryan at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to 
> "freebsd-ports-unsubscribe at 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.