Date: Mon, 07 Oct 2013 05:21:48 -0500 From: Bryan Drewery <bryan@shatow.net> Cc: ports@freebsd.org Subject: Re: [HEADSUP] Staging, packaging and more Message-ID: <52528B3C.5020906@shatow.net> In-Reply-To: <7D0F44D08D6643B9AA3EA3FD2E5DB255@white> 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> <7D0F44D08D6643B9AA3EA3FD2E5DB255@white>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/6/2013 9:16 PM, Dewayne Geraghty wrote: >> -----Original Message----- >> From: owner-freebsd-ports@freebsd.org >> [mailto:owner-freebsd-ports@freebsd.org] On Behalf Of Ulrich Spörlein >> Sent: Sunday, 6 October 2013 11:20 PM >> To: Bryan Drewery >> Cc: ports@freebsd.org; Baptiste Daroussin; Fernando Apesteguía >> Subject: Re: [HEADSUP] Staging, packaging and more >> Importance: Low >> >> 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 >> 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. Are you suggesting we should just auto install all of ports then? The hassle of installing required dependencies for something outside of the normal system is going to happen either way. >> >> 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 > Concur with Uli, sans expletive. Subpackages has no harm to anyone. The idea that "too many packages hurts me" is bad. It's 1 more entry in 'pkg info'. The overall savings in BW/Space is good for everyone. It makes upgrades faster for non-developer users who don't need headers. A lot of ports already track DOCS/EXAMPLES. Subpackages are just an extension/refactoring of that effort. There are plenty of ideas and ways to make this user friendly by automatically installing/depending on the subpackages, as they effectively are today with DOCS/EXAMPLES options. > > 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 The suggestions to rm -rf /usr/include etc and /var/db/pkg are big hacks that will break binary package upgrades. Don't forget that is the end goal here. > And yes some ports require parts of share or (unbelievably) examples to function correctly. You say some can't work, but still suggest to rm -rf it. That is not a good solution. The package maintainer should define that so the package works, without you hacking at it. If a port incorrectly does not work without EXAMPLES, you need to tell the maintainer. > > 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?52528B3C.5020906>