From owner-freebsd-ports@FreeBSD.ORG Tue Oct 8 11:28:07 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ED021682; Tue, 8 Oct 2013 11:28:07 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 564332A4E; Tue, 8 Oct 2013 11:28:07 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id q58so3523686wes.14 for ; Tue, 08 Oct 2013 04:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=CUHXGl1My215FadOzwR9Q73VOThI3gvRh1rrdL1A/Hw=; b=fkQIs/HXcefRjtxqn5wnDPbHFr8FsBzvzPjygt/JuZFNnYJlraa+lXT71aQURWO8Kx XLw1cmIwnJV4LGLHnEKJK/h7wfrLWnLHpQ9GaI/aOUnIqc2oWg71eUbyJud0rhKdii8q J/ow7g7befck8wlUKTnxoYMAbPQ4ihcyWIep+wfF3v7vlWY18twbyBms/hGXzUwc8k0K qFi3HqfVFkc800EssXRH8I/ZxxMFVnx1dORPvoklQy+mxNwVwVdwjeQ9/7zazJ6VU397 iGSgPmDE4xL/TuC8JkxEUoPfWcwbcqfdkegaKfhXMwn5CEYXX9dIoe31e0r2mHJqGtLx 8Y8A== X-Received: by 10.180.105.36 with SMTP id gj4mr1192312wib.14.1381231685814; Tue, 08 Oct 2013 04:28:05 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id ft19sm4236742wic.5.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 08 Oct 2013 04:28:05 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 8 Oct 2013 13:28:02 +0200 From: Baptiste Daroussin To: Ulrich =?iso-8859-1?Q?Sp=F6rlein?= Subject: Re: [HEADSUP] Staging, packaging and more Message-ID: <20131008112802.GN16964@ithaqua.etoilebsd.net> References: <20131003203501.GA1371@medusa.sysfault.org> <20131004061833.GA1367@medusa.sysfault.org> <20131004063259.GC72453@ithaqua.etoilebsd.net> <20131004065753.GV82824@droso.dk> <20131004070158.GE72453@ithaqua.etoilebsd.net> <20131004111256.GC98118@admin.xzibition.com> <20131008084721.GJ16964@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U6leaJ20qZQc29iB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@freebsd.org, Bryan Drewery X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:28:08 -0000 --U6leaJ20qZQc29iB Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 08, 2013 at 01:21:40PM +0200, Ulrich Sp=F6rlein wrote: > 2013/10/8 Baptiste Daroussin : > > On Sun, Oct 06, 2013 at 02:20:21PM +0200, Ulrich Sp=F6rlein wrote: > >> 2013/10/4 Bryan Drewery : > >> > 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 wrot= e: > >> >> > > > > > > > >> >> > > > > > > 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 platf= orms is a > >> >> > > > lot of confusion by people, why their custom software XYZ doe= s not > >> >> > > > properly build - the most common answer: they forgot to insta= ll 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 n= eed to > >> >> > > > install several libGL-dev, libX11-dev, ... packages first. > >> >> > > > This is something, which I personally see as a big plus of th= e FreeBSD > >> >> > > > ports system and which makes FreeBSD attractive as a developm= ent platform. > >> >> > > > > >> >> > > > >> >> > > On the other ends, that makes the package fat for embedded syst= ems, that also > >> >> > > makes some arbitrary runtime conflicts between packages (becaus= e 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 tracki= ng. 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 direct= ion. Should we be > >> >> > > nicer with developers? with end users? with embedded world? Tha= t 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 diff= erent > >> >> > name as we've used the -devel suffix for many years for developme= ntal > >> >> > versions. > >> >> > > >> >> > I must agree that it is one of the things high on my list of thin= gs that > >> >> > irritate me with several Linux distributions but I can see the po= int for > >> >> > for embedded systems as well. But can't we have both? Create th= ree > >> >> > 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 backgro= und, > >> >> > 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 > > > > You are totally misunderstanding the goal of sub packages. Right now pe= ople are > > asking for nox11, noportdocs, noportexamples, etc and all sort of knob,= when > > building resulting in a nightmare for the package system, a given packa= ge might > > or might not have a file depending on the knob, this is totally insane. >=20 > Yes it is, and I fully understand that part and have been advocating > for one package that has everything, but might only extract 80% > depending on OPTIONS, for some time now. >=20 > I just don't want us to have 20.000 ports now, and then 40.000 ports > because we split things into user/dev ports/packages. >=20 > I'm totally cool with having a tweaked package here and there to fix > several annoyances as you've outlined below. Seriously, make it > happen! >=20 > A user should not care, if not installing headers for package X solves > a conflict, do it! But please don't make it a default to not install > headers because 3% of the FreeBSD system builders might find it > useful. >=20 > It looks like a lot of the arguments are because there's a different > understanding of what a -dev package is, and of course everyone just > knows what they are in linux-land, and they suck. That's why you see > some pushback on this list. >=20 > > Here is a list of things the sub package solves (among full other thing= s): > > - Stupid conflicts like libjpeg and libjpeg-turbo, that conflicts becau= se they > > have the same dev files, meaning that people cannot end up with packa= ges > > bringing both libraries where there are no technical restrictions abo= ut it. a > > more accurate examples is probably all the databases clients like pgs= ql or > > mysql etc. > > - Allow to not split in tons of different ports things like qt and php. >=20 > Yes, please! >=20 > > - Not providing .h, .a, .la, etc files also makes it more complicated f= or > > someone to build something on a production server. Why the hell does a > > production would need a compiler and anything related to build? excep= t making > > it easier for an attacked to build and run its own software easily th= at has no > > meaning imho. >=20 > That argument doesn't hold. If an attacker can upload source code to a > machine, they can also upload > binaries. But yeah, people might want to do this for whatever lock-down r= easons. >=20 > > - Allow to bring cross compilation in the ports tree without too much h= eadache. > > To get cross compilation working the more atomic the packages are the= simpler > > it is. As we need for some build to have both native and target packa= ges for > > example gettext: all the bin/* should be native one and are needed wh= ile > > building, whereas we need target version of libintl. Same goes for li= bxstl and > > xsltproc, it is very easier to flag them if they are small packages. = (Yes I am > > really close to get cross buidling working in the ports tree and yes = having > > splitted packages will help me a lot here.) >=20 > Ah, so they actually solve a big problem for the FreeBSD project, I > wasn't aware of that. >=20 > > - Yes diskspace and bandwidth matters, Not everyone has a large bandwid= th > > internet access, I have personnally setup a couple of FreeBSD servers= in > > countries, bandwidth is not cheap at all. >=20 > All claims about this approach saving bandwidth should provide the > numbers that a bin/dev package split will actually save them. I don't > say it doesn't, but this is easy to measure and would make the > argument that much stronger ... >=20 > > If you all want flat packages then stop asking for nox11 nonls nodocs e= tc. > > > > Some examples of weirdness because we do not split packages: > > - glib2 bring python as a dependency (just because a developper only sc= ript is > > in python), and NO glib port has not to be fixed here it does what we= should > > do. > > - Lots of people complained about pkg-config being a run dep. But if we= are > > consistent every single port bring .pc files should then run depend on > > pkg-config because .pc files are useless without pkg-config. > > - People complain about having to depend on the full fat gcc46 just bec= ause of the > > fact that their packages is linked to on of the libraries part of gcc= 46. >=20 > But how would you save on bandwidth here? Will the gcc46 port result > in packages gcc46-bin.tbz, gcc46-dev.tbz, gcc46-lib.tbz, or will it be > one archive that selectively extracts things based on what the user > needs? Different packages selectively extracts will bring nothing useful. --U6leaJ20qZQc29iB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlJT7EIACgkQ8kTtMUmk6ExHyQCgltjlnn7r8QG7fZLi0yt3QNHu ouYAn1Zj9y4T7fyoSON9MNFpokdAsZEw =FtRH -----END PGP SIGNATURE----- --U6leaJ20qZQc29iB--