[HEADSUP] Staging, packaging and more

[Pascal Schmid]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/06/2013 07:21 PM, Bernhard Fröhlich wrote:
> On Sun, Oct 6, 2013 at 2:20 PM, Ulrich Spörlein <uqs at freebsd.org> 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
> 
> I also don't see why we need to optimize our packages for an embedded environment that is
> usually very customized. Wouldn't it make more sense to provide some proper port / packaging
> options/flags that help to optimize size of the packages without touching header files? People
> could use that flags and poudriere to build their packages together with all their other 
> compiler flags and cpu optimisations.
> 

+1

As far as I can see Daniel Nebdal's approach ("WITH_DEV_FILES" flag, and defaulting to "yes")
sounds promising.

Pascal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSUZ9hAAoJEAWefonBOgAfDlUP/3117hVdZ6WhrygIGnctSb49
V+i0SggAFxXuvFFYlkjexrWFpjMPN2H7vBtR9DVbLNwqb4En+mVj/LVY1ejS9TAQ
gj/nKlK6HNdVQWQD8qLfzFUAzWwnSBco/rIOiGkOrHuvFSUCTV5gPehoJ+Vg8Qnz
dyUp5SByePNpY1MGMTJZh9gKWJFtTe8DcanDBCVL65rZf/eOVPyiMwlQK+Fy2AQj
OQgJxhkWJzvl5V9THsMGiSCzJ+9EMoC620F9WEs3MvO0Ky2zIercFJ2bDaks6CXn
arNTsqTT1zI0sZNGNQMrnxYtQPgV3oCEAggj4ZOG0FkhmBkxWNOPUyahBUE/V8ds
tvLvugzVzqeaIJWg3IKDNEfGGh0ZnAMhUakUHyJPDhuCLgb498uwElesmgaSvlky
eotS4cWGVp2lquuf/xPRRl82K4ciozZi3mttRmrfoznK69p1HJbepCn9maIhFkii
WqLTjKVkeZ778is8mw8dom/Qb8OEj+XR6Vetq7cLg4Is//zieKzSvMWm7QrW1dAI
zohAjP+lMP5d3TEmeVqvSZhQ9ticzqGGaW4U7zxxRZ0Y/zxkBwe3cIBEpjTpnW9p
/a0DJ3JodVBo79N2JheIqweCK9RPn8rOK5HxujnWcJ3jbQAgCxOdLd9iyN6IxOjI
3pHI9pO++Am9ReFvL/Uy
=qm+q
-----END PGP SIGNATURE-----