harder and harder to avoid pkg
Kubilay Kocak
koobs at FreeBSD.org
Wed Oct 12 08:43:59 UTC 2016
On 12/10/2016 5:55 PM, Matthew Seaman wrote:
> On 11/10/2016 19:59, Julian Elischer wrote:
>> As the number of dependencies between packages get ever higher, it
>> becomes more and more difficult to compile packages and the
>> dependence on binary precompiled packages is increased. However
>> binary packages are unsuitable for some situations. We really need
>> to follow the lead of some of the Linux groups and have -runtime
>> and -devel versions of packages, OR we what woudlbe smarter,
>> woudl be to have several "sub manifests" to allow unpacking in
>> different environments.
>>
>>
>> A simple example: libxml2
>>
>> This package installs include files and libraries and dicumentation
>> etc.
>>
>> yet if I build an appliance , I want it to only install a singe
>> file.
>>
>> /usr/local/lib/libxml2.so.2
>>
>>
>> The presence of this file will satisfy any runtime dependencies of
>> packages that require it.
>>
>> Unfortunately there is no way to install just this file, and still
>> report that we have the package loaded, so
>>
>> pkg will always try to reinstall it leading to a huge mess.
>>
>> My current scheme is to unpack all packages into a larger staging
>> area, and *manually* (scripted) copy out only the files I need, and
>> then copy the pkg database, so that when run on the running
>> appliance, pkg THINKS all the packages are loaded on the appliance,
>> even though only the runtime files are installed. This is what we
>> in the industry call "a hack" :-) It is also not robust in the
>> face of changing pkg versions.
>>
>> It would be a lot better it pkg knew it was being asked to install
>> only the runtime set, and coudl accurately store this information
>> in its database, allowing it to satisfy the needs of other packages
>> that need that dependnency only in a runtime manner.
>>
>> Is any of this possible at the moment?
>>
>> suggestions from the ports/pkg community are appreciated..
>>
>> Julian
>
> You are describing the 'sub-packages' concept that has been knocking
> around for some time. With sub-packages you'ld divide up the result
> of staging each port into various chunks:
Yep, like this:
Mar 6 2016 - https://reviews.freebsd.org/D5563
Ports framework "variants" proof-of-concept (with poudriere support)
Status Report Dec 2015 - Supporting Variants in the Ports Framework
https://www.freebsd.org/news/status/report-2015-10-2015-12.html#Supporting-Variants-in-the-Ports-Framework
> - binaries + config file samples + required data files (the core pkg
> content) - shlibs - debug symbols - docs - examples - c/c++ headers
> and static or profiling libs (ie. only required for compilation) -
> various additional plugins etc. currently controlled by port options
>
> Each of these would be packaged separately and can be used
> independently for resolving dependencies. Building each port would
> result in as many of these sub packages as are applicable.
>
> Turning OPTIONS into sub-packages will also significantly reduce the
> number of OPTIONS settings needed in the ports tree (I think bapt had
> an estimate of about a 70% reduction but ICBW) and make the pkg
> system significantly better able to handle more varied user
> requirements without users having to compile their own packages.
>
> Unfortunately attention has been diverted while there's a lot of
> work going on towards packaging base. The problem as far as ports
> are concerned is producing several packages out of one port -- it's
> not rocket science level of difficulty to make that change, but the
> assumption of a one-to-one correspondence between ports and packages
> is deeply rooted, and it's going to take a lot of work to unpick.
Mar 6 2016 - https://reviews.freebsd.org/D5563
Ports framework "variants" proof-of-concept (with poudriere support)
> Happily, the package sets produced for the base system are already
> divided along these lines, so with a packaged base it is really very
> easy to produce a stripped down and streamlined base system.
>
> Cheers,
>
> Matthew
More information about the freebsd-ports
mailing list