Old ports bugs analyzis

[Garrett Cooper]

On Tue, Mar 30, 2010 at 1:54 PM, Arseny Nasokin <eirnym at gmail.com> wrote:
> On 31 Mar 2010, at 00:49, Garrett Cooper <yanefbsd at gmail.com> wrote:
>
>> On Tue, Mar 30, 2010 at 1:25 PM, Arseny Nasokin <eirnym at gmail.com> wrote:
>>>
>>> On 30 Mar 2010, at 23:14, Alexey Shuvaev
>>> <shuvaev at physik.uni-wuerzburg.de>
>>> wrote:
>>>
>>>> On Tue, Mar 30, 2010 at 01:05:39AM +0400, Eir Nym wrote:
>>>>>
>>>>> I work on creating system for system and ports autobuilder with custom
>>>>> settings for my FreeBSD machines. I know about many programs, which do
>>>>> same, but I don't like strange depends, which are not controlled by
>>>>> OPTIONS and some another
>>>>>
>>>>> I've analyse ports tree and want to say about.
>>>>> There're lot problems with ports to create per-port PRs
>>>>> manually.Common types of problems are listed here:
>>>>>
>>>>> 0) Main part of problems in tons of ports, which has hidden options
>>>>> (WITH & WITHOUT checking), but not using OPTIONS for them.
>>>>> 1) There many libraries added with BUILD&RUN dependencies, not as
>>>>> LIB-DEPENDS.
>>>>> 2) Some ports has only BUILD depends to libraries, but links them
>>>>> dynamicly.
>>>>> 3) All(?) samba33 slaves define dependency as "samba33", and make
>>>>> warning me about master target redefinition when do something on them.
>>>>> 4) many ports define dependencies as
>>>>> "${.CURDIR}/../../<category>/<dep-port-name>"
>>>>> 5) And some adds trailing slash.
>>>>>
>>>>> I want fix these problems, but I have no much time to fix several
>>>>> thousands of ports. This work (include PR sending) needs about is 1-2
>>>>> month per 8-10 hours a day.
>>>>>
>>>> If the problems are so common, maybe there are not so many problems
>>>> at all? :)
>>>
>>> Yes, it's features! Let's all bugs will be features! Do you remember The
>>> Bat
>>> mail client, which doesn't want support standarts at all?
>>>
>>> Cases 0, 2, 3 and 4 are bugs.
>>> 0: I want to control options via OPTIONS, not by knowledge about Makefile
>>> syntax with much time.
>>> 2: build port, install, remove lib and get this port unusable.
>>> 3: where program should find package orign "samba33"?
>>> 4: when reading Makefile, it hard to explain where port is. And when
>>> ports
>>> tree has changed place in system, it's not good idea to rebuild index.
>>>
>>> 2, 5 are questions at most.
>>> 2: libraries should be LIB_DEPENDS
>>
>> Caveat: static libraries are build dependencies; dynamic libraries are
>> lib dependencies. We had a discussion about this on #bsdports
>> yesterday and it was a well understood fact that was being proposed
>> for a move forward in terms of installing binary packages.
>>
>
> Port building ability will be avaliable? Now ports tree has bugs, but I can
> turn on/of custom build options. I use most of ports with custom settings.

Today binary packages are rolled as generic as possible provided the
architecture they're built for and are monolithic, meaning that they
contain the build, lib, patch, and run dependencies required to build
everything, as they're generated after an in-place install in
${PREFIX} .

One of many ideas we were kicking around on #bsdports was to produce
`fat packages' which would be usable in package installation and ports
building scenarios (similar to the headache that exists in many Linux
distros with -devel and non-devel packages), but the user could
specify whether or not they wanted the -devel pieces or not (if it
applied) -- so only one set of packages would need to be distributed.

We didn't really kick the idea around too much, but it was still a
novelty that should be `nursed' to a proper conclusion as it would
allow folks who roll packages and install on embedded systems /
install bases, or prefer installing via packages, to have small
install bases, and smaller potential binary roll up after the fact.

Thanks,
-Garrett