Prev: Be careful with fdopendir() on RELENG_7
Next: x11-toolkits/qt4-gui fails with png and/or zlib.h off64_t
From: Garrett Cooper on 30 Mar 2010 20:14
On Tue, Mar 30, 2010 at 1:54 PM, Arseny Nasokin <eirnym(a)gmail.com> wrote:
> On 31 Mar 2010, at 00:49, Garrett Cooper <yanefbsd(a)gmail.com> wrote:
>
>> On Tue, Mar 30, 2010 at 1:25 PM, Arseny Nasokin <eirnym(a)gmail.com> wrote:
>>>
>>> On 30 Mar 2010, at 23:14, Alexey Shuvaev
>>> <shuvaev(a)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
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Arseny Nasokin on 31 Mar 2010 00:36
On 31 Mar 2010, at 04:14, Garrett Cooper <yanefbsd(a)gmail.com> wrote:

> On Tue, Mar 30, 2010 at 1:54 PM, Arseny Nasokin <eirnym(a)gmail.com>
> wrote:
>> On 31 Mar 2010, at 00:49, Garrett Cooper <yanefbsd(a)gmail.com> wrote:
>>
>>> On Tue, Mar 30, 2010 at 1:25 PM, Arseny Nasokin <eirnym(a)gmail.com>
>>> wrote:
>>>>
>>>> On 30 Mar 2010, at 23:14, Alexey Shuvaev
>>>> <shuvaev(a)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

I can't see and discuss in IRC due browser and platform(software part)
limitations in nearest future.

I don't clearly understand, will be ports system removed? Will there
will be sourse and binary packages or will it be Gentoo-style
"portages", which will provide installation from binary or source with
options?

Almost all packages in my systems has custom settings.

_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Doug Barton on 31 Mar 2010 01:19
On 03/30/10 21:36, Arseny Nasokin wrote:
> I don't clearly understand, will be ports system removed?

At this time all discussion is theoretical. LONG before we make any
actual changes the users will have a chance to chime in, and will be
notified if any actual changes are made.


Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Garrett Cooper on 31 Mar 2010 02:16
On Tue, Mar 30, 2010 at 10:19 PM, Doug Barton <dougb(a)freebsd.org> wrote:
> On 03/30/10 21:36, Arseny Nasokin wrote:
>> I don't clearly understand, will be ports system removed?
>
> At this time all discussion is theoretical. LONG before we make any
> actual changes the users will have a chance to chime in, and will be
> notified if any actual changes are made.

Ports shouldn't ever be removed; it's just that the focus for
folks should be shifted to binary packages unless they have a pressing
urge to install packages from source, or don't want the bloat
associated with the package they're installing.
Doug is right though -- it's going to take a while before what's
being discussed is going to happen and we'll provide sufficient heads
up before the changes are made.
HTH,
-Garrett
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Garrett Cooper on 31 Mar 2010 02:20
On Tue, Mar 30, 2010 at 9:36 PM, Arseny Nasokin <eirnym(a)gmail.com> wrote:
> On 31 Mar 2010, at 04:14, Garrett Cooper <yanefbsd(a)gmail.com> wrote:
>
>> 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.
>
> I can't see and discuss in IRC due browser and platform(software part)
> limitations in nearest future.
>
> I don't clearly understand, will be ports system removed? Will there will be
> sourse and binary packages or will it be Gentoo-style "portages", which will
> provide installation from binary or source with options?

Gentoo portage is maintainer hell; we have enough fun with ports not
to get stuck in that mess.

> Almost all packages in my systems has custom settings.

Which is exactly why I advocate using ports for my desktops and
servers. I just have other vested interests outside of my personal
machines where binary packages are better suited than installed a
boatload of packages from source.

Cool thing is though, if people use standard packages, there's a
greater chance of there not being stability issues with the packages
themselves right (or at least all of the issues will be known
upfront)?

Thanks :),
-Garrett
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Be careful with fdopendir() on RELENG_7
Next: x11-toolkits/qt4-gui fails with png and/or zlib.h off64_t