From owner-freebsd-ports@FreeBSD.ORG Tue Oct 8 11:21:41 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 A5B9C1EC; Tue, 8 Oct 2013 11:21:41 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 60A5E29DC; Tue, 8 Oct 2013 11:21:41 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id wp4so375336obc.28 for ; Tue, 08 Oct 2013 04:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Wqz9AbRIc/RRTY0xfLkHm9AlU7gLOaNdDisH6TpG08Y=; b=dz+fjmvHH/3xQo8jDJyvR0Rxl1KqPqTvIE6kyWgOXKkkKDp0CQXK5Sia3Fa2Qo8BuM KEIFoR+xW6qhkXuDbRvgQxTcgap/oOVJdpZ4Esbl2X48O2TXVNFlIuTTyzCVTBaLw0Zh qScELHv7dqm36V6VckHjOH8TBcsoNSQ2dYzo3hS6bl6MqB8u8SkTnrbvY6Q5Sj5RowlC qggLkO486lXVcFiCflINY1wBC+mh5agixcKtt1kDvlbrg9jLA4icZVotWrgqWZe6HrXd 8gh4GF/0KjC1MVBo4HG9hzaz7I9RgV9Yxk/VcyaoD4OMuP3lUJKBoKzzLnYgeu9+O75U KZfg== MIME-Version: 1.0 X-Received: by 10.60.174.75 with SMTP id bq11mr793607oec.17.1381231300655; Tue, 08 Oct 2013 04:21:40 -0700 (PDT) Sender: uspoerlein@gmail.com Received: by 10.76.69.104 with HTTP; Tue, 8 Oct 2013 04:21:40 -0700 (PDT) In-Reply-To: <20131008084721.GJ16964@ithaqua.etoilebsd.net> References: <524D6059.2000700@FreeBSD.org> <524DD120.4000701@freebsd.org> <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> Date: Tue, 8 Oct 2013 13:21:40 +0200 X-Google-Sender-Auth: f89Mgufjft1KyFO483EGWOASYaU Message-ID: Subject: Re: [HEADSUP] Staging, packaging and more From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= To: Baptiste Daroussin , Bryan Drewery Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ports@freebsd.org 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:21:41 -0000 2013/10/8 Baptiste Daroussin : > On Sun, Oct 06, 2013 at 02:20:21PM +0200, Ulrich Sp=C3=B6rlein 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 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 platfor= ms 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 to= ols 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 nee= d 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 developmen= t platform. >> >> > > > >> >> > > >> >> > > On the other ends, that makes the package fat for embedded system= s, 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 v= ersion at >> >> > > runtime), that leads to tons of potential issue while building lo= cally, and >> >> > > that makes having sometime insane issues with dependency tracking= . Why having >> >> > > .a, .la, .h etc in production servers? It could greatly reduce PB= I size, etc. >> >> > > >> >> > > Personnaly I do have no strong opinion in one or another directio= n. 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 no= t. >> >> > > >> >> > >> >> > If we chose to go down that path, at least we should chose a differ= ent >> >> > name as we've used the -devel suffix for many years for development= al >> >> > 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 poin= t for >> >> > for embedded systems as well. But can't we have both? Create thre= e >> >> > 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 backgroun= d, >> >> > but that would probably be confusing for users at the end of the da= y, 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 peop= le are > asking for nox11, noportdocs, noportexamples, etc and all sort of knob, w= hen > building resulting in a nightmare for the package system, a given package= might > or might not have a file depending on the knob, this is totally insane. 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. 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. 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! 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. 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. > Here is a list of things the sub package solves (among full other things)= : > - Stupid conflicts like libjpeg and libjpeg-turbo, that conflicts because= they > have the same dev files, meaning that people cannot end up with package= s > bringing both libraries where there are no technical restrictions about= it. a > more accurate examples is probably all the databases clients like pgsql= or > mysql etc. > - Allow to not split in tons of different ports things like qt and php. Yes, please! > - Not providing .h, .a, .la, etc files also makes it more complicated for > someone to build something on a production server. Why the hell does a > production would need a compiler and anything related to build? except = making > it easier for an attacked to build and run its own software easily that= has no > meaning imho. 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 rea= sons. > - Allow to bring cross compilation in the ports tree without too much hea= dache. > To get cross compilation working the more atomic the packages are the s= impler > it is. As we need for some build to have both native and target package= s for > example gettext: all the bin/* should be native one and are needed whil= e > building, whereas we need target version of libintl. Same goes for libx= stl and > xsltproc, it is very easier to flag them if they are small packages. (Y= es I am > really close to get cross buidling working in the ports tree and yes ha= ving > splitted packages will help me a lot here.) Ah, so they actually solve a big problem for the FreeBSD project, I wasn't aware of that. > - Yes diskspace and bandwidth matters, Not everyone has a large bandwidth > internet access, I have personnally setup a couple of FreeBSD servers i= n > countries, bandwidth is not cheap at all. 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 ... > If you all want flat packages then stop asking for nox11 nonls nodocs etc= . > > Some examples of weirdness because we do not split packages: > - glib2 bring python as a dependency (just because a developper only scri= pt is > in python), and NO glib port has not to be fixed here it does what we s= hould > do. > - Lots of people complained about pkg-config being a run dep. But if we a= re > 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 becau= se of the > fact that their packages is linked to on of the libraries part of gcc46= . 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? > - Trying installing both gnome2 and kde4 on the same box this is impossib= le just > because gnome2 will at a moment pull in unixODBC and kde4 will pull in > libiodbc, which in fact doesn't conflict in a binary world, they only > conflicts on developpement only files! (don't tell me we don't have a > dependency hell here.) > > Concerning the dependency hell, we already have it, in fact it is easier = to > solve the dependency hell with small atomic packages than with big large > packages. The other way is to go doing PBIs like packages, but even doing= PBI, > will benefit a lot from splitted packages, because they will be smaller t= han the > acutal one, meaning faster to upgrade, faster to fetch, faster to install= , and > easier to maintain. (Remember they are created out of regular packages.) > > Concerning the fact that you need a couple of new packages to be able to > actually build something out github or whatever, this is a developer prob= lem and > doing pkg install gtk2-dev is not complicated at all. And remember that m= ost > users are NOT developers, they are just USERS they just want to get thing= s > running not to compile them. > > Once again I'm not advocacing for any kind of -dev packages yet, we have = lot of > more important problem to solve before going that way. Fair enough. Once dev-packages-by-default become a reality, there'll be some more heated discussions :) Cheers, UIi