Re: Old ports bugs analyzis
On Tue, Mar 30, 2010 at 10:19 PM, Doug Barton do...@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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
On Tue, Mar 30, 2010 at 9:36 PM, Arseny Nasokin eir...@gmail.com wrote:
On 31 Mar 2010, at 04:14, Garrett Cooper yanef...@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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
On 31 Mar 2010, at 10:20, Garrett Cooper yanef...@gmail.com wrote:
On Tue, Mar 30, 2010 at 9:36 PM, Arseny Nasokin eir...@gmail.com
wrote:
On 31 Mar 2010, at 04:14, Garrett Cooper yanef...@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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
On 31 Mar 2010, at 09:19, Doug Barton do...@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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
On Wed, Mar 31, 2010 at 12:59 AM, Arseny Nasokin eir...@gmail.com wrote:
On 31 Mar 2010, at 10:20, Garrett Cooper yanef...@gmail.com wrote:
On Tue, Mar 30, 2010 at 9:36 PM, Arseny Nasokin eir...@gmail.com wrote:
On 31 Mar 2010, at 04:14, Garrett Cooper yanef...@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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis [sic]
On Wed, 31 Mar 2010 01:39:35 -0700, Garrett Cooper yanef...@gmail.com articulated: On Wed, Mar 31, 2010 at 12:59 AM, Arseny Nasokin eir...@gmail.com wrote: On 31 Mar 2010, at 10:20, Garrett Cooper yanef...@gmail.com wrote: On Tue, Mar 30, 2010 at 9:36 PM, Arseny Nasokin eir...@gmail.com wrote: On 31 Mar 2010, at 04:14, Garrett Cooper yanef...@gmail.com wrote: [snip, snip, snip, snip] If I could just add my 2¢ to this discussion. I really appreciate the fact that, in most cases anyway, FreeBSD makes available through its maintainers a collection of up-to-date software. Now I realize that FreeBSD does have a (in my opinion unreasonable) problem with certain software in its base system that has an inappropriate GPL or whatever license, though this usually causes the end user no great harm. Now, many systems do not follow FreeBSD's lead. Some are still supplying, as an example Postfix 2.1 or other software that has been deprecated for over 3 years as their current versions. This causes users on these systems to either work with old software or roll their own which can lead to unforeseen problems. I would certainly hope that FreeBSD does not fall into that abyss. -- Jerry freebsd-ports.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ I will never lie to you. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
On 31 Mar 2010, at 12:39, Garrett Cooper yanef...@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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31/03/2010 17:45:21, Ulrich Spörlein wrote: 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. The term 'fat packages' suggests to me packages that incorporate binaries for several different CPU architectures -- there's precedent for that usage in MacOS X[*]. 'Polymorphic' would be a better term IMHO - -- pkgs could be both fat and polymorphic if desired. Cheers, Matthew [*] Whether fat-ness is managed by introducing a port of the MacOS lipo(1) application and modifying the way applications are run and that dynamic linking works to support multi-architecture binaries is the way to go, or whether having architecture specific parts of a pkg that are installed selectively would be better is no doubt something that will provide many hours of enjoyable debate. - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuziwYACgkQ8Mjk52CukIwMjACcC4wc4GcW4eERSpYTwoGEpzjy aGAAn1B/9A7vMy8LgeNhBkO9rYqQUafa =c6+5 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
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 BUILDRUN 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? :)
I put my analysys in several work files:
I've removed ${PORTSDIR} from paths for readability in index files.
http://freebsd.eroese.org/bsd.local.mk - different describe target
(clean and simple)
http://freebsd.eroese.org/portInfo.py - py-IDX maker. old, but enough version.
http://freebsd.eroese.org/tag - portsnap(8) tag
http://freebsd.eroese.org/IDX - special maked IDX
http://freebsd.eroese.org/py-IDX - human readable format of IDX, see
py program for comments about types.
I have tried to understand what is in these files but have not managed
it completely.
The file py-IDX lists 2 of my ports, devel/slglade and
x11-toolkits/gtkdatabox as being fixed:
fix devel/slglade
fix x11-toolkits/gtkdatabox
Could you elaborate more what was 'fixed' in these 2 examples?
Thanks,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
--
With pleasure
On 30 Mar 2010, at 23:14, Alexey Shuvaev shuv...@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 BUILDRUN 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
I put my analysys in several work files:
I've removed ${PORTSDIR} from paths for readability in index files.
http://freebsd.eroese.org/bsd.local.mk - different describe target
(clean and simple)
http://freebsd.eroese.org/portInfo.py - py-IDX maker. old, but
enough version.
http://freebsd.eroese.org/tag - portsnap(8) tag
http://freebsd.eroese.org/IDX - special maked IDX
http://freebsd.eroese.org/py-IDX - human readable format of IDX, see
py program for comments about types.
I have tried to understand what is in these files but have not managed
it completely.
The file py-IDX lists 2 of my ports, devel/slglade and
x11-toolkits/gtkdatabox as being fixed:
fix devel/slglade
fix x11-toolkits/gtkdatabox
Could you elaborate more what was 'fixed' in these 2 examples?
Thanks,
I've striped out debug output from top.
I've updated files py-IDX and python program.
And also put some documentation in file http://freebsd.eroese.org/docs
Thanks,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
On Tue, Mar 30, 2010 at 1:25 PM, Arseny Nasokin eir...@gmail.com wrote:
--
With pleasure
On 30 Mar 2010, at 23:14, Alexey Shuvaev shuv...@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 BUILDRUN 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.
I put my analysys in several work files:
I've removed ${PORTSDIR} from paths for readability in index files.
http://freebsd.eroese.org/bsd.local.mk - different describe target
(clean and simple)
http://freebsd.eroese.org/portInfo.py - py-IDX maker. old, but enough
version.
http://freebsd.eroese.org/tag - portsnap(8) tag
http://freebsd.eroese.org/IDX - special maked IDX
http://freebsd.eroese.org/py-IDX - human readable format of IDX, see
py program for comments about types.
I have tried to understand what is in these files but have not managed
it completely.
The file py-IDX lists 2 of my ports, devel/slglade and
x11-toolkits/gtkdatabox as being fixed:
fix devel/slglade
fix x11-toolkits/gtkdatabox
Could you elaborate more what was 'fixed' in these 2 examples?
Thanks,
I've striped out debug output from top.
I've updated files py-IDX and python program.
And also put some documentation in file http://freebsd.eroese.org/docs
Cheers,
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
On 31 Mar 2010, at 00:49, Garrett Cooper yanef...@gmail.com wrote:
On Tue, Mar 30, 2010 at 1:25 PM, Arseny Nasokin eir...@gmail.com
wrote:
--
With pleasure
On 30 Mar 2010, at 23:14, Alexey Shuvaev shuv...@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 BUILDRUN 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.
I put my analysys in several work files:
I've removed ${PORTSDIR} from paths for readability in index files.
http://freebsd.eroese.org/bsd.local.mk - different describe target
(clean and simple)
http://freebsd.eroese.org/portInfo.py - py-IDX maker. old, but
enough
version.
http://freebsd.eroese.org/tag - portsnap(8) tag
http://freebsd.eroese.org/IDX - special maked IDX
http://freebsd.eroese.org/py-IDX - human readable format of IDX,
see
py program for comments about types.
I have tried to understand what is in these files but have not
managed
it completely.
The file py-IDX lists 2 of my ports, devel/slglade and
x11-toolkits/gtkdatabox as being fixed:
fix devel/slglade
fix x11-toolkits/gtkdatabox
Could you elaborate more what was 'fixed' in these 2 examples?
Thanks,
I've striped out debug output from top.
I've updated files py-IDX and python program.
And also put some documentation in file http://freebsd.eroese.org/
docs
Cheers,
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
On Tue, Mar 30, 2010 at 1:54 PM, Arseny Nasokin eir...@gmail.com wrote:
On 31 Mar 2010, at 00:49, Garrett Cooper yanef...@gmail.com wrote:
On Tue, Mar 30, 2010 at 1:25 PM, Arseny Nasokin eir...@gmail.com wrote:
On 30 Mar 2010, at 23:14, Alexey Shuvaev
shuv...@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 BUILDRUN 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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
On 31 Mar 2010, at 04:14, Garrett Cooper yanef...@gmail.com wrote:
On Tue, Mar 30, 2010 at 1:54 PM, Arseny Nasokin eir...@gmail.com
wrote:
On 31 Mar 2010, at 00:49, Garrett Cooper yanef...@gmail.com wrote:
On Tue, Mar 30, 2010 at 1:25 PM, Arseny Nasokin eir...@gmail.com
wrote:
On 30 Mar 2010, at 23:14, Alexey Shuvaev
shuv...@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 BUILDRUN 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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Old ports bugs analyzis
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 BUILDRUN 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.
I put my analysys in several work files:
I've removed ${PORTSDIR} from paths for readability in index files.
http://freebsd.eroese.org/bsd.local.mk - different describe target
(clean and simple)
http://freebsd.eroese.org/portInfo.py - py-IDX maker. old, but enough version.
http://freebsd.eroese.org/tag - portsnap(8) tag
http://freebsd.eroese.org/IDX - special maked IDX
http://freebsd.eroese.org/py-IDX - human readable format of IDX, see
py program for comments about types.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
