Prev: Be careful with fdopendir() on RELENG_7
Next: x11-toolkits/qt4-gui fails with png and/or zlib.h off64_t
From: Arseny Nasokin on 31 Mar 2010 03:59
On 31 Mar 2010, at 10:20, Garrett Cooper <yanefbsd(a)gmail.com> wrote:

> 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

If we are talk about specialized optimisations or customisations we
should talk about ports system. If we talk about desktop machines,
there binary packages are better in most cases (for example, using
Synaptics frontend)
_______________________________________________
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 04:01
On 31 Mar 2010, at 09:19, 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.
>
>
> 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/
>

Understand, thanks. Can I help with something?
_______________________________________________
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 04:39
On Wed, Mar 31, 2010 at 12:59 AM, Arseny Nasokin <eirnym(a)gmail.com> wrote:
> On 31 Mar 2010, at 10:20, Garrett Cooper <yanefbsd(a)gmail.com> wrote:
>
>> 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
>
> If we are talk about specialized optimisations or customisations we should
> talk about ports system. If we talk about desktop machines, there binary
> packages are better in most cases (for example, using Synaptics frontend)

YMMV, but most of the time binary packages are built with the idea in
mind that it will meet the majority of the end-users' needs instead of
a specific case (unless there is a good reason for there being
variance, in that case ports are split, i.e. vim, vim-lite, etc).

There is a small amount of optimization that can be gained by using
proper CFLAGS as well with more modern hardware (let's face it.. the
default flags that binary packages are built with are meant to run on
generic old-school IBM clones all the way up to the most bleeding edge
AMD and Intel processors for instance) -- so if you use the
appropriate CPUTYPE and CFLAGS you can gain performance wise, because
you're tailoring the programs you compile to meet your system's
capabilities. You just have to be careful because ricing is something
that Gentoo users got themselves in trouble with back around 2003 ~
2004, and then I think that most people learned that they weren't
really gaining much in performance and were losing in stability, so
they stopped ricing their compiles.

Cheers,
-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 06:28
On 31 Mar 2010, at 12:39, Garrett Cooper <yanefbsd(a)gmail.com> wrote:
>> If we are talk about specialized optimisations or customisations we
>> should
>> talk about ports system. If we talk about desktop machines, there
>> binary
>> packages are better in most cases (for example, using Synaptics
>> frontend)
>
> YMMV, but most of the time binary packages are built with the idea in
> mind that it will meet the majority of the end-users' needs instead of
> a specific case (unless there is a good reason for there being
> variance, in that case ports are split, i.e. vim, vim-lite, etc).
>
> There is a small amount of optimization that can be gained by using
> proper CFLAGS as well with more modern hardware (let's face it.. the
> default flags that binary packages are built with are meant to run on
> generic old-school IBM clones all the way up to the most bleeding edge
> AMD and Intel processors for instance) -- so if you use the
> appropriate CPUTYPE and CFLAGS you can gain performance wise, because
> you're tailoring the programs you compile to meet your system's
> capabilities. You just have to be careful because ricing is something
> that Gentoo users got themselves in trouble with back around 2003 ~
> 2004, and then I think that most people learned that they weren't
> really gaining much in performance and were losing in stability, so
> they stopped ricing their compiles.
>
> Cheers,
> -Garrett

I've talked about custom built-in settings. Different options are need
in different situations. We doesn't have any real statistics about
options use.

For example, gvim(1) is good idea on most desktop systems, but after
some issue, I build vim without GUI support. Issue is simple:

Start x11, run xterm, run screen in it, detach, shutdown x11 server.
Attach to screen from text mode and run vim. You'll get at least
warning and slow startup.
Second issue about is why should X11 be on headless server?

What should we do in this case? Create 10-20 packages for every
program? Or provide customisation interface (ports tree)?

If second we can provide ports tree, which can download prebuild
package if common options are used or build it in other case or if
user want it.

_______________________________________________
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: Ulrich =?utf-8?B?U3DDtnJsZWlu?= on 31 Mar 2010 12:45
On Wed, 31.03.2010 at 14:28:46 +0400, Arseny Nasokin wrote:
> I've talked about custom built-in settings. Different options are need
> in different situations. We doesn't have any real statistics about
> options use.
>
> For example, gvim(1) is good idea on most desktop systems, but after
> some issue, I build vim without GUI support. Issue is simple:
>
> Start x11, run xterm, run screen in it, detach, shutdown x11 server.
> Attach to screen from text mode and run vim. You'll get at least
> warning and slow startup.
> Second issue about is why should X11 be on headless server?
>
> What should we do in this case? Create 10-20 packages for every
> program? Or provide customisation interface (ports tree)?
>
> If second we can provide ports tree, which can download prebuild
> package if common options are used or build it in other case or if
> user want it.

This has been floated around in this thread as "fat packages", where you
basically have the build cluster build a port, eg. three ways. In our
case vim-lite (no x11), vim (gui) and vim-full (perl, cscope, ...).
These three runs can than be combined into one fat package. As they
share documentation and other "share/" data, only the binaries/libraries
need to be stored 3x in the package and compression should nullify the
..tbz growth further.

Same could be done for mplayer, an mplayer-full "flavour" an
mplayer-free flavour using only free codecs, etc. Similar things can be
done for mysql's or openldap's -client and -server packages.

In summary, pkg_add vim on a server without X11 libs can then decide to
extract the non-X11 variant, while someone on a desktop system will get
a bigger version.

This however, needs better pkg_ tools, more/faster hardware in the build
cluster and a ton of volunteer work that is hard to come by these days
....

Regards,
Uli
_______________________________________________
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