gettext/GPLv4 virus infects FreeBSD - BSD

This is a discussion on gettext/GPLv4 virus infects FreeBSD - BSD ; Steve O'Hara-Smith wrote: > > > > Sure, that's remarkable indeed, I definitely appreciate the time and > > effort the volunteers are investing in to development of the FreeBSD > > base and ports system. There, however, always is ...

+ Reply to Thread
Page 4 of 5 FirstFirst ... 2 3 4 5 LastLast
Results 61 to 80 of 87

Thread: gettext/GPLv4 virus infects FreeBSD

  1. Re: gettext/GPLv4 virus infects FreeBSD

    Steve O'Hara-Smith wrote:
    > >
    > > Sure, that's remarkable indeed, I definitely appreciate the time and
    > > effort the volunteers are investing in to development of the FreeBSD
    > > base and ports system. There, however, always is a room for improvement,
    > > and the rectification of the said flaws in ports build system, I have
    > > pointed out in an earlier post, would be a superlative melioration.

    >
    > So you have patches and/or time to contribute that will improve
    > matters ?
    >


    This is a *very* poor argument. Contributions have appeared in the past,
    and new ones will appear in the future. This is not the problem. The
    problem is that there is no consensus on the direction to move, there is
    a vocal set of users (*) who think that the present system is superior to
    anything in existence, and nothing must change. The fact that people are
    deserting in mass to greener pastures don't distract them at all to
    their main aim: that they can continue exploiting their hard gained
    knowledge of the old system, and never need to learn something new.

    (*) there is also a set of competent developers who beleive that the
    present system is suboptimal, but will think until the end of time to
    the most perfect, canonical or functorial way of managing the system,
    and coding it in the most exquisite way. Hacking something around the
    present system is in no way a task they are interested in. Finally
    they agree with the set of "dumb users" alluded above to keep the status
    quo, which is better than any hackish improvement.

    --

    Michel TALON


  2. Re: gettext/GPLv4 virus infects FreeBSD

    Paco wrote:
    > Ran cvsup today and was blown away be the number of ports needing to be
    > upgraded, over 100! Looking in UPDATING's entry for 20080605 finds "Given
    > the scope and sheer number of dependent ports, it may be more advisable
    > to simply blow away all existing install ports (after keeping any local
    > configuration changes), and rebuilding from scratch."! Say what?


    I'll seize the opportunity to ask a question about the port system i've
    never dare asking.

    In a situation like this, i imagine bsd.port.mk is updated in a way that
    if gettext is required then the new version is used. This new version
    overwrite the old one and thus makes all previous installed ports broken
    because the old shared lib disappeared.
    To prevent this to happen, all packages that depends on gettext is
    bumped to a new version, and so are automatically recompiled by tools
    which does full upgrades (like portmaster -a, etc) OR 'easily' spotted
    with pkg_version and thus can be updated manually by as many 'make
    install clean' as necessary.
    Am i right on this or far away from the reality ?

  3. Re: gettext/GPLv4 virus infects FreeBSD

    Paco wrote:
    > Ran cvsup today and was blown away be the number of ports needing to be
    > upgraded, over 100! Looking in UPDATING's entry for 20080605 finds "Given
    > the scope and sheer number of dependent ports, it may be more advisable
    > to simply blow away all existing install ports (after keeping any local
    > configuration changes), and rebuilding from scratch."! Say what?


    I'll seize the opportunity to ask a question about the port system i've
    never dare asking.

    In a situation like this, i imagine bsd.port.mk is updated in a way that
    if gettext is required then the new version is used. This new version
    overwrite the old one and thus makes all previous installed ports broken
    because the old shared lib disappeared.
    To prevent this to happen, all packages that depends on gettext is
    bumped to a new version, and so are automatically recompiled by tools
    which does full upgrades (like portmaster -a, etc) OR 'easily' spotted
    with pkg_version and thus can be updated manually by as many 'make
    install clean' as necessary.
    Am i right on this or far away from the reality ?

  4. Re: gettext/GPLv4 virus infects FreeBSD

    In comp.unix.bsd.freebsd.misc coolix wrote:
    > Paco wrote:
    > > Ran cvsup today and was blown away be the number of ports needing to be
    > > upgraded, over 100! Looking in UPDATING's entry for 20080605 finds "Given
    > > the scope and sheer number of dependent ports, it may be more advisable
    > > to simply blow away all existing install ports (after keeping any local
    > > configuration changes), and rebuilding from scratch."! Say what?

    >
    > I'll seize the opportunity to ask a question about the port system i've
    > never dare asking.
    >
    > In a situation like this, i imagine bsd.port.mk is updated in a way that
    > if gettext is required then the new version is used. This new version


    I don't think this requires a modification of bsd.ports.mk.

    > overwrite the old one and thus makes all previous installed ports broken
    > because the old shared lib disappeared.


    Except if you use a tool like portupgrade which keeps a copy of the old
    shared lib, so that old programs continue to work.

    > To prevent this to happen, all packages that depends on gettext is
    > bumped to a new version, and so are automatically recompiled by tools
    > which does full upgrades (like portmaster -a, etc) OR 'easily' spotted
    > with pkg_version and thus can be updated manually by as many 'make
    > install clean' as necessary.
    > Am i right on this or far away from the reality ?


    You seem to be right.

    --

    Michel TALON


  5. Re: gettext/GPLv4 virus infects FreeBSD

    In comp.unix.bsd.freebsd.misc coolix wrote:
    > Paco wrote:
    > > Ran cvsup today and was blown away be the number of ports needing to be
    > > upgraded, over 100! Looking in UPDATING's entry for 20080605 finds "Given
    > > the scope and sheer number of dependent ports, it may be more advisable
    > > to simply blow away all existing install ports (after keeping any local
    > > configuration changes), and rebuilding from scratch."! Say what?

    >
    > I'll seize the opportunity to ask a question about the port system i've
    > never dare asking.
    >
    > In a situation like this, i imagine bsd.port.mk is updated in a way that
    > if gettext is required then the new version is used. This new version


    I don't think this requires a modification of bsd.ports.mk.

    > overwrite the old one and thus makes all previous installed ports broken
    > because the old shared lib disappeared.


    Except if you use a tool like portupgrade which keeps a copy of the old
    shared lib, so that old programs continue to work.

    > To prevent this to happen, all packages that depends on gettext is
    > bumped to a new version, and so are automatically recompiled by tools
    > which does full upgrades (like portmaster -a, etc) OR 'easily' spotted
    > with pkg_version and thus can be updated manually by as many 'make
    > install clean' as necessary.
    > Am i right on this or far away from the reality ?


    You seem to be right.

    --

    Michel TALON


  6. Re: gettext/GPLv4 virus infects FreeBSD

    On Tue, 24 Jun 2008 13:50:43 +0000 (UTC)
    talon@lpthe.jussieu.fr (Michel Talon) wrote:

    > Steve O'Hara-Smith wrote:
    > > >
    > > > Sure, that's remarkable indeed, I definitely appreciate the time and
    > > > effort the volunteers are investing in to development of the FreeBSD
    > > > base and ports system. There, however, always is a room for
    > > > improvement, and the rectification of the said flaws in ports build
    > > > system, I have pointed out in an earlier post, would be a superlative
    > > > melioration.

    > >
    > > So you have patches and/or time to contribute that will improve
    > > matters ?
    > >

    >
    > This is a *very* poor argument. Contributions have appeared in the past,
    > and new ones will appear in the future. This is not the problem. The
    > problem is that there is no consensus on the direction to move, there is
    > a vocal set of users (*) who think that the present system is superior to
    > anything in existence, and nothing must change.


    A clear analysis of the perceived problems would be a great
    contribution. Personally I'm not unhappy with ports or pkgsrc so I'm not
    about to produce that analysis. If that analysis were followed by an
    outline design that provides the benefits of the current system and avoids
    the problems highlighted in the analysis then that would be even better and
    could provide a clear direction. However "something more like X" for
    various values of X does not achieve this, especially when there are people
    able to identify ways in which the current system could be viewed as better
    than X.

    --
    C:>WIN | Directable Mirror Arrays
    The computer obeys and wins. | A better way to focus the sun
    You lose and Bill collects. | licences available see
    | http://www.sohara.org/

  7. Re: gettext/GPLv4 virus infects FreeBSD

    On 06/24/2008 07:59 PM, Steve O'Hara-Smith wrote:
    > A clear analysis of the perceived problems would be a great
    > contribution. Personally I'm not unhappy with ports or pkgsrc so I'm not
    > about to produce that analysis. If that analysis were followed by an
    > outline design that provides the benefits of the current system and avoids
    > the problems highlighted in the analysis then that would be even better and
    > could provide a clear direction. However "something more like X" for
    > various values of X does not achieve this, especially when there are people
    > able to identify ways in which the current system could be viewed as better
    > than X.


    Try, building the latest devel/qt4 meta-port, the process involves
    RE-extracting and RE-compiling the same upstream source/dist file 35
    times to meet the following dependencies:

    qt4-accessible-4.3.4_1
    qt4-assistant-4.3.4_1
    qt4-codecs-cn-4.3.4
    qt4-codecs-jp-4.3.4
    qt4-codecs-kr-4.3.4
    qt4-codecs-tw-4.3.4
    qt4-corelib-4.3.4_1
    qt4-dbus-4.3.4_1
    qt4-designer-4.3.4_1
    qt4-doc-4.3.4
    qt4-gui-4.3.4_2
    qt4-iconengines-4.3.4_1
    qt4-imageformats-4.3.4_1
    qt4-inputmethods-4.3.4_1
    qt4-libQtAssistantClient-4.3.4_1
    qt4-linguist-4.3.4_1
    qt4-makeqpf-4.3.4_1
    qt4-moc-4.3.4
    qt4-network-4.3.4_1
    qt4-opengl-4.3.4_2
    qt4-pixeltool-4.3.4_1
    qt4-porting-4.3.4
    qt4-qdbusviewer-4.3.4_1
    qt4-qmake-4.3.4
    qt4-qt3support-4.3.4_2
    qt4-qtconfig-4.3.4_1
    qt4-qtestlib-4.3.4_1
    qt4-qvfb-4.3.4_1
    qt4-rcc-4.3.4
    qt4-script-4.3.4_1
    qt4-sql-4.3.4_1
    qt4-svg-4.3.4_1
    qt4-uic3-4.3.4_2
    qt4-uic-4.3.4
    qt4-xml-4.3.4_1

    in addition to some other ports and, or packages, which have knowingly
    been left as an exercise for you.

    I think, this is not the only example to make you and, or other such
    fans, coolers, acs' and what not, unhappy, for present FreeBSD ports
    and, or package build system.

    I don't think, source based systems like FreeBSD and, or Gentoo are
    gaining any popularity over binary distributions, despite a lot of
    community marketing hype and, or advocacy; which again is merely a
    wastage of man-hours and effort.

    All those who, either don't want to invest their time on creative things
    or are not interested in analyzing, discovering and, or accepting any
    flaws in the current FreeBSD ports and, or package build system, are
    nothing, but exclusively trolls.

    --
    Dr Balwinder S "bsd" Dheeman Registered Linux User: #229709
    Anu'z Linux@HOME (Unix Shoppe) Machines: #168573, 170593, 25 9192
    Chandigarh, UT, 160062, India Gentoo, Fedora, Debian/FreeBSD/XP
    Home: http://cto.homelinux.net/~bsd/ Visit: http://counter.li.org/

  8. Re: gettext/GPLv4 virus infects FreeBSD

    Michel Talon wrote:
    >> All we need is a more qualified and experienced engineering team to
    >> manage the ports tree. Preferably individuals with A) formal systems
    >> administration training, B) formal software engineering and release
    >> management training, and C) real-world experience. It does not appear
    >> that the current team has any of these qualifications :-(

    >
    >First this is extremely obnoxious against people who do that on their
    >free time.


    Facts are facts, if sometimes obnoxious. Better to spell out where
    the damage has been done and why, than to pretend that everything's
    hunky dory (while a good OS loses a large chunk of market share to its
    better run competitors). If this were a qualified team _someone_ would
    have noticed that there was no need to bump the version of hundreds of
    ports. If this is not a qualified team then we should be taking steps
    to solicit one. If this is a faulty process then that should be fixed.
    The only thing that won't accomplish anything is to pretend it is not
    a serious problem.

    The question we should be asking is who is on the team, how did they
    validate the faulty decision, were they following any guidelines, and how
    in the hell could none of them bother to perform even a cursory validation
    as to whether this extensive mid-release update in any way necessary?

    > And second, how do you propose to pay these professional,
    >competent people who supposedly will manage the ports tree in a more
    >efficient way? Hint: the Debian team is around 1000 people, and the
    >FreeBSD ports team perhaps around 200 people. Good luck to find the $$$
    >able to support a professionnal team of that size.


    Are you saying that 200 people signed off on this mistake? If that is in
    fact the case then I'll have to agree with Dominic Fandrey that this is
    "Even worse than I assumed."

    Paco

  9. Re: gettext/GPLv4 virus infects FreeBSD

    Paco wrote:
    >
    > > And second, how do you propose to pay these professional,
    > >competent people who supposedly will manage the ports tree in a more
    > >efficient way? Hint: the Debian team is around 1000 people, and the
    > >FreeBSD ports team perhaps around 200 people. Good luck to find the $$$
    > >able to support a professionnal team of that size.

    >
    > Are you saying that 200 people signed off on this mistake? If that is in
    > fact the case then I'll have to agree with Dominic Fandrey that this is
    > "Even worse than I assumed."
    >
    > Paco


    Each time gettext is updated, the same problem occurs. So people are
    very well aware of this scenario. Then, gettext is bumped between releases
    because it is the best time to do that, and stabilize things for next
    release. So, who is the main cause of trouble here? perhaps yourself for
    updating your ports between releases, and doing that from source. There
    are releases and binary packages for a good reason. Wise people do clean
    installs using a RELEASE and then use the principle: "if it ain't broke,
    ain't fix it". Cowboys who run portupgrade -a each day in the vain hope
    of being always at the forefront of progress have only themselves to
    criticize when things go astray.


    --

    Michel TALON


  10. Re: gettext/GPLv4 virus infects FreeBSD

    Paco wrote:
    > Michel Talon wrote:


    [are we still whining about the gettext bump - *sigh*]

    > The question we should be asking is who is on the team, how did they
    > validate the faulty decision, were they following any guidelines, and how in
    > the hell could none of them bother to perform even a cursory validation as
    > to whether this extensive mid-release update in any way necessary?


    These are very simple questions to answer: the FreeBSD ports committers are
    the team. They are ports committers by virtue of having spent way too much
    time cooking up patches and making things work. The 'cursory validation' of
    which you speak is in the form of days worth of building on the cluster.

    I don't understand where the "mid-release" comes from. Please remember that
    the FreeBSD ports tree is not branched. It is tagged when a FreeBSD release
    happens, but other than that, the ports tree is entirely separate from the
    FreeBSD release process.

    This is a feature, not a bug.

    > > And second, how do you propose to pay these professional, competent people
    > > who supposedly will manage the ports tree in a more efficient way? Hint:
    > > the Debian team is around 1000 people, and the FreeBSD ports team perhaps
    > > around 200 people. Good luck to find the $$$ able to support a
    > > professionnal team of that size.

    >
    > Are you saying that 200 people signed off on this mistake? If that is in
    > fact the case then I'll have to agree with Dominic Fandrey that this is
    > "Even worse than I assumed."


    No. Someone who has shown himself to be competent enough to be given a ports
    commit bit (and who has done significant amounts of work) decided to do the
    work, validate it and commit it.

    It works, so no one complains.

    The FreeBSD Project is not in the business of assigning blame, it is in the
    business of producing an excellent operating system and maintaining a ports
    tree.

    The committers are committers because they have been found competent and
    trustworthy by other committers. If you are not happy with the way the system
    works, the way do change it is to submit patches and to discuss works in
    progress on the mailing lists with other developers. Flailing madly on Usenet
    is not the way to go about it.

    - Philip

    --
    Philip Paeps Please don't email any replies
    philip@paeps.cx I follow the newsgroup.

    "Any questions? Comments?"
    "I'm really impressed with the way you've managed to make Powerpoint look
    like your crappy old troff."
    -- Peter Linington and Ian Utting

  11. Re: gettext/GPLv4 virus infects FreeBSD

    On Wed, 25 Jun 2008 04:34:11 +0530
    Balwinder S Dheeman wrote:

    > On 06/24/2008 07:59 PM, Steve O'Hara-Smith wrote:
    > > A clear analysis of the perceived problems would be a great
    > > contribution. Personally I'm not unhappy with ports or pkgsrc so I'm not
    > > about to produce that analysis. If that analysis were followed by an
    > > outline design that provides the benefits of the current system and
    > > avoids the problems highlighted in the analysis then that would be even
    > > better and could provide a clear direction. However "something more
    > > like X" for various values of X does not achieve this, especially when
    > > there are people able to identify ways in which the current system
    > > could be viewed as better than X.

    >
    > Try, building the latest devel/qt4 meta-port, the process involves
    > RE-extracting and RE-compiling the same upstream source/dist file 35
    > times to meet the following dependencies:


    Yep that looks like a problem but - does it really compile all of
    the code for each dependency or does it just compile that part of the code
    involved in the package being installed each time round ? I rather think
    the latter, to the extent that the former occurs it could reasonably be
    considered a bug in the build phase of those ports which build too much.

    Clearly the benefit of this approach is that packages which only
    depend on a few of these only need to have those few installed. Equally
    clearly the downside is that there is excessive unpacking done when all or
    even many are wanted to be built.

    Assuming that the benefit is desirable how would you avoid the
    downside ? One interesting possibility would be to spot the use of the same
    distfiles in multiple packages, do the unpack in a separate work area and
    then mount it into the work area of each port using an inverted union mount.

    Another solution would be to split up the distfile - but since
    that's an upstream item this solution is probably not feasible.

    --
    C:>WIN | Directable Mirror Arrays
    The computer obeys and wins. | A better way to focus the sun
    You lose and Bill collects. | licences available see
    | http://www.sohara.org/

  12. Re: gettext/GPLv4 virus infects FreeBSD

    Philip Paeps wrote:
    >These are very simple questions to answer: the FreeBSD ports commtters are
    >the team.


    Sorry, but you are wrong. Please go back and review the threads in
    freebsd-ports@ and elsewhere. Ports committers did not bump the version
    numbers of their own ports, it was forced on them by the maintainer/s.

    >I don't understand where the "mid-release" comes from. Please remember that
    >the FreeBSD ports tree is not branched.


    That is a policy failure. Any non-essential ports change that would cause
    this level of pain, or otherwise potentially effect more applications
    than a base release bump, should be scheduled at the same time as the next
    (minor at least) standard/base update, just like every other OS.

    But then we're not even talking about a necessary version bump, we are
    talking about a _mistake_. There was no actual dependency to gettext that
    would have necessitated a version bump.

    Paco

  13. Re: gettext/GPLv4 virus infects FreeBSD

    In article <4862a9ce$0$17227$742ec2ed@news.sonic.net>,
    Paco writes:
    > Philip Paeps wrote:
    >>These are very simple questions to answer: the FreeBSD ports commtters are
    >>the team.

    >
    > Sorry, but you are wrong. Please go back and review the threads in
    > freebsd-ports@ and elsewhere. Ports committers did not bump the version
    > numbers of their own ports, it was forced on them by the maintainer/s.
    >
    >>I don't understand where the "mid-release" comes from. Please remember that
    >>the FreeBSD ports tree is not branched.

    >
    > That is a policy failure. Any non-essential ports change that would cause
    > this level of pain, or otherwise potentially effect more applications
    > than a base release bump, should be scheduled at the same time as the next
    > (minor at least) standard/base update, just like every other OS.
    >
    > But then we're not even talking about a necessary version bump, we are
    > talking about a _mistake_. There was no actual dependency to gettext that
    > would have necessitated a version bump.
    >
    > Paco


    Couple of observations:

    (1) The ports team is comprised of volunteers, as is the system
    team. Instead of pissing and moaning about what a lousy job they
    do, you should be grateful for what they have done - without their
    efforts you'd be a helluva lot worse off than at present. You'd
    have to track each of the apps you have installed, their dependencies
    and requirements, fetch the raw code from the source code foundry,
    modify the source, create patches, and all the rest that's now
    done for you by those miserable sons-of-bitches who aren't doing
    things exactly the way you expect it to be done. (I might add
    that I don't like the way some things are done, either, to
    include the recent gettext fiasco.)

    (2) If the system is so damn bad, DO something and quitcherbitching.
    Become a committer, work from within the make the system better.
    Hell, who knows, you might even make THE contribution that'll change
    things forevermore.

    (3) The ports system DOES need improvement, no argument. I know
    enough to know I don't have an answer for the problem. That said,
    I do think a first step would be to clean out the ports tree, and
    to re-examine the various dependencies (if A requires B and B
    requires C, is it _really_ necessary to say that A requires C?) Do
    away with multiple versions of libraries and support software. Only
    after that's done will anybody have a fighting chance to repair,
    replace or modify the system.

    --
    Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
    -----
    Thinking is the hardest work there is, which is the probable
    reason so few engage in it. -- Henry Ford


  14. Re: gettext/GPLv4 virus infects FreeBSD

    On 06/25/2008 10:28 PM, Steve O'Hara-Smith wrote:
    > On Wed, 25 Jun 2008 04:34:11 +0530
    > Balwinder S Dheeman wrote:
    >
    >> On 06/24/2008 07:59 PM, Steve O'Hara-Smith wrote:
    >>> A clear analysis of the perceived problems would be a great
    >>> contribution. Personally I'm not unhappy with ports or pkgsrc so I'm not
    >>> about to produce that analysis. If that analysis were followed by an
    >>> outline design that provides the benefits of the current system and
    >>> avoids the problems highlighted in the analysis then that would be even
    >>> better and could provide a clear direction. However "something more
    >>> like X" for various values of X does not achieve this, especially when
    >>> there are people able to identify ways in which the current system
    >>> could be viewed as better than X.

    >> Try, building the latest devel/qt4 meta-port, the process involves
    >> RE-extracting and RE-compiling the same upstream source/dist file 35
    >> times to meet the following dependencies:

    >
    > Yep that looks like a problem but - does it really compile all of
    > the code for each dependency or does it just compile that part of the code
    > involved in the package being installed each time round ? I rather think
    > the latter, to the extent that the former occurs it could reasonably be
    > considered a bug in the build phase of those ports which build too much.
    >
    > Clearly the benefit of this approach is that packages which only
    > depend on a few of these only need to have those few installed. Equally
    > clearly the downside is that there is excessive unpacking done when all or
    > even many are wanted to be built.
    >
    > Assuming that the benefit is desirable how would you avoid the
    > downside ? One interesting possibility would be to spot the use of the same
    > distfiles in multiple packages, do the unpack in a separate work area and
    > then mount it into the work area of each port using an inverted union mount.
    >
    > Another solution would be to split up the distfile - but since
    > that's an upstream item this solution is probably not feasible.


    IMHO, yes, opinion, because I have not tested any of the following as yet:

    1. Use same ${WRKSRC} or symlink to it and avoid extraction, force make
    clean before the build.

    2. In addition to above, use a ${DESTDIR}, which most of the upstream
    projects follow and RE-engineer the pkg_create(1), needs more analysis
    and, or may be a reinvention of the wheel and possibly some heavy rework
    on auditing of pkg-plist(s), but the same can be automated.

    3. Study and analyze, how the ArchLinux, Gentoo and, or Debian build
    systems sub-divide packages build from a single source. IMHO, the Debian
    has quite a good one and policy driven build system.

    4. If we really hate and, or find other such system not suitable for
    adaption, re-invent our own efficient frame work from up like 'git'.

    --
    Dr Balwinder S "bsd" Dheeman Registered Linux User: #229709
    Anu'z Linux@HOME (Unix Shoppe) Machines: #168573, 170593, 259192
    Chandigarh, UT, 160062, India Gentoo, Fedora, Debian/FreeBSD/XP
    Home: http://cto.homelinux.net/~bsd/ Visit: http://counter.li.org/

  15. Re: gettext/GPLv4 virus infects FreeBSD

    On Thu, 26 Jun 2008 14:48:55 +0530
    Balwinder S Dheeman wrote:

    > On 06/25/2008 10:28 PM, Steve O'Hara-Smith wrote:
    > > On Wed, 25 Jun 2008 04:34:11 +0530
    > > Balwinder S Dheeman wrote:
    > >
    > >> On 06/24/2008 07:59 PM, Steve O'Hara-Smith wrote:
    > >>> A clear analysis of the perceived problems would be a great
    > >>> contribution. Personally I'm not unhappy with ports or pkgsrc so I'm
    > >>> not about to produce that analysis. If that analysis were followed by
    > >>> an outline design that provides the benefits of the current system and
    > >>> avoids the problems highlighted in the analysis then that would be
    > >>> even better and could provide a clear direction. However "something
    > >>> more like X" for various values of X does not achieve this,
    > >>> especially when there are people able to identify ways in which the
    > >>> current system could be viewed as better than X.
    > >> Try, building the latest devel/qt4 meta-port, the process involves
    > >> RE-extracting and RE-compiling the same upstream source/dist file 35
    > >> times to meet the following dependencies:

    > >
    > > Yep that looks like a problem but - does it really compile all
    > > of the code for each dependency or does it just compile that part of
    > > the code involved in the package being installed each time round ? I
    > > rather think the latter, to the extent that the former occurs it could
    > > reasonably be considered a bug in the build phase of those ports which
    > > build too much.
    > >
    > > Clearly the benefit of this approach is that packages which only
    > > depend on a few of these only need to have those few installed. Equally
    > > clearly the downside is that there is excessive unpacking done when all
    > > or even many are wanted to be built.
    > >
    > > Assuming that the benefit is desirable how would you avoid the
    > > downside ? One interesting possibility would be to spot the use of the
    > > same distfiles in multiple packages, do the unpack in a separate work
    > > area and then mount it into the work area of each port using an
    > > inverted union mount.
    > >
    > > Another solution would be to split up the distfile - but since
    > > that's an upstream item this solution is probably not feasible.

    >
    > IMHO, yes, opinion, because I have not tested any of the following as yet:
    >
    > 1. Use same ${WRKSRC} or symlink to it and avoid extraction, force make
    > clean before the build.
    >
    > 2. In addition to above, use a ${DESTDIR}, which most of the upstream
    > projects follow and RE-engineer the pkg_create(1), needs more analysis
    > and, or may be a reinvention of the wheel and possibly some heavy rework
    > on auditing of pkg-plist(s), but the same can be automated.
    >
    > 3. Study and analyze, how the ArchLinux, Gentoo and, or Debian build
    > systems sub-divide packages build from a single source. IMHO, the Debian
    > has quite a good one and policy driven build system.
    >
    > 4. If we really hate and, or find other such system not suitable for
    > adaption, re-invent our own efficient frame work from up like 'git'.


    At this point I would suggest you write up an analysis and an
    outline design for a solution and post it on ports@ for further discussion
    and possibly implementation.

    --
    C:>WIN | Directable Mirror Arrays
    The computer obeys and wins. | A better way to focus the sun
    You lose and Bill collects. | licences available see
    | http://www.sohara.org/

  16. Re: gettext/GPLv4 virus infects FreeBSD

    Paco wrote:
    > Philip Paeps wrote:
    > >These are very simple questions to answer: the FreeBSD ports commtters are
    > >the team.

    >
    > Sorry, but you are wrong. Please go back and review the threads in
    > freebsd-ports@ and elsewhere. Ports committers did not bump the version
    > numbers of their own ports, it was forced on them by the maintainer/s.


    The maintainer is a committer. The maintainer is a member of the team. As
    part of his update to gettext, he bumped the dependent ports as a matter of
    convenience.

    > > I don't understand where the "mid-release" comes from. Please remember
    > > that the FreeBSD ports tree is not branched.

    >
    > That is a policy failure.


    No. It is a feature. If you don't like this feature, you can simply not
    update your ports tree.

    > Any non-essential ports change that would cause this level of pain, or
    > otherwise potentially effect more applications than a base release bump,
    > should be scheduled at the same time as the next (minor at least)
    > standard/base update, just like every other OS.


    The bumping of versions is for preventing pain, not for causing it. Bumping
    the versions of dependent ports marks them for recompilation so they do not
    depend on old libraries.

    > But then we're not even talking about a necessary version bump, we are
    > talking about a _mistake_. There was no actual dependency to gettext that
    > would have necessitated a version bump.


    Have you asked the maintainer about this? I would assume that the maintainer
    of gettext knows best about what has and what hasn't changed and how this
    affects or does not affect dependent ports.

    Every major upgrade of gettext I am aware of has necessitated a bump for
    various reasons, usually very obvious ones like a shlib bump but not
    necessarily.

    In any case, the maintainer is not reading along here, I think.

    - Philip

    --
    Philip Paeps Please don't email any replies
    philip@paeps.cx I follow the newsgroup.

    BOFH Excuse #212:
    Of course it doesn't work. We've performed a software upgrade.

  17. Re: gettext/GPLv4 virus infects FreeBSD

    Philip Paeps wrote:
    >> > I don't understand where the "mid-release" comes from. Please remember
    >> > that the FreeBSD ports tree is not branched.

    >> That is a policy failure.

    >
    >No. It is a feature. If you don't like this feature, you can simply not
    >update your ports tree.


    I couldn't have said it better if, well, if I was a RedHat plant being
    paid to obfuscate criticism of serious flaws in a competing OS.

    Paco

  18. Re: gettext/GPLv4 virus infects FreeBSD

    Begin <48658f80$0$17178$742ec2ed@news.sonic.net>
    On 28 Jun 2008 01:10:24 GMT, Paco wrote:
    > Philip Paeps wrote:
    >>> > I don't understand where the "mid-release" comes from. Please
    >>> > remember that the FreeBSD ports tree is not branched.
    >>> That is a policy failure.

    >>No. It is a feature. If you don't like this feature, you can simply
    >>not update your ports tree.

    >
    > I couldn't have said it better if, well, if I was a RedHat plant being
    > paid to obfuscate criticism of serious flaws in a competing OS.


    This sort of thing is why I stopped bothering to respond to you, or
    in most cases, read your blatherings. We can do without the trolling.

    Despite what a few vocal and often equally undiscerning dissenters
    elsethread may have you believe, the ports system is still functioning
    pretty closely to its design criteria. Though you really don't seem to
    need them, as you came here with an axe to grind, and not to discuss.

    If you really do know it all so much better, then start your own ports
    replacement for FreeBSD and show us. Finding people who'll help you
    with it is permitted, of course. I think you can recruit one or two
    loudmouths right here. Come back when you're done. Feel free to gloat.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  19. Re: gettext/GPLv4 virus infects FreeBSD

    jpd writes:

    >Then you need to systematize and automatize your systems management.
    >There are various approaches, depending on your needs. For one example
    >you could look at how eg. dutch isp xs4all does this (on FreeBSD).


    URLs, please? Or at least what to google for?
    --
    The first entry of Sin into the mind occurs when, out of cowardice or
    conformity or vanity, the Real is replaced by a comforting lie.
    -- Integritas, Consonantia, Claritas

  20. Re: gettext/GPLv4 virus infects FreeBSD

    jpd wrote:
    >>>> > I don't understand where the "mid-release" comes from. Please
    >>>> > remember that the FreeBSD ports tree is not branched.
    >>>> That is a policy failure.
    >>>No. It is a feature. If you don't like this feature, you can simply
    >>>not update your ports tree.

    >>
    >> I couldn't have said it better if, well, if I was a RedHat plant being
    >> paid to obfuscate criticism of serious flaws in a competing OS.

    >
    >This sort of thing is why I stopped bothering to respond to you, or
    >in most cases, read your blatherings. We can do without the trolling.


    You might find it easier jpd, by cutting down the time spent calling
    those you disagree with trolls. In this thread alone name calling
    accounts for over 50% of your contribution.

    If you really do think the fact that FreeBSD ports maintainers are
    volunteers somehow makes them off-limits for to criticism, no matter how
    extensive the damage caused by their mistakes (from lack of understanding
    of release management, lack of training, inexperience, or whatever)
    then I'd guess that you don't have any children. If you did you would
    know that both carrots and sticks are required, and expected, to properly
    guide newbies.

    >If you really do know it all so much better, then start your own ports
    >replacement for FreeBSD and show us. Finding people who'll help you
    >with it is permitted, of course. I think you can recruit one or two
    >loudmouths right here. Come back when you're done. Feel free to gloat.


    What exactly you expect to accomplish by such name calling?

    Paco

+ Reply to Thread
Page 4 of 5 FirstFirst ... 2 3 4 5 LastLast