gettext/GPLv4 virus infects FreeBSD
Paco
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?
"blow away all existing install ports"
"rebuilding from scratch"
Clearly someone with a profound lack of systems administration experience
committed this change, but how the hell did it get through QA? Is there
no one running this ship any more?
So, with 100+ ports needing to be upgraded before versioning once
again works, I expect to have a hard time convincing my boss that there
are good reasons for not "blowing away FreeBSD and installing Linus".
Question is, what's so critical about this new gettext that might be worth
the effort. What is the gain in functionality? What is the gain
in security? That's the crux, there is nothing in gettext that needs
to be patched. No security improvement, no compatibility improvements,
no improvements whatsoever. Just some package maintainer who thinks that
systems administrators have nothing better to do than perform upgrades
in-between release cycles.
Actually, truth be known, there likely is a lot more to it than poor QA and
inexperienced port maintainers. What's behind this is the GPL, GPLv4
specifically, and GNU's hatred of BSD licensing. To the point: gettext's
license recently changed from v2 to v3. What this means is that if you
have a commercial app that links to gettext in any way, you can be sued.
Stallman couldn't have planted a better virus in the heart of FreeBSD
if he had planned it. This kind of gratuitous library skew is exactly
what FreeBSD's source-based package system was designed to avoid.
So before I'm forced give up the FreeBSD dream:
A) how do you "unbump" these port versions,
B) how can we get a GPLV3_FREE=YES flag in make.conf, and
C) what happened to this once sold OS?
Paco
Philip Paeps
> 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?
This is the case every time gettext updates. It's nothing new. The problem
is so many things pulling in gettext. An even more real problem is things
pulling in gettext surreptitiously just because it's on the system. I ranted
about this on my blog:
http://www.paeps.cx/weblog/FreeBSD/the_userfriendly_police.html
Repeat after me: the problem is not in the ports tree. The problem is
gettext. The real problem is autotools.
In fact, the ports tree deals with it rather elegantly - offering you to
update very cleanly. You can also keep the old libintl.so.7 somewhere like
/usr/local/lib/compat/pkg and update things at your leisure. You don't *have*
to blast away everything if you don't want to. If you can live with some
things running with libintl.so.7 and some with libintl.so.8, you can use that
approach.
> So, with 100+ ports needing to be upgraded before versioning once again
> works, I expect to have a hard time convincing my boss that there are good
> reasons for not "blowing away FreeBSD and installing Linus".
I can't quite see the connection? I guess this is just flamebait?
> Question is, what's so critical about this new gettext that might be worth
> the effort. What is the gain in functionality? What is the gain in
> security?
You would have to ask the gettext developers these questions. The FreeBSD
ports tree merely tracks the upstream version. That's what the ports tree is
for. As far as I'm concerned, gettext is perfectly useless. I like my
computers to speak English to me. Unfortunately, some ports will pull it in
unconditionally because the software they port just doesn't work without.
> Actually, truth be known, there likely is a lot more to it than poor QA and
> inexperienced port maintainers.
Have you looked at who maintains this port? Have you asked on the -ports@
list if an -exp run has been done before this was committed? The commit
touches a ridiculous amount of ports. Do you think that was allowed to go in
before it was at least tested and validated on the cluster?
> What's behind this is the GPL, GPLv4 specifically, and GNU's hatred of BSD
> licensing. To the point: gettext's license recently changed from v2 to v3.
> What this means is that if you have a commercial app that links to gettext
> in any way, you can be sued.
I think you're seeing black helicopters. The ports tree allows you to build
software. It is your responsibility to make sure that you are allowed to run
this software and that you agree with the licences of the software you use.
The FreeBSD operating system -- that is the kernel and the supporting userland
bits like libc and the stuff in /bin and /sbin (and most of the stuff in
/usr/bin and /usr/sbin) -- is BSD-licensed. There are ways to infect the
kernel with non-free GPL code too, should you so choose. By default, this
does not happen though. You can infect your kernel with the non-free CDDL
licence too, if you want to use some of the CDDL-licensed bits. Again, by
default this is not done.
What you build from the ports tree is entirely your business and your own
responsibility.
> So before I'm forced give up the FreeBSD dream:
>
> A) how do you "unbump" these port versions,
You use a version of the ports tree before the date this was committed.
> B) how can we get a GPLV3_FREE=YES flag in make.conf, and
You cannot. But I'm sure patches to that effect will be welcomed for review
and perhaps even committing. Note, again, that the base-system does not
currently contain any GPLv3-infected software. There is some GPLv2-infected
software (toolchain), which you can choose not to build by setting a
WITHOUT_GNU= flag in make.conf. This flag is mainly intended for distributors
of FreeBSD who will only supply their customers with binaries.
> C) what happened to this once sold OS?
I don't think anything happened. I think you just jumped to a completely
wrong conclusion and accidentally equated the contents of the FreeBSD ports
tree to the rock-solid FreeBSD operating system. Such things happen. Try to
be more careful though.
- Philip
--
Philip Paeps Please don't email any replies
phi...@paeps.cx I follow the newsgroup.
The primary function of the design engineer is to make
things difficult for the fabricator and impossible
for the serviceman.
Anton Hartl
> Paco <spamfr...@sonic.net> wrote:
[...]
>> What's behind this is the GPL, GPLv4 specifically, and GNU's hatred of BSD
>> licensing. To the point: gettext's license recently changed from v2 to v3.
>> What this means is that if you have a commercial app that links to gettext
>> in any way, you can be sued.
>
> I think you're seeing black helicopters. The ports tree allows you to build
> software. It is your responsibility to make sure that you are allowed to run
> this software and that you agree with the licences of the software you use.
Furthermore it's simply a half-truth; from the ChangeLog:
The gettext related programs and tools are now licensed under the GPL
version 3, instead of the GPL version 2. The libintl library continues
to be licensed under LGPL.
>
> - Philip
>
-Anton
Patrick Lamaizière
Philip Paeps <philip...@paeps.cx> a écrit :
> Paco <spamfr...@sonic.net> 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?
>
> This is the case every time gettext updates. It's nothing new. The
> problem is so many things pulling in gettext. An even more real
> problem is things pulling in gettext surreptitiously just because
> it's on the system. I ranted about this on my blog:
Yes, I remember funny upgrade of libtool or perl too.
Martin Etteldorf
> Le 9 Jun 2008 20:36:43 GMT,
> Philip Paeps <philip...@paeps.cx> a écrit :
>
>> problem is so many things pulling in gettext. An even more real
>> problem is things pulling in gettext surreptitiously just because
>> it's on the system. I ranted about this on my blog:
>
> Yes, I remember funny upgrade of libtool or perl too.
You're sure about the libtool part?
Martin
--
"For the Snark's a peculiar creature, that won't
Be caught in a commonplace way.
Do all that you know, and try all that you don't;
Not a chance must be wasted to-day!"
Christian Weisgerber
> To the point: gettext's license recently changed from v2 to v3.
> What this means is that if you have a commercial app that links to
> gettext in any way, you can be sued.
Nonsense. libintl remains under the LGPL. Only the message catalog
processing tools are GPLv3.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Patrick Lamaizière
Martin Etteldorf <ette...@email.lu> a écrit :
> >> This is the case every time gettext updates. It's nothing new.
> >> The problem is so many things pulling in gettext. An even more
> >> real problem is things pulling in gettext surreptitiously just
> >> because it's on the system. I ranted about this on my blog:
> >
> > Yes, I remember funny upgrade of libtool or perl too.
>
> You're sure about the libtool part?
Sure. I spent days to update all my boxes :)
ports/UPDATING
20060223:
AFFECTS: all ports using libtool as part of the build process
And few days before an upgrade of perl 5.8.7(?) to 5.8.8
20060220:
AFFECTS: users of lang/perl5.8
Martin Etteldorf
> Le Tue, 10 Jun 2008 17:16:52 +0000 (UTC),
> Martin Etteldorf <ette...@email.lu> a écrit :
>
>> >> This is the case every time gettext updates. It's nothing new.
>> >> The problem is so many things pulling in gettext. An even more
>> >> real problem is things pulling in gettext surreptitiously just
>> >> because it's on the system. I ranted about this on my blog:
>> >
>> > Yes, I remember funny upgrade of libtool or perl too.
>>
>> You're sure about the libtool part?
>
> Sure. I spent days to update all my boxes :)
Days? Here it was merely a matter of 1 or 2 hours and I didn't
notice any bigger problems during that upgrade. But then again,
that may be because I'm avoiding Pest and Cholera^W^W^W KDE and
Gnome at any cost. Helps a lot keeping the number of installed
ports down at a reasonable size.
Torfinn Ingolfsen
>
> C) what happened to this once sold OS?
The os is still solid (I guessed you meant "solid" - yes?)
The ports tree is separate from the os -it is not an integral part of
the os.
The only constant is change.
--
Torfinn Ingolfsen,
Norway
Robert Melson
Martin Etteldorf <ette...@email.lu> writes:
> Patrick Lamaizičre <patn...@davenulle.org> wrote:
>> Le Tue, 10 Jun 2008 17:16:52 +0000 (UTC),
>> Martin Etteldorf <ette...@email.lu> a écrit :
>>
>>> >> This is the case every time gettext updates. It's nothing new.
>>> >> The problem is so many things pulling in gettext. An even more
>>> >> real problem is things pulling in gettext surreptitiously just
>>> >> because it's on the system. I ranted about this on my blog:
>>> >
>>> > Yes, I remember funny upgrade of libtool or perl too.
>>>
>>> You're sure about the libtool part?
>>
>> Sure. I spent days to update all my boxes :)
>
> Days? Here it was merely a matter of 1 or 2 hours and I didn't
> notice any bigger problems during that upgrade. But then again,
> that may be because I'm avoiding Pest and Cholera^W^W^W KDE and
> Gnome at any cost. Helps a lot keeping the number of installed
> ports down at a reasonable size.
>
>
> Martin
>
Days. Yeah, I know, it's a function of what you have installed.
I have chosen to use my system as a workstation, which drags in
a lot of stuff not found on a system used strictly as a server.
However, without adding any new applications, my "inventory"
has gone from ~500 discrete ports/packages to > 1000 in less
than a year. Part of that is the new granularity in, e.g.
php and its modules, but a large part of it is what seems to me
to be a kind of shotgun approach to packaging, where something
that's not explicitly needed is included "just in case".
So, yeah, days. Not hours, but days to upgrade the ports on my
system.
Bob Melson
--
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
Lars Eighner
and talented Paco broadcast on comp.unix.bsd.freebsd.misc:
> Ran cvsup today and was blown away be the number of ports needing to be
> upgraded, over 100!
No doubt when the gettext upgrade finishes there will be another Gnome
Upgrade Adventure! Nothing really quite compares with the X upgrade
unleashed about 5 mins. after some 6.x release, so everyone's release discs
were coasters.
--
Lars Eighner <http://larseighner.com/> use...@larseighner.com
Countdown: 223 days to go.
Ted Nolan <tednolan>
Lars Eighner <use...@larseighner.com> wrote:
>
>
>In our last episode, <484d8873$0$17176$742e...@news.sonic.net>, the lovely
>and talented Paco broadcast on comp.unix.bsd.freebsd.misc:
>
>> Ran cvsup today and was blown away be the number of ports needing to be
>> upgraded, over 100!
>
>No doubt when the gettext upgrade finishes there will be another Gnome
>Upgrade Adventure! Nothing really quite compares with the X upgrade
>unleashed about 5 mins. after some 6.x release, so everyone's release discs
>were coasters.
>
I guess I'm not typical, but I just keep the ports tree that comes with
the release ISOs, and everything generally works fine. Yes, I won't
have the very latest 'foo' if I decide to install 'foo', but in general,
who cares?
(Though I *was* astounded when I tried to install gnome on Solaris
8 once [before it came from Sun], and found that I had to compile
and install every open-source program ever written to have a shot
at it. IIRC, it took me over two weeks).
Ted
--
------
columbiaclosings.com
What's not in Columbia anymore..
Thierry Thomas
> So, yeah, days. Not hours, but days to upgrade the ports on my
> system.
In these cases, just wait some days, and then use the packages built on
the compilation farm; just upgrade from ports when you have some
customized options.
--
Th. Thomas.
Robert Melson
Believe it or not, I prefer the ability to "roll my own". It's
not entirely rational, I know, but there it is, despite my
griping about the increase in "inventory" and the time needed
to do an upgrade. Other side of the coin is, of course, that
such upgrade everything events don't happen all that often,
although their frequency HAS increased over the course of the
past couple of years.
In my case, I have a single machine and plenty of time to invest.
But it sounds to me like the OP is in a production environment
with a number of machines involved. I can understand and mostly
sympathize with his complaint, even while recognizing that there
are mechanisms, such as what you suggest, that will reduce the
pain. But if management will not accept either the delay
involved or precompiled packages, then he has no real alternative
and is, I think, justified in his anger and frustration.
There really does have to be a better way. I don't know what
it might be or how to arrive at it, but I think the ports/packages
system has become unwieldy and is close to collapse.
Ted Mittelstaedt
"Robert Melson" <mel...@aragorn.rgmhome.net> wrote in message
news:8KKdnYw-FN9269LV...@earthlink.com...
> In article <slrng4uras....@graf.pompo.net>,
> Thierry Thomas <tth...@mail.dotcom.fr> writes:
> > On Tue, 10 Jun 2008 18:18:55 -0500, Robert Melson wrote:
> >
>
> In my case, I have a single machine and plenty of time to invest.
> But it sounds to me like the OP is in a production environment
> with a number of machines involved. I can understand and mostly
> sympathize with his complaint, even while recognizing that there
> are mechanisms, such as what you suggest, that will reduce the
> pain. But if management will not accept either the delay
> involved or precompiled packages, then he has no real alternative
> and is, I think, justified in his anger and frustration.
>
> There really does have to be a better way.
There IS a better way. I run plenty of FreeBSD in production.
No servers get software upgrades in between version updates.
Period. If a security notification comes out that affects a server
(ie: a new apache version) then I move the old binaries to backups
and compile the newer version by hand, not using the ports
tree.
Every couple of FreeBSD versions or couple of years, whenever
I feel like it, then I rebuild the server. From scratch, none of this
in-place upgrade bullcrap. Sometimes it puts some new feature
in that is useful. Usually not, though. And often I'll take the
opportunity to just scrap the server hardware and use newer
and faster hardware.
FreeBSD isn't Windows. When MS says jump, you upgrade
Windows. The FreeBSD project doesen't say jump.
Ted
jpd
Robert Melson <mel...@aragorn.rgmhome.net> wrote:
> But it sounds to me like the OP is in a production environment
> with a number of machines involved.
In that case it'll be somewhat more work as there are more, more-or-less
independent, package sets to re-build. But one still really should do
that on a single machine then distribute the package sets.
> I can understand and mostly sympathize with his complaint,
As do I to an extent, but as others have noted, the problem is pretty
much independent from the base system. That distinction is important.
Part of the problem is the horrible dependency trees of much open
source software, especially anything even remotely related to the gnu
project (and we've discussed this here before a number of times). This
is in part a problem of developers with not enough release engineering
experience, who are as a result often a bit too free with creating new
dependencies. (Even the mozilla project is interesting.cn WRT this.)
Though one could argue that the ports maintainers could be a bit more
careful about updates of things that touch a lot of other things, and
especially their timing. I think I'll agree with that.
> But if management will not accept either the delay
> involved or precompiled packages, then he has no real alternative
> and is, I think, justified in his anger and frustration.
Management will just have to cope. If they don't understand that,
they're not fit for management. As they say, adding more pregnant women
will not get you the kids faster[1]. Of course, management also needs
the minions to communicate this well upstream.
> There really does have to be a better way. I don't know what
> it might be or how to arrive at it, but I think the ports/packages
> system has become unwieldy and is close to collapse.
I think that, eg. the X explosion was at least in an attempt to help fix
this, if maybe so far not terribly effective. Ports works pretty well,
really, and it isn't the framework itself that is the problem.
Other distributions have much of the same problem, but are harder to
setup to do your own builds.
I think that I somewhat sympathise, if not with the OP's tone, but with
the sentiment that the FreeBSD project overall, base and ports both,
has coasted somewhat into a ``well it works for me'' mindset, which is
rather unhelpful if your setup is valid but somewhat different. I have
no numbers or proof except my own experiences[2] and what I see float by
here, but I think that this is something the project needs to work on.
[1] Also ``adding more people to a late project makes it later''.
See also Fred Brooks' excellent explanation of why this is so in
_The Mythical Man-Month_.
[2] The fbsd7 ata trouble with my ultra5 was passed off to elsewhere
and nothing more was heard about it. I might try again with 7.1,
but I'm not optimistic.
--
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.
Marco van de Voort
>>> This is the case every time gettext updates. It's nothing new. The
>>> problem is so many things pulling in gettext. An even more real
>>> problem is things pulling in gettext surreptitiously just because
>>> it's on the system. I ranted about this on my blog:
>>
>> Yes, I remember funny upgrade of libtool or perl too.
>
> You're sure about the libtool part?
Yes. Note that the big catch was not libtool, but changed naming of ports.
E.g. gtk12 changed into gtk-1.2
Martin Etteldorf
> Days. Yeah, I know, it's a function of what you have installed.
> I have chosen to use my system as a workstation,
I'm doing that as well, and -- believe it or not -- you can still
live fine without Gnome and KDE.
> However, without adding any new applications, my "inventory"
> has gone from ~500 discrete ports/packages to > 1000 in less
> than a year. Part of that is the new granularity in, e.g.
> php and its modules, but a large part of it is what seems to me
> to be a kind of shotgun approach to packaging, where something
> that's not explicitly needed is included "just in case".
Maybe some cleanup will help. e.g. I don't need no 3 versions of
libtool, automake/-conf/-whatever, neither do I need different
versions of gcc.
Sometimes it helps checking if you have installed ports with no
dependencies in either direction as well. Usually you can just
safely drop them.
Wilhelm B. Kloke
>
> Maybe some cleanup will help. e.g. I don't need no 3 versions of
> libtool, automake/-conf/-whatever, neither do I need different
> versions of gcc.
Neither do I, but as I need some fortran, I get them for love on FreeBSD.
--
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-373
PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key
J. Porter Clark
>Robert Melson <mel...@aragorn.rgmhome.net> wrote:
>> Days. Yeah, I know, it's a function of what you have installed.
>> I have chosen to use my system as a workstation,
>I'm doing that as well, and -- believe it or not -- you can still
>live fine without Gnome and KDE.
Yes, but can you live without cdrecord? 8-(
--
J. Porter Clark <j...@porterclark.com>
jpd
J. Porter Clark <j...@porterclark.com> wrote:
>
> Yes, but can you live without cdrecord? 8-(
Just before I was about to say `yes' I double-checked, and I seem to
have it installed on my system. Probably because I needed it for dvds,
but this box doesn't have a dvd burner installed, only a cd burner. For
that, burncd (from base) does just fine.
Can you live with a cdrecord without rscsi and cddb? I can, and mine has
exactly no dependencies according to pkg_info. It's probably why I added
atapicam to the kernel, though.
Michel Talon
An option which is considered as the devil's tentation by many FreeBSD
users, (note i have not said the penguin's way) and lacks proper tools
to be used comfortably ...
--
Michel TALON
Michel Talon
When i wrote my paper on the FreeBSD ports system, the constant mania of
changing the names of ports seemd to me to be the biggest gripe against
the system. At least this is the sort of thing which brings absolutely
nothing positive (except comforting the ego of some bikeshed painters)
and causes a lot of trouble for ports management.
--
Michel TALON
Joerg Schilling
>
>>Robert Melson <mel...@aragorn.rgmhome.net> wrote:
>
>>> Days. Yeah, I know, it's a function of what you have installed.
>>> I have chosen to use my system as a workstation,
>
>>I'm doing that as well, and -- believe it or not -- you can still
>>live fine without Gnome and KDE.
>
>Yes, but can you live without cdrecord? 8-(
Well, you are right never versions of cdrtools include libfind which
is by default compiled against gettext(3). I thought that GNU gettext(3)
if LGPL and did not care. I just checked gettext-0.17 which seems
to bee the latest and gettext(3) is still LGPLv2.
As cdrtools are now nearly completely under CDDL, a change from LGPL
to GPL for one of the external libraries would be a major problem.
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Martin Etteldorf
>
>>Robert Melson <mel...@aragorn.rgmhome.net> wrote:
>
>>> Days. Yeah, I know, it's a function of what you have installed.
>>> I have chosen to use my system as a workstation,
>
>>I'm doing that as well, and -- believe it or not -- you can still
>>live fine without Gnome and KDE.
>
> Yes, but can you live without cdrecord? 8-(
Yes. *For me*, burncd and dvd+rw-tools are sufficient.
BTW: cdrecord needs neither gettext nor iconv if you have set
WITHOUT_NLS=yes in your build environment. Setting this is a good
idea anyway if you don't need it, as it also helps a lot to avoid
installing unnecessary packages.
Paco
>Well, you are right never versions of cdrtools include libfind which
>is by default compiled against gettext(3). I thought that GNU gettext(3)
>if LGPL and did not care. I just checked gettext-0.17 which seems
>to bee the latest and gettext(3) is still LGPLv2.
Interesting. When I:
cd /usr/ports/devel/gettext
make
more work/gettext-0.17/NEWS
it clearly indicates:
* License:
The gettext related programs and tools are now licensed under the GPL
version 3, instead of the GPL version 2. The libintl library continues
to be licensed under LGPL.
So does this mean that any commercial, non-OSS application developer
who calls crdrtools from their app can now be sued, regardless of whether
they modify your code or not?
Paco
Paco
>Furthermore it's simply a half-truth; from the ChangeLog:
>
> The gettext related programs and tools are now licensed under the GPL
> version 3, instead of the GPL version 2. The libintl library continues
> to be licensed under LGPL.
How does libintl relate? If I use an app that links to gettext will it
call libintl instead, if gettext isn't installed?
Paco
Paco
>So, yeah, days. Not hours, but days to upgrade the ports on my
>system.
None of which does anything other than resynchronize your port version
numbers (assuming you didn't upgrade gettext in the first place).
That's negative ROI to the accountants and other suits, budget
down the drain for those of us paying the sysadmins, and a waste of
time to those doing the upgrades.
Not a good way to do release management, whether or not it is in
the base OS.
Paco
Paco
>As do I to an extent, but as others have noted, the problem is pretty
>much independent from the base system. That distinction is important.
Except that they're both essential components of FreeBSD and both play
a key role in differentiating FreeBSD from other Unix/Linux OS'.
Taking the laissez-faire approach to release management, as per Philip's
opinion that ports "merely tracks the upstream version", diminishes
FreeBSD's value against the competition. You can bet Ubuntu doesn't let
application version numbers skew like this. Note which of these two OS
(Ubuntu and FreeBSD) is gaining market share and which is losing it...
>Though one could argue that the ports maintainers could be a bit more
>careful about updates of things that touch a lot of other things, and
>especially their timing. I think I'll agree with that.
A bit more careful, well yes, to put it mildly. For my own part I'd
prefer a forked gettext, at GPLv2, giving individual port maintainers
the decision of which to use. That sure beats forcing version upgrades
on sysadmins and port maintainers from on high.
>Management will just have to cope. If they don't understand that,
>they're not fit for management.
It's not just management... There's a lot of pressure on organizations to
move from FreeBSD to Linux. Just look at Yahoo, once a solid FreeBSD
shop, which recently mandated RHEL for all new projects. Do you think
they don't understand the relative costs and benefits?
>I think that I somewhat sympathise, if not with the OP's tone, but with
>the sentiment that the FreeBSD project overall, base and ports both,
>has coasted somewhat into a ``well it works for me'' mindset, which is
>rather unhelpful if your setup is valid but somewhat different.
Sure looks that way from here. Is this (applying some best practices
to ports tree management) anything the FeeBSD foundation would look at?
Paco
Paco
>I guess I'm not typical, but I just keep the ports tree that comes with
>the release ISOs, and everything generally works fine. Yes, I won't
>have the very latest 'foo' if I decide to install 'foo', but in general,
>who cares?
That's what we used to do too, before getting burnt by one of the numerous
"unannounced" PHP vulnerabilities. Unfortunately, not all security
fixes make it to announcements, Portaudit, CERT, Bugtraq, or otherwise.
As it stands now there's simply not enough time or money to do all these
worthless updates, in all the various base OSs and jails. Won't be until
the next major version upgrade either. We've also lost the ability to do
meaningful reports using "pkg_version -L", lost a lot of the functionality
that got us using FreeBSD in the first place, gained an ever more difficult
job of rationalizing FreeBSD to all the new hires who only know Linux,
and are getting nothing but grief from the old managers they gripe to.
Paco
jpd
On 12 Jun 2008 02:54:08 GMT, Paco <nospa...@sonic.net> wrote:
> jpd <read_t...@do.not.spam.it.invalid> wrote:
>>As do I to an extent, but as others have noted, the problem is pretty
>>much independent from the base system. That distinction is important.
>
> Except that they're both essential components of FreeBSD and both play
> a key role in differentiating FreeBSD from other Unix/Linux OS'.
True enough. But you still have to be careful making blanket statements
about either, or attribute things to it that neither does or is.
> Taking the laissez-faire approach to release management, as per Philip's
> opinion that ports "merely tracks the upstream version", diminishes
> FreeBSD's value against the competition. You can bet Ubuntu doesn't let
> application version numbers skew like this.
The ports system strictly seen only tracks the patches needed to make the
upstream releases build and work on FreeBSD. The goal is just that, that
and giving you a tool to build softare and optionally put it in packages.
It does make fixing broken applications then submitting patches back to
the maintainer(s) easier over a binary emphasised system.
Ubuntu does something different entirely. It provides a full set of
supported software in binaries. Worse, it seems to just fail to tell
the upstream of the patches it created to fix bugs and other things.
FreeBSD's ``supported'' stuff is in the base system, the rest just
happens to work.
> Note which of these two OS (Ubuntu and FreeBSD) is gaining market
> share and which is losing it...
Cheap shot, and few here will care. Simply because ubuntu does something
different for a different market, starting from a different premise and
using a different system. If that's where you feel more comfy, or what
your skillset is more suited for, well, go ahead and switch.
Ubuntu is probably more comparable with PC-BSD in terms of its goals.
> For my own part I'd prefer a forked gettext, at GPLv2, giving
> individual port maintainers the decision of which to use.
That would put a lot more strain on keeping the ports tree stable
and compiling than a simple licence change that doesn't affect the
substantial part of the package (the library).
You can argue about the wisdom of tracking the change right away, but
forking I don't feel is an adequate solution. There are other ways to
soften the impact of the change, though. You can keep the change out of
your local ports tree until you're ready to do a full rebuild.
>>Management will just have to cope. If they don't understand that,
>>they're not fit for management.
>
> It's not just management... There's a lot of pressure on organizations to
> move from FreeBSD to Linux. Just look at Yahoo, once a solid FreeBSD
> shop, which recently mandated RHEL for all new projects. Do you think
> they don't understand the relative costs and benefits?
From past discussions with people who then were working or used to work
at yahoo, they've been moving that way for a long time now, from what
I gather due to management sillyness, certain divisions losing clue,
perhaps inter-division infighting, and other bigcorp mis-situations.
Had they moved to, oh, gentoo, then I would've been lots more worried
about FreeBSD and its ports system.
One could debate setting up an enterprise FreeBSD distributor and
support operation, but I don't have enough of an idea to guestimate
whether there's enough market to sustain such a thing.
It'd be an interesting venture, though.
> Is this (applying some best practices to ports tree management)
> anything the FeeBSD foundation would look at?
I don't know. Ask them?
I think it is probably worth a shot.
jpd
On 12 Jun 2008 03:07:05 GMT, Paco <notfo...@sonic.net> wrote:
> As it stands now there's simply not enough time or money to do all these
> worthless updates, in all the various base OSs and jails.
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).
> gained an ever more difficult job of rationalizing FreeBSD to all the
> new hires who only know Linux, and are getting nothing but grief from
> the old managers they gripe to.
``The old managers'' being systems people? Your problem is much more
with educating new hires and running a shop than it is with a particular
system. You can outsource the building stuff to RHEL or any other linux
distribution, thus trading on required skill levels, and it may help
for a while. But I don't think you'll run a better shop for it, if you
don't also bring your people's skill levels up to par, and, even if
you're already a full one flavour shop you might need to re-work your
deployment procedures because your shop has grown larger.
I really think this isn't strictly system dependent but more of a side
effect of growing ever larger, both in people and in deployed systems.
And now matter which way you look at it, unless you stop growing you
have no choice but to look very critically at how you're doing things.
Joerg Schilling
jpd <read_t...@do.not.spam.it.invalid> wrote:
>Can you live with a cdrecord without rscsi and cddb? I can, and mine has
>exactly no dependencies according to pkg_info. It's probably why I added
>atapicam to the kernel, though.
I am not sure what you refer to, but it may be that you use a very old version
of cdrecord/cdrtools.
Since a year, at least mkisofs depends on gettext(3) and iconv(3).
If you did not install the related software, it still compiles but you
will not be able to correctly work in a UTF-8 based user environment.
Joerg Schilling
Martin Etteldorf <ette...@email.lu> wrote:
>J. Porter Clark <j...@porterclark.com> wrote:
>> Martin Etteldorf <ette...@email.lu> writes:
>>
>>>Robert Melson <mel...@aragorn.rgmhome.net> wrote:
>>
>>>> Days. Yeah, I know, it's a function of what you have installed.
>>>> I have chosen to use my system as a workstation,
>>
>>>I'm doing that as well, and -- believe it or not -- you can still
>>>live fine without Gnome and KDE.
>>
>> Yes, but can you live without cdrecord? 8-(
>
>Yes. *For me*, burncd and dvd+rw-tools are sufficient.
Looks like a funny missunderstanding.....
burncd is non-portable and both programs do not implement the
features you get from cdrecord. In addition both programs still
require mkisofs which is maintained as part of cdrtools since
more than 10 years now.
>BTW: cdrecord needs neither gettext nor iconv if you have set
>WITHOUT_NLS=yes in your build environment. Setting this is a good
>idea anyway if you don't need it, as it also helps a lot to avoid
>installing unnecessary packages.
The build system does not understand something like "WITHOUT_NLS=yes"
and mkisofs will not be able to work correctly in a UTF-8 based locale
if there is no iconv(3).
Joerg Schilling
Paco <spam...@sonic.net> wrote:
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>Well, you are right never versions of cdrtools include libfind which
>>is by default compiled against gettext(3). I thought that GNU gettext(3)
>>if LGPL and did not care. I just checked gettext-0.17 which seems
>>to bee the latest and gettext(3) is still LGPLv2.
>
>Interesting. When I:
>
> cd /usr/ports/devel/gettext
> make
> more work/gettext-0.17/NEWS
>
>it clearly indicates:
>
> * License:
> The gettext related programs and tools are now licensed under the GPL
> version 3, instead of the GPL version 2. The libintl library continues
> to be licensed under LGPL.
As I mentioned already: gettext(3) is still under LGPLv2
>So does this mean that any commercial, non-OSS application developer
>who calls crdrtools from their app can now be sued, regardless of whether
>they modify your code or not?
See above: cdrtools use gettext(3) and iconv(3). These functions are
inside LGPLv2 libs.
If these functions are ever converted into GPL, then distributors (not
authors likee me or users) may be sued. This e.g. is why you need to take
care to avoid "libcdio" for GNOME on FreeBSD.
jpd
On 12 Jun 2008 08:34:16 GMT, Joerg Schilling <j...@cs.tu-berlin.de> wrote:
> I am not sure what you refer to, but it may be that you use a very old
> version of cdrecord/cdrtools.
Quite possible. This is *checks* cdrtools-2.01_6.
> If you did not install the related software, it still compiles but you
> will not be able to correctly work in a UTF-8 based user environment.
Mine isn't UTF-8 so I wouldn't've noticed.
Gettext and iconv are installed, but pkg_info -xrR cdrtools doesn't show
any dependencies. Might also be a broken package database, of course.
I'll have to check that soonish.
Joerg Schilling
jpd <read_t...@do.not.spam.it.invalid> wrote:
>Begin <6bc5c8F...@mid.dfncis.de>
>On 12 Jun 2008 08:34:16 GMT, Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>> I am not sure what you refer to, but it may be that you use a very old
>> version of cdrecord/cdrtools.
>
>Quite possible. This is *checks* cdrtools-2.01_6.
There is nothing like 2.01_6, but 2.01 is 4 years old and obsoleted by
current versions. The latest release is 2.01.01a40.
ftp://ftp.berlios.de/pub/cdrecord/alpha/
>> If you did not install the related software, it still compiles but you
>> will not be able to correctly work in a UTF-8 based user environment.
>
>Mine isn't UTF-8 so I wouldn't've noticed.
UTF-8 support was not needed in former times. It has been added a year ago.
You would of course need to upgrade cdrtools to a recent version first.
Given the fact that mkisofs did fix dozens of bugs since summer 2004 (this is
when 2.01 came out), I encourage you to upgrade.
jpd
On 12 Jun 2008 10:47:22 GMT, Joerg Schilling <j...@cs.tu-berlin.de> wrote:
> In article <slrng51pp4.2ur...@mantell0.local>,
> jpd <read_t...@do.not.spam.it.invalid> wrote:
>>Begin <6bc5c8F...@mid.dfncis.de>
>>On 12 Jun 2008 08:34:16 GMT, Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>> I am not sure what you refer to, but it may be that you use a very old
>>> version of cdrecord/cdrtools.
>>
>>Quite possible. This is *checks* cdrtools-2.01_6.
>
> There is nothing like 2.01_6, but 2.01 is 4 years old and obsoleted by
> current versions. The latest release is 2.01.01a40.
That number positively inspires confidence. How much trouble is it to
increase the minor number, instead of appending more numbers? ;-)
I know it's sort-of a fad, like the four numbers mozilla now needs and
then only uses the first and the last. And people gripe about ASN.1....
Anyway, my ports/sysutils/cdrtools/Makefile is 1.70 dated 2007-04-16,
where the latest is 1.72 dated 2008-04-11, and there don't seem to have
been updates to the related distinfo file in the meantime.
The very latest available in ports is 2.01.01a39 as cdrtools-devel.
It might be a good idea to do a formal 2.02 or something so that one
doesn't need the -devel port to have something halfway recent.
> Given the fact that mkisofs did fix dozens of bugs since summer 2004
> (this is when 2.01 came out), I encourage you to upgrade.
Well, I don't need it that often and the backups I take (done as iso
containing a couple of compressed tarballs) seem to work fine.
Being the reactionary conservative admin that I am, I'll stay away from
-devel ports on principle unless there is pressing need to do otherwise,
and then only grudgingly. And then there is that the old port doesn't
need libGNUGOO err libintl/libgettext.
I do think that a stable release every so often would help immensely.
Thierry Thomas
> > In these cases, just wait some days, and then use the packages built on
> > the compilation farm; just upgrade from ports when you have some
> > customized options.
> An option which is considered as the devil's tentation by many FreeBSD
> users, (note i have not said the penguin's way) and lacks proper tools
> to be used comfortably ...
Michel, I know your views about portupgrade, but the -P option has been
designed for that... Yes, it's slow, but yet better than recompiling
everything!
--
Th. Thomas.
Thierry Thomas
> Taking the laissez-faire approach to release management, as per Philip's
> opinion that ports "merely tracks the upstream version", diminishes
> FreeBSD's value against the competition. You can bet Ubuntu doesn't let
> application version numbers skew like this. Note which of these two OS
> (Ubuntu and FreeBSD) is gaining market share and which is losing it...
To be fair, you should compare a release of Ubuntu against a release of
FreeBSD: to prepare a release, the FreeBSD ports team do a lot of
quality assurance, and the packaged applications are stabilized and
coherent versions. Many people only install applications from these sets
of packages, with some upgrades for critical advices.
And, as a bonus, FreeBSD lets you pick new fresh ports from the CVS, and
new sets of packages are built and made available continuely: this is an
interesting possibility to get the ameliorations provided by the authors
but you have to decide by yourself if you need it or not, and when!
--
Th. Thomas.
Michel Talon
I have used portupgrade -P in the past, and my experience is that it is
crap to speak clearly. Half of the ports are rebuilt from source with
this option. It is no better with portupgrade -PP, because if it cannot
find a package it fails. To be complete, when using plain portupgrade,
there is a 50% probability that the build stops in the middle and leaves
you with an half upgraded box. The guy who has designed this aberration
should be shot. I completely agree with you however that people should
use binary packages, and upgrade from ports only when using customized
options. Unfortunately FreeBSD has no automated working tools to do
that.
--
Michel TALON
Martin Etteldorf
> In article <g2p9lb$h5j$1...@kadath.gruftie.net>,
> Martin Etteldorf <ette...@email.lu> wrote:
>>J. Porter Clark <j...@porterclark.com> wrote:
>>> Martin Etteldorf <ette...@email.lu> writes:
>>>
>>>>Robert Melson <mel...@aragorn.rgmhome.net> wrote:
>>>
>>>>> Days. Yeah, I know, it's a function of what you have installed.
>>>>> I have chosen to use my system as a workstation,
>>>
>>>>I'm doing that as well, and -- believe it or not -- you can still
>>>>live fine without Gnome and KDE.
>>>
>>> Yes, but can you live without cdrecord? 8-(
>>
>>Yes. *For me*, burncd and dvd+rw-tools are sufficient.
>
> Looks like a funny missunderstanding.....
That so?
> burncd is non-portable and both programs do not implement the
> features you get from cdrecord.
So what? I was asked whether I could live without cdrecord and
I answered, that *I* can live without it.
no offense... cdrecord is a great piece of software and to put
it frankly, I'm using it in environments other than FreeBSD.
But again: *I* don't need it *on a FreeBSD box*
> In addition both programs still require mkisofs
I'm afraid you're in the wrong here.
>>BTW: cdrecord needs neither gettext nor iconv if you have set
>>WITHOUT_NLS=yes in your build environment. Setting this is a good
>>idea anyway if you don't need it, as it also helps a lot to avoid
>>installing unnecessary packages.
>
> The build system does not understand something like "WITHOUT_NLS=yes"
Oh yes, the build system of FreeBSD (i.e. "ports"-Mechanism) does.
> and mkisofs will not be able to work correctly in a UTF-8 based locale
> if there is no iconv(3).
Now why exactly should I care about that in a solely non-UTF8-
Environment?
Michel Talon
> > burncd is non-portable and both programs do not implement the
> > features you get from cdrecord.
>
> So what? I was asked whether I could live without cdrecord and
> I answered, that *I* can live without it.
> no offense... cdrecord is a great piece of software and to put
> it frankly, I'm using it in environments other than FreeBSD.
> But again: *I* don't need it *on a FreeBSD box*
>
Maybe *you* can use burncd with your CD burner, but for a lot of
people, including myself with 3 different burners, it doesn't work,
pure and simple, while i don't have any problem with cdrecord.
--
Michel TALON
Robert Melson
That's been my experience with the -P and -PP options of portupgrade,
which is one of the reasons I pretty much confine myself to
rolling my own by compiling upgrades from the ports tree.
As for the rest, the sad fact is that there's no system out there
in the wild that has a completely satisfactory upgrade mechanism,
not even the major commercial houses. Unless it's changed in the
last couple of years, IBM's installp is a true abortion, as are
both Sun's and HP's attempts. In the case of FBSD, I really think
the problem is a compound of an increasingly cumbersome ports
system and upgrade tools that are less than optimal. What to do
about it? Dunno, to be honest, though a good start would be to
clean up and clean out the ports tree and by insisting that the
basic, core requirements be consistent - why, for example, should
one set of applications require glib-1XX and another group glib-2XX?
Why, if A requires B and B requires C, should C be listed as a
requirement for A? The whole system is creaky and cranky and, it
seems, largely undisciplined. Could I do better? Probably not
even as well, truth to tell. Does that make my observations any
less valid? I think not.
Bob Melson
--
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
Paco
>> Note which of these two OS (Ubuntu and FreeBSD) is gaining market
>> share and which is losing it...
>
>Cheap shot, and few here will care. Simply because ubuntu does something
>different for a different market
That's an odd way of magrginalizing someone's thesis. I guess you don't
see package release management as being an OS differentiator. From my
perspective it is not only a differentiator, it is _the_ differentiator.
Package subsystems are in many ways more important than the OS itself.
But I digress, having seen this type of forest and trees issue before.
In the 80s it was Osborne, Lotus, Borland, and Wordstar's market to lose,
in the 90s IBM, Sun, Quarterdeck, and Wordprefect's. FreeBSD and
BSD ports are at the same crossroads today. Of that I'm certain.
Paco
Martin Etteldorf
> Martin Etteldorf <ette...@email.lu> wrote:
>> > burncd is non-portable and both programs do not implement the
>> > features you get from cdrecord.
>>
>> So what? I was asked whether I could live without cdrecord and
>> I answered, that *I* can live without it.
>> no offense... cdrecord is a great piece of software and to put
>> it frankly, I'm using it in environments other than FreeBSD.
>> But again: *I* don't need it *on a FreeBSD box*
>>
>
> Maybe *you* can use burncd with your CD burner
Yes, that's exactly what I said.
jpd
On 13 Jun 2008 04:02:28 GMT, Paco <spamf...@sonic.net> wrote:
> jpd <read_t...@do.not.spam.it.invalid> wrote:
>>> Note which of these two OS (Ubuntu and FreeBSD) is gaining market
>>> share and which is losing it...
>>
>>Cheap shot, and few here will care. Simply because ubuntu does something
>>different for a different market
>
> That's an odd way of magrginalizing someone's thesis.
I don't think your argumentation is valid. It's akin to saying, oh,
trains are losing market because everybody wants a SUV. Both may be
true, but the connection between them is flimsy at best. Worse, it reeks
of trolling for any reaction, which if true justifies dismissing the
argument with prejudice, were such necessairy on usenet. Use a better
comparison and you get a better argument.
> I guess you don't see package release management as being an OS
> differentiator. From my perspective it is not only a differentiator,
> it is _the_ differentiator. Package subsystems are in many ways more
> important than the OS itself.
The key of the ports system is that it offers you lots of things beyond
mere binary packages that makes it attractive for people who need that
sort of thing. You seem to have problems justifying its use, meaning
that you're not taking full advantage of what it can do.
That's fine: There are many other systems that offer a different set of
features and have different skill requirements. If you can find a system
better suited to your needs, then use that.
*I think*, basing on reading between the lines of what you said earlier,
that your shop seems to need to re-evaluate and adjust how it is doing
what it is doing. I also think that FreeBSD may still be a good choice,
but even if not, you'll know that better after looking at how your shop
functions. That'll work better than just venting your frustration here.
> But I digress, having seen this type of forest and trees issue before.
> In the 80s it was Osborne, Lotus, Borland, and Wordstar's market to lose,
> in the 90s IBM, Sun, Quarterdeck, and Wordprefect's. FreeBSD and
> BSD ports are at the same crossroads today. Of that I'm certain.
You're forgetting that those were commercial enterprises depending on
their users to generate them revenue.
FreeBSD, like many other OSS projects, merely depends on enough people
willing to put effort into improving the system, and perhaps a few
generous people to provide some funding for infrastructure.
You can insist on trying to find the real cause for your frustration
externally, but you won't find it here. It also makes you sound like
a troll. If nothing else, you'll have to come up with much better
arguments, but you'll probably have to bring people who care too.
Paco
>I don't think your argumentation is valid. It's akin to saying, oh,
>trains are losing market because everybody wants a SUV. Both may be
>true, but the connection between them is flimsy at best. Worse, it reeks
>of trolling
If you don't think the argument is valid why then haven't you explained
the reasons release management is important for a base OS but not a
ports subsystem? Without this your argument is inconsistent.
How is it ok to either lose the ability to do incremental updates or
spend a hours reconciling libraries (in-between releases) in ports but
not in base? The distinction is lost on those of us who maintain both.
>The key of the ports system is that it offers you lots of things beyond
>mere binary packages that makes it attractive for people who need that
>sort of thing. You seem to have problems justifying its use, meaning
>that you're not taking full advantage of what it can do.
I fully understand the advantage of FreeBSD's ports. That's why I raised
this issue in the first place. You are simply venting, but let me ask you
a question: aside from the advantages of source-based vs release-based
ports, does FreeBSD ports subsystem offer any other advantages over
Ubuntu's? I guess I should first ask if you have ever used a package
manager like aptitude or synaptic. The way you've dismissed each's
differential advantages makes it seem unlikely.
>FreeBSD, like many other OSS projects, merely depends on enough people
>willing to put effort into improving the system, and perhaps a few
>generous people to provide some funding for infrastructure.
Give me a break. That's not even tangentially related to whether or not
the ports-maintainer is capable of applying release management best
practices. That's the issue here, industry best practices. FreeBSD
doesn't exist in a vacuume, it exists in a competitive environment.
If sloppy ports release management doesn't diminish FreeBSD's market
share, mindshare, number of users, number of contributors, or the
viability of its future releases, then everything I've ever learned
about software development is wrong.
>You can insist on trying to find the real cause for your frustration
>externally, but you won't find it here. It also makes you sound like
>a troll.
There you go again, shooting the messenger. Now how about replying to
the substantive questions asked above?
Paco
JE
> jpd <read_t...@do.not.spam.it.invalid> wrote:
>>I don't think your argumentation is valid. It's akin to saying, oh,
>>trains are losing market because everybody wants a SUV. Both may be
>>true, but the connection between them is flimsy at best. Worse, it reeks
>>of trolling
>
> If you don't think the argument is valid why then haven't you explained
> the reasons release management is important for a base OS but not a
> ports subsystem? Without this your argument is inconsistent.
>
> How is it ok to either lose the ability to do incremental updates or
> spend a hours reconciling libraries (in-between releases) in ports but
> not in base? The distinction is lost on those of us who maintain both.
>
>>The key of the ports system is that it offers you lots of things beyond
>>mere binary packages that makes it attractive for people who need that
>>sort of thing. You seem to have problems justifying its use, meaning
>>that you're not taking full advantage of what it can do.
>
> I fully understand the advantage of FreeBSD's ports. That's why I raised
> this issue in the first place. You are simply venting, but let me ask you
> a question: aside from the advantages of source-based vs release-based
> ports, does FreeBSD ports subsystem offer any other advantages over
> Ubuntu's? I guess I should first ask if you have ever used a package
Getting into the differences of FreeBSD versus Linux is a HUGE can of worms.
If you are not aware of why FreeBSD is NOT a linux "distro", then you should
go do some homework and come back later.
< remainder of post snipped as credibility of poster shattered by previous
statement >
Cheers
JE
jpd
On 14 Jun 2008 04:00:02 GMT, Paco <nos...@sonic.net> wrote:
> jpd <read_t...@do.not.spam.it.invalid> wrote:
>>I don't think your argumentation is valid. It's akin to saying, oh,
>>trains are losing market because everybody wants a SUV. Both may be
>>true, but the connection between them is flimsy at best. Worse, it reeks
>>of trolling
>
> If you don't think the argument is valid why then haven't you explained
I am under no obligation to explain you anything. I'm saying that if
you want to discuss your point with me you need to do so on terms that
I find acceptable. Trolling I don't think acceptable. So I gave you the
chance to cleanse your argment of the stink of trolling.
The rest, sadly, consisted of you arguing yourself into a ``not to be
taken seriously'' corner. Regardless of merit of your actual point, this
means that I will not discussing with you further.
Michel Talon
>
> Give me a break. That's not even tangentially related to whether or not
> the ports-maintainer is capable of applying release management best
> practices. That's the issue here, industry best practices. FreeBSD
> doesn't exist in a vacuume, it exists in a competitive environment.
> If sloppy ports release management doesn't diminish FreeBSD's market
> share, mindshare, number of users, number of contributors, or the
> viability of its future releases, then everything I've ever learned
> about software development is wrong.
Honestly in every system there are ports which are maintained in a
sensible way, and ports which are maintained by clowns. I know some
packages in Ubuntu which belong to the last category, even if most
packages are good. So you have to judge FreeBSD ports as an ensemble,
and, in my opinion, the vast majority of ports are well maintained,
up to date, and working. One cannot throw everything out of the window
because a small number of ports have ridiculous dependencies or don't
work. For me the mere richness of the ports system - the fact that we
have 18000 ports - is a considerable asset, similarly for Debian or
Ubuntu. I would never trade that for a minuscule number of ports like in
OpenBSD, even if considerably audited and polished. This necessarily
comes with a price, that a small number of ports are bad.
As for the general tools, and philosophy, it is a completely different
problem. My opinion is that the general philosophy - building everything
from source - is completely wrong, and a major cause of problems in
FreeBSD. The Linux distribution which shares this philosophy, Gentoo,
after a period of hype is now almost forgotten. People have discovered
that building from source is a total waste of time, and bring nothing to
the game except problems. The OpenBSD folks have understood this point
and are pushing for binary upgrades. Binary packages are the only way to
get a *reliable* system, in particular for upgrades. At present there is
no good system for managing such binary packages in FreeBSD, even if
such packages are continually produced on the FreeBSD cluster. To get
proper management, i think some small adaptations of the present ports
system should be necessary - this is non trivial and requires thinking
to corner cases, reading an UPDATING file should *never* be necessary,
and consequently the appropriate information should be available
directly in the ports system - but should represent very little tweaking
of the present system. Then a tool like aptitude should be built, this
is considerable work. Of course this is completely independant of
rewriting or polishing the ports system, whose performance was
horrendous, but has seen very beneficial performance improvements
recently.
Of course, as always, the major obstacle to progress is the conservatism
of a number of users, very vocal, who think that all is for the best in
the best of worlds. As a consequence, such discussions regularly emerge
in the newsgroups or mailing lists, and have exactly zero outcome.
In general you will be asked to produce a working implementation of
your ideas, this is the usual magic way of discarding so-called trolls.
Don't lose your time doing that, nobody will take a look at it.
While all this interesting discussions take place, as you are saying,
Ubuntu is storming the market. Probably FreeBSD will become a niche OS,
used in embedded equipment like Cisco or Juniper, by people who don't
want to use GPL stuff, hence cannot rely on Linux, but want to profit
form a competent pool of developers, and a good performant OS, which
is the case of FreeBSD.
--
Michel TALON
Balwinder S Dheeman
Moreover, FreeBSD developers and, or port maintainers including the
mentors are quite ignorant and, or reluctant to accept and, or rectify a
lot of simple flaws in the present ports management and, or build system
-- for example the upstream qt-x11-opensource-src-4.3.4.tar.gz source
is (re)extracted and (re)compiled 32 times to build and install the
following (sub)ports and, or packages:
qt4-4.3.4_1 qt4-opengl-4.3.4_2
qt4-accessible-4.3.4_1 qt4-pixeltool-4.3.4_1
qt4-assistant-4.3.4_1 qt4-porting-4.3.4
qt4-corelib-4.3.4_1 qt4-qdbusviewer-4.3.4_1
qt4-dbus-4.3.4_1 qt4-qmake-4.3.4
qt4-designer-4.3.4_1 qt4-qt3support-4.3.4_2
qt4-doc-4.3.4 qt4-qtconfig-4.3.4_1
qt4-gui-4.3.4_2 qt4-qtestlib-4.3.4_1
qt4-iconengines-4.3.4_1 qt4-qvfb-4.3.4_1
qt4-imageformats-4.3.4_1 qt4-rcc-4.3.4
qt4-inputmethods-4.3.4_1 qt4-script-4.3.4_1
qt4-libQtAssistantClient-4.3.4_1 qt4-sql-4.3.4_1
qt4-linguist-4.3.4_1 qt4-svg-4.3.4_1
qt4-makeqpf-4.3.4_1 qt4-uic3-4.3.4_2
qt4-moc-4.3.4 qt4-uic-4.3.4
qt4-network-4.3.4_1 qt4-xml-4.3.4_1
just to sub-divide an upstream package into FreeBSD sub-packages, which
may easily fill up your disk partition. I'm sure the FreeBSD developers
are already aware of this and many other such ports and, or packages.
I'm unable to guess, what religious agony is distracting FreeBSD
developers in adapting kind of some Debian/Ubuntu build/package
management system.
--
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/
Paco
>Moreover, FreeBSD developers and, or port maintainers including the
>mentors are quite ignorant and, or reluctant to accept and, or rectify a
>lot of simple flaws in the present ports management and, or build system
It appears they do know, if the traffic on freebsd-ports@ is any
indication:
http://www.archivum.info/freebs...@freebsd.org/2008-06/msg00100.html
> Great, all ports depending on devel/gettext got bumped.
>
> My Shell script checks every single library and executable on the system
> with ldd and it says _nothing is amiss_ after upgrading devel/gettext.
>
> Now I am condemned to rebuild ~100 ports, even though it is completely
> unnecessary. I do not have to tell you that downloading all the distfiles
> over a GSM connection will take days. And all this for no reason at all!
>
> What's going on here?
>
> Ldd says it's not necessary. Can anyone really argue with that?
http://www.archivum.info/freebs...@freebsd.org/2008-06/msg00285.html
> Remarkable.
>
> In my reality, libintl was bumped from so.6 to .so.8 with the update
> to gettext 0.16.1 and has stayed at .so.8 since. In particular,
> there was no libintl bump as part of the update to 0.17.
http://www.archivum.info/freebs...@freebsd.org/2008-06/msg00313.html
> If that is the case then the gettext warning from 20080605 in
> /usr/ports/UPDATING was entirely wrong and all the version
> bumping has been for naught. There was no reason to rebuild
> anything at all.
>
> Even worse than I assumed.
>I'm unable to guess, what religious agony is distracting FreeBSD
>developers in adapting kind of some Debian/Ubuntu build/package
>management system.
By most metric's FreeBSD ports system is far superior to Linux'
(front-ends and release management being the obvious exceptions).
The ability to define compile-time options is *BSD's greatest asset IMO.
Whereas most Linux distros force a pre-compiled model, FreeBSD allows
you to upgrade from source or (pre-compiled) packages.
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 :-(
Paco
Michel Talon
>
> By most metric's FreeBSD ports system is far superior to Linux'
> (front-ends and release management being the obvious exceptions).
> The ability to define compile-time options is *BSD's greatest asset IMO.
> Whereas most Linux distros force a pre-compiled model, FreeBSD allows
> you to upgrade from source or (pre-compiled) packages.
This is total bullshit. You can very well compile Linux packages for
many distros from source and tweak the options as much as you like.
For the case of Debian Linux, this is described in my comparison:
http://www.lpthe.jussieu.fr/~talon/freebsdports.html
There is a Linux distribution whose aim is to compile from source,
Gentoo, almost nobody uses it, because this is not an asset it is
a major cause of problems.
>
> 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. And second, how do you propose to pay these professionnal,
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.
> Paco
--
Michel TALON
Steve O'Hara-Smith
Paco <notfo...@sonic.net> 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 :-(
How about simply a team big enough to do release engineering on a
collection of nearly 19000 pieces of third party software! Personally I
think they do a remarkable job of it.
--
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/
Balwinder S Dheeman
> Paco <notfo...@sonic.net> wrote:
>> By most metric's FreeBSD ports system is far superior to Linux'
>> (front-ends and release management being the obvious exceptions).
>> The ability to define compile-time options is *BSD's greatest asset IMO.
>> Whereas most Linux distros force a pre-compiled model, FreeBSD allows
>> you to upgrade from source or (pre-compiled) packages.
>
> This is total bullshit. You can very well compile Linux packages for
> many distros from source and tweak the options as much as you like.
> For the case of Debian Linux, this is described in my comparison:
> http://www.lpthe.jussieu.fr/~talon/freebsdports.html
> There is a Linux distribution whose aim is to compile from source,
> Gentoo, almost nobody uses it, because this is not an asset it is
> a major cause of problems.
I second that, may I add that only experienced/hardcore and, or somewhat
biased professionals prefer FreeBSD and, or Gentoo over Debian, Ubuntu
and, or Fedora; even though there is no documentary proof available on
the community marketed hype about said performance gains by compiling
and, or fine-tuning each and every port/package again and again on
individual development machines; IMHO, that's merely a wastage of time
and resources. The http://wiki.archlinux.org/index.php/Arch_vs_Others,
though might slanted, but is quite informative.
>> 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. And second, how do you propose to pay these professionnal,
> 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.
We need to increase the user-base, by making the FreeBSD base and ports
system easy to install, upgrade and, or maintain, which definitely will
attract more developers also; need I repeat that this one is a basic and
only principle behind growth and, or survival of most of the Free/Libre
Open Source Software projects.
Balwinder S Dheeman
> On 24 Jun 2008 04:21:10 GMT
> Paco <notfo...@sonic.net> 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 :-(
>
> How about simply a team big enough to do release engineering on a
> collection of nearly 19000 pieces of third party software! Personally I
> think they do a remarkable job of it.
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.
Steve O'Hara-Smith
Balwinder S Dheeman <bsd.S...@cto.homelinux.net> wrote:
> On 06/24/2008 02:23 PM, Steve O'Hara-Smith wrote:
> > On 24 Jun 2008 04:21:10 GMT
> > Paco <notfo...@sonic.net> 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 :-(
> >
> > How about simply a team big enough to do release engineering on
> > a collection of nearly 19000 pieces of third party software! Personally
> > I think they do a remarkable job of it.
>
> 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 ?
Balwinder S Dheeman
> On Tue, 24 Jun 2008 15:34:40 +0530
> Balwinder S Dheeman <bsd.S...@cto.homelinux.net> wrote:
>
>> On 06/24/2008 02:23 PM, Steve O'Hara-Smith wrote:
>>> On 24 Jun 2008 04:21:10 GMT
>>> Paco <notfo...@sonic.net> 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 :-(
>>> How about simply a team big enough to do release engineering on
>>> a collection of nearly 19000 pieces of third party software! Personally
>>> I think they do a remarkable job of it.
>> 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 ?
Yeah, I already am contributing as much time and, or effort as I can by
installing, compiling, testing and, or exploring around 800 ports or
packages. IMHO, every FreeBSD user, somehow, is/can be a contributor
even by providing good feedback.
FYKI, I also am a maintainer/submitter, though for few FreeBSD ports at
the moment, please see http://cto.homelinux.net/ports, but the list may
grow and, or shrink in the near future depending upon the responsiveness
of the FreeBSD mentors and time I may spare at early fifties :)
As for as the rectification of the flaws in FreeBSD ports build and, or
packaging system are concerned, well, though that's not a small job, I
positively, shall try contributing patches and, or suggestions for the same.
Michel Talon
> >
> > 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
coolix
> 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 ?
Michel Talon
> 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
Steve O'Hara-Smith
ta...@lpthe.jussieu.fr (Michel Talon) wrote:
> Steve O'Hara-Smith <ste...@eircom.net> 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.
Balwinder S Dheeman
> 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.
Paco
>> 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
Michel Talon
>
> > 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
Philip Paeps
> Michel Talon <ta...@lpthe.jussieu.fr> 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
phi...@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
Paco
>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
Steve O'Hara-Smith
Balwinder S Dheeman <bsd.S...@cto.homelinux.net> 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.
Robert Melson
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
Balwinder S Dheeman
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'.
Steve O'Hara-Smith
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.
Philip Paeps
> Philip Paeps <philip...@paeps.cx> 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
phi...@paeps.cx I follow the newsgroup.
BOFH Excuse #212:
Of course it doesn't work. We've performed a software upgrade.
Paco
>> > 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
jpd
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.
Paco
>>>> > 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
Wolfgang Schelongowski
>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
jpd
On 28 Jun 2008 23:15:29 GMT, Paco <notfor...@sonic.net> wrote:
> jpd <read_t...@do.not.spam.it.invalid> 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.
Har har. And you weren't? The previous time you pulled the exact same
trick. You run out of arguments, start calling people shills, and when
told that's no way to keep a discussion open and interesting, start
trying to accuse the person who just told you off of the exact same
things, except in a very special paco sauce.
I'm willing to accept that this is just that you are running into your
own limits here, but then it's time for you to accept that you were Just
Plain Wrong and move on to more productive things. Like, oh, trying to
be part of the solution instead of insisting on assigning blame.
We don't play the blame game here.
Well, most of us anyway. The thing is, we'd rather have a reasonably
working system than a lot of blame and no system. So bitching that it
doesn't work easily means you get handed the job of coming up with at
least a proposal or a design if not working code that does it better.
You have been invited to do so half a dozen times or so in this thread,
by various people. Pray tell, has your contribution to this very same
thread included at least 50% of constructive design discussion?
> 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)
You're mixing up a few things here, or rather, who said what. That and
forgetting that you can't threaten to fire volunteers. In fact, you're
even forgetting you're a complete outsider to the organisation and
nowhere near the people making policy. You do not have that say.
Neither do I, but contrary to you, I don't claim I do. I do know and so
I explained that this organisation, or rather, community, has a habit of
simply farting in the general direction of anyone who tries to pull fast
ones like you have tried to, and tried it rather ineptly at that.
You've been repeatedly informed of this and that you need to do better
to be taken seriously, yet you insist. Well, we'll just insist on not
taking you seriously. In this, previous attempts clearly show that you
have a better chance of getting the phone company to care.
> 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.
There's always a few newbies that think their opinion trumps everything,
including the well-ment advice from people who clearly do know better.
>>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?
Instead of what you claim, I told you to not try and call Philip names,
as they're transparant attempts to troll for reactions (shortened to
simply ``trolling'' in the vernacular, in case you weren't aware).
In the above paragraph I invited you to excercise your wisdom and
knowledge you seem to feel vastly superior to that possessed by the
entirety of the FreeBSD project, and fix the problems in a system
you blame on its creators' incompetence. In doing so, I apparently
``accomplished'' eliciting a reaction from you wherein you show yourself
functionally illiterate.
Well, it's all in a day's work, I guess. I must admit that I feel it
is a bit of a disappointment, altough not entirely unexpected, as it
seems to dash all hopes of a better world, or at least a better ports
collection replacement. Still, can't have everything, eh.
Balwinder S Dheeman
Paco:
Almost all the anonymous people like jpd, shall/can never bring any name
for the FreeBSD and, or any such systems/project. IMHO, we either should
ignore these kinds of planted trolls or strongly condemn them once and
for all.
I've never posted except with my real name and email address, and that
goes back 12 years. There's always been a certain level of anonymity
since people can choose a username that doens't match their real name,
and of course there was 'anon.penet.fi' where people could post with a
certain level of anonymity. But I chose not to. There are things that
I may hesitate to post about, but that's a personal thing, and
ultimately those things I don't post and, or reply about are by
definition less important than the things I do post about. But I
decided that anonymity removes power and authenticity from posts,
because it's really easy to say something when you can't be accountable.
jpd:
You do realize Nelson Mandela was in jail for decades for what amounts
to terrorist acts. If you want a better signpost, check to see if Philip
Berrigan is on the list, someone who did time for civil disobedience but
always took the responsibility, waiting to be arrested after the deed.
That's a far better model for changing society than hiding behind
anonymity out of fear.
Giorgos Keramidas
There have been replies from eponymous members of the _current_ FreeBSD
team too. Two of the replies I saw were from:
Thierry Thomas in message <slrng52td5....@graf.pompo.net>
Philip Paeps in message <slrng63vjj.tn...@carrot.paeps.cx>
Thierry is a ports-committer, thus a member of the Ports team, and
Philip is an src-committer. Yours truly is a doc-committer and has been
watching this thread unfold in amazed silence.
Do we _really_ have to drag the thread low enough where "ad hominem"
attacks are all that is left?
> jpd:
> You do realize Nelson Mandela was in jail for decades for what amounts
> to terrorist acts. If you want a better signpost, check to see if
> Philip Berrigan is on the list, someone who did time for civil
> disobedience but always took the responsibility, waiting to be
> arrested after the deed. That's a far better model for changing
> society than hiding behind anonymity out of fear.
Being anonymous doesn't make him also "wrong" when he says that the best
way of fixing something is actually jumping in and writing the code to
fix it.
jpd
Wolfgang Schelongowski <Wolfgang.Sc...@gmx.de> wrote:
> jpd <read_t...@do.not.spam.it.invalid> 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?
There is a SANE paper[1] on this particular thing, and ISTR there was
a site about it too. Searching for the more hardware-related PXE boot
options also gives numerous interesting links.
Then there are the bits on FreeBSD.org about building your own release.
You can of course maintain a set of built packages tailored for your
shop's needs. Automating base rollout on a standard layout I did with a
few scripts on a machine that supported hot-swapping of disks. You can
do it with PXE as above too, or you could build your own CD with base
and collected packages, keep those on an nfs mount, etc.
Other interesting approaches to part of the problems include cfengine
and arusha (ark)[2] though those are not FreeBSD specific. There may be
more, I've not kept up due to circumstances.
[1] _Installing and maintaining clusters of UNIX servers using PXE and rsync_
http://www.nluug.nl/events/sane2002/papers/SANE.ps
[2] http://ark.sourceforge.net/
Balwinder S Dheeman
No, this has never been my intension.
FYKI, I after discovering flaws in the FreeBSD ports build framework
and, or systems have also posted a few alternative ideas for solving the
problem, here on this thread itself.
BTW, either you deliberately, have snipped/ignored an important portion,
"There are things that I may hesitate to post and, or reply about, but
that's a personal thing, and ultimately those things I don't post and,
or reply about are by definition less important than the things I do
post about." or you totally failed to grasp what I was trying to say.
>> jpd:
>> You do realize Nelson Mandela was in jail for decades for what amounts
>> to terrorist acts. If you want a better signpost, check to see if
>> Philip Berrigan is on the list, someone who did time for civil
>> disobedience but always took the responsibility, waiting to be
>> arrested after the deed. That's a far better model for changing
>> society than hiding behind anonymity out of fear.
>
> Being anonymous doesn't make him also "wrong" when he says that the best
> way of fixing something is actually jumping in and writing the code to
> fix it.
I never object jpd and, or any other anonymous posters, if I agree with
them.
Giorgos Keramidas
>On 06/29/2008 01:08 PM, Giorgos Keramidas wrote:
>> There have been replies from eponymous members of the _current_ FreeBSD
>> team too. Two of the replies I saw were from:
>>
>> Thierry Thomas in message <slrng52td5....@graf.pompo.net>
>> Philip Paeps in message <slrng63vjj.tn...@carrot.paeps.cx>
>>
>> Thierry is a ports-committer, thus a member of the Ports team, and
>> Philip is an src-committer. Yours truly is a doc-committer and has been
>> watching this thread unfold in amazed silence.
>>
>> Do we _really_ have to drag the thread low enough where "ad hominem"
>> attacks are all that is left?
>
> No, this has never been my intension.
That's a bit reassuring :)
> FYKI, I after discovering flaws in the FreeBSD ports build framework
> and, or systems have also posted a few alternative ideas for solving
> the problem, here on this thread itself.
I seem to have missed the suggestions. It took me a while to go through
all the posts in the thread, so this is quite probably just me not paying
enough attention to all the details of some posts.
You do know there is a discussion list about improvements to Ports, the
mailing list at <freebs...@freebsd.org>, right? Maybe you should bring
these ideas about improvement to the list. At least then you stand a fair
chance of actually reaching the *Ports* *team* itself.
Marco van de Voort
>> >>> This is the case every time gettext updates. It's nothing new. The
>> >>> problem is so many things pulling in gettext. An even more real
>> >>> problem is things pulling in gettext surreptitiously just because
>> >>> it's on the system. I ranted about this on my blog:
>> >>
>> >> Yes, I remember funny upgrade of libtool or perl too.
>> >
>> > You're sure about the libtool part?
>>
>> Yes. Note that the big catch was not libtool, but changed naming of ports.
>> E.g. gtk12 changed into gtk-1.2
>
> When i wrote my paper on the FreeBSD ports system, the constant mania of
> changing the names of ports seemd to me to be the biggest gripe against
> the system. At least this is the sort of thing which brings absolutely
> nothing positive (except comforting the ego of some bikeshed painters)
> and causes a lot of trouble for ports management.
The big problem for me was that this didn't happen along some major version
line, without some form of grace (like having a bunch of symlinks for the
duration of that major version cycle)
IOW it could break ports (and binaries) over point releases.