[HEADSUP] Staging, packaging and more

Ulrich Spörlein uqs at FreeBSD.org
Tue Oct 8 11:21:41 UTC 2013

2013/10/8 Baptiste Daroussin <bapt at freebsd.org>:
> On Sun, Oct 06, 2013 at 02:20:21PM +0200, Ulrich Spörlein wrote:
>> 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
> 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.

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

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

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 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.

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 reasons.

> - 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.)

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 in
>   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 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.

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

> - 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.

Fair enough. Once dev-packages-by-default become a reality, there'll
be some more heated discussions :)


More information about the freebsd-ports mailing list