On Sun, Oct 06, 2013 at 02:20:21PM +0200, Ulrich Spörlein wrote: > 2013/10/4 Bryan Drewery <br...@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
You are totally misunderstanding the goal of sub packages. Right now people are asking for nox11, noportdocs, noportexamples, etc and all sort of knob, when 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. 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 packages 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. - 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. - Allow to bring cross compilation in the ports tree without too much headache. 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 packages for example gettext: all the bin/* should be native one and are needed while building, whereas we need target version of libintl. Same goes for libxstl 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.) - Yes diskspace and bandwidth matters, Not everyone has a large bandwidth internet access, I have personnally setup a couple of FreeBSD servers in countries, bandwidth is not cheap at all. 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 script 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 because of the fact that their packages is linked to on of the libraries part of gcc46. - Trying installing both gnome2 and kde4 on the same box this is impossible 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 than 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 problem and doing pkg install gtk2-dev is not complicated at all. And remember that most users are NOT developers, they are just USERS they just want to get things 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. regards, Bapt
pgpSAy2eXQNrg.pgp
Description: PGP signature
