Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Removing documentation
23 views
Skip to first unread message
George Mitchell
Feb 8, 2016, 6:18:29 AM2/8/16
to
On 02/08/16 04:55, John Marino wrote:
> On 2/8/2016 10:30 AM, Mathias Picker wrote:
>> [...]
>> To comment on the original bug report: removing portmaster from
>> documentation seems to be a bit premature. It's working fine for me,
>> and it seems quite a lot simpler to me than synth, which makes it
>> preferable in my book.
>
> Honestly you're the first one to say *that*.
> [...]
Then allow me to be the second. But then, I find poudriere
unusable on my build system (I don't use ZFS and my memory is
apparently too limited). Portmaster just does the right thing.
We get that you don't like portmaster. So please don't use it.
But don't deprive the rest of us. -- George
_______________________________________________
freebs...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-port...@freebsd.org"
> On 2/8/2016 10:30 AM, Mathias Picker wrote:
>> [...]
>> To comment on the original bug report: removing portmaster from
>> documentation seems to be a bit premature. It's working fine for me,
>> and it seems quite a lot simpler to me than synth, which makes it
>> preferable in my book.
>
> Honestly you're the first one to say *that*.
> [...]
Then allow me to be the second. But then, I find poudriere
unusable on my build system (I don't use ZFS and my memory is
apparently too limited). Portmaster just does the right thing.
We get that you don't like portmaster. So please don't use it.
But don't deprive the rest of us. -- George
_______________________________________________
freebs...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-port...@freebsd.org"
John Marino
Feb 8, 2016, 8:47:43 AM2/8/16
to
On 2/8/2016 2:40 PM, Mark Linimon wrote:
> On Sun, Feb 07, 2016 at 03:21:49PM +0100, John Marino wrote:
>> Anybody proposing to be maintainer, in my opinion, should first be
>> required to take over every open PR in bugzilla
>
> thus ensuring that no one would ever take it.
If the candidate is incapable of handling the PRs, why should s/he be
annointed the maintainer?
If, by making them the maintainer, they are expected to fix the PRs,
what difference does the action order make?
If it's the right person, the result will be that all known issues are
fixed and portmaster has a proven capable maintainer.
That's a bad thing? Proving qualifications is a bad thing?
This is not just any port, and it's difficult to maintain, so pardon me
if I'd like some proof.
JOhn
> On Sun, Feb 07, 2016 at 03:21:49PM +0100, John Marino wrote:
>> Anybody proposing to be maintainer, in my opinion, should first be
>> required to take over every open PR in bugzilla
>
> thus ensuring that no one would ever take it.
If the candidate is incapable of handling the PRs, why should s/he be
annointed the maintainer?
If, by making them the maintainer, they are expected to fix the PRs,
what difference does the action order make?
If it's the right person, the result will be that all known issues are
fixed and portmaster has a proven capable maintainer.
That's a bad thing? Proving qualifications is a bad thing?
This is not just any port, and it's difficult to maintain, so pardon me
if I'd like some proof.
JOhn
Greg 'groggy' Lehey
Feb 8, 2016, 5:53:50 PM2/8/16
to
On Monday, 8 February 2016 at 23:15:45 +0100, John Marino wrote:
> On 2/8/2016 11:07 PM, Greg 'groggy' Lehey wrote:
>> I think you're missing the point. If this were the criterion for
>> becoming maintainer, there's a good chance that nobody would
>> volunteer. Your suggestion would work in a corporate environment, but
>> that's not us.
>
> I have said repeatedly that this criteria is unique to portmaster
> due to it's presence in the handbook and to its [apparent]
> importance in the ports ecosystem.
This wasn't very obvious.
> I am NOT saying this is the criteria for every port. However, I would
> rather nobody volunteer if they aren't qualified so that decisions
> aren't kicked down the road like a can. I'm not looking to check a box
> resulting in no improvement, I want somebody qualified or not at all.
And that's what you're getting: not at all.
So how would things improve in this respect if we change to synth?
There we need a maintainer who understands Ada. OK, at the moment
that's you. But what happens when you relinquish maintainership for
whatever reason?
My feeling on the matter is that there's space for more than one tool,
as Mathias suggested. But I think it would help synth to have
user-oriented documentation similar to that for portmaster or
portupgrade ("to achieve this, do this..."). I could see this as a
good addition to the handbook (4.5.3.3). A(n objective) discussion of
the pros and cons of the three alternatives would also be useful.
Greg
--
Sent from my desktop computer.
Finger gr...@FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
> On 2/8/2016 11:07 PM, Greg 'groggy' Lehey wrote:
>> I think you're missing the point. If this were the criterion for
>> becoming maintainer, there's a good chance that nobody would
>> volunteer. Your suggestion would work in a corporate environment, but
>> that's not us.
>
> I have said repeatedly that this criteria is unique to portmaster
> due to it's presence in the handbook and to its [apparent]
> importance in the ports ecosystem.
This wasn't very obvious.
> I am NOT saying this is the criteria for every port. However, I would
> rather nobody volunteer if they aren't qualified so that decisions
> aren't kicked down the road like a can. I'm not looking to check a box
> resulting in no improvement, I want somebody qualified or not at all.
And that's what you're getting: not at all.
So how would things improve in this respect if we change to synth?
There we need a maintainer who understands Ada. OK, at the moment
that's you. But what happens when you relinquish maintainership for
whatever reason?
My feeling on the matter is that there's space for more than one tool,
as Mathias suggested. But I think it would help synth to have
user-oriented documentation similar to that for portmaster or
portupgrade ("to achieve this, do this..."). I could see this as a
good addition to the handbook (4.5.3.3). A(n objective) discussion of
the pros and cons of the three alternatives would also be useful.
Greg
--
Sent from my desktop computer.
Finger gr...@FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
Walter Schwarzenfeld
Feb 8, 2016, 8:15:59 PM2/8/16
to
I don't agree with John Marino in some points, but Ada is a fine and
underrated language.
underrated language.
Torsten Zühlsdorff
Feb 9, 2016, 3:22:03 PM2/9/16
to
On 08.02.2016 02:18, Greg 'groggy' Lehey wrote:
> On Sunday, 7 February 2016 at 12:44:32 +0100, Torsten Zühlsdorff wrote:
>> Hello,
>>
>>>> You have a tool presented as "official" that hasn't had it's
>>>> original maintainer in 4 years and was only kept on life support up
>>>> until 9 months ago.
>>>
>>> Agreed, the "official" (the term used is "recommended") status is
>>> gone. But that's a reason to fix the documentation, not remove it.
>>> As I see it, we have three choices, in increasing order of
>>> desirability:
>>>
>>> 1. Remove all mention of portmaster. That's what this PR recommends.
>>> 2. Do nothing.
>>> 3. Update the documentation to indicate the current status,
>>> recommending alternatives if possible.
>>
>> Number 4 is missing: find a maintainer for it.
>
> Yes. It was there in my draft, and I removed it. It's a separate
> issue: I was asking here about what to do with documentation for used,
> but unmaintained packages. But you make a good point: if there's a
> lapse in maintainership, and the product then becomes maintained
> again, you don't want to lose the documentation.
There is another point hidden: you don't want to lose the software itself.
At the moment i'm maintaining a greater number of software (also outside
FreeBSD). Every one of it is abandoned but very good. Every one is
feature complete and needs just small fixes for example when the
compiler requires this or a bug is found. Many software get lost (and
later reinvented with all needed maturing) because the author did not
maintain it anymore. While i dislike this kind of work we should be
fair: there is software which fulfill its purpose of its niche and just
need to keep running.
Greetings,
Torsten
> On Sunday, 7 February 2016 at 12:44:32 +0100, Torsten Zühlsdorff wrote:
>> Hello,
>>
>>>> You have a tool presented as "official" that hasn't had it's
>>>> original maintainer in 4 years and was only kept on life support up
>>>> until 9 months ago.
>>>
>>> Agreed, the "official" (the term used is "recommended") status is
>>> gone. But that's a reason to fix the documentation, not remove it.
>>> As I see it, we have three choices, in increasing order of
>>> desirability:
>>>
>>> 1. Remove all mention of portmaster. That's what this PR recommends.
>>> 2. Do nothing.
>>> 3. Update the documentation to indicate the current status,
>>> recommending alternatives if possible.
>>
>> Number 4 is missing: find a maintainer for it.
>
> Yes. It was there in my draft, and I removed it. It's a separate
> issue: I was asking here about what to do with documentation for used,
> but unmaintained packages. But you make a good point: if there's a
> lapse in maintainership, and the product then becomes maintained
> again, you don't want to lose the documentation.
There is another point hidden: you don't want to lose the software itself.
At the moment i'm maintaining a greater number of software (also outside
FreeBSD). Every one of it is abandoned but very good. Every one is
feature complete and needs just small fixes for example when the
compiler requires this or a bug is found. Many software get lost (and
later reinvented with all needed maturing) because the author did not
maintain it anymore. While i dislike this kind of work we should be
fair: there is software which fulfill its purpose of its niche and just
need to keep running.
Greetings,
Torsten
John Marino
Feb 10, 2016, 5:16:33 AM2/10/16
to
On 2/10/2016 11:09 AM, Lars Engels wrote:
> On Wed, Feb 10, 2016 at 10:40:44AM +0100, John Marino wrote:
>> On 2/10/2016 10:37 AM, Lars Engels wrote:
>>> On Tue, Feb 09, 2016 at 06:28:11PM +0100, John Marino wrote:
>>>> On 2/9/2016 4:15 PM, Lars Engels wrote:
>>>>>
>>>>> root@fbsd01:~ # synth status
>>>>> Querying system about current package installations.
>>>>> Stand by, comparing installed packages against the ports tree.
>>>>> Stand by, building pkg(8) first ... Failed!! (Synth must exit)
>>>>> Unfortunately, the system upgrade failed.
>>>>
>>>> Do you have a file called /var/log/synth/ports-mgmt___pkg.log ? If so,
>>>> does it provide clues?
>>>
>>> So it's missing the proxy variables.
>>>
>>
>> okay, so internally it's only installing resolv.conf in the builder
>> environment. Where are these proxy variables defined? When I
>> understand what's needed, I can give you a patch to try (if required)
>
> resolv.conf doesn't work in that proxy scenario. DNS requests are
> handled by the proxy server.
>
> I set
> HTTP_PROXY=http://proxyserver:8888; export HTTP_PROXY
> http_proxy=http://proxyserver:8888; export http_proxy
> ftp_proxy=http://proxyserver:8888; export FTP_PROXY
> ftp_proxy=http://proxyserver:8888; export ftp_proxy
>
> NO_PROXY="localhost,127.0.0.1,..."; export NO_PROXY
>
> in /etc/profile and
> :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,HTTP_PROXY=http\c//proxyserver\c8888,FTP_PROXY=http\c//proxyserver\c8888,NO_PROXY=localhost\054127.0.0.1\054...:\
>
> in /etc/login.conf
>
wow, okay, so basically these 4 variables would have to be present in
the builder environment then?
I'll have to think about this. I'll probably have to add a feature like
a file like "/usr/local/etc/synth/<profile>-environment which will
append user environment variables to the stock ones.
That's not exactly a 1-line change, but would that solve this issue?
John
> On Wed, Feb 10, 2016 at 10:40:44AM +0100, John Marino wrote:
>> On 2/10/2016 10:37 AM, Lars Engels wrote:
>>> On Tue, Feb 09, 2016 at 06:28:11PM +0100, John Marino wrote:
>>>> On 2/9/2016 4:15 PM, Lars Engels wrote:
>>>>>
>>>>> root@fbsd01:~ # synth status
>>>>> Querying system about current package installations.
>>>>> Stand by, comparing installed packages against the ports tree.
>>>>> Stand by, building pkg(8) first ... Failed!! (Synth must exit)
>>>>> Unfortunately, the system upgrade failed.
>>>>
>>>> Do you have a file called /var/log/synth/ports-mgmt___pkg.log ? If so,
>>>> does it provide clues?
>>>
>>> So it's missing the proxy variables.
>>>
>>
>> okay, so internally it's only installing resolv.conf in the builder
>> environment. Where are these proxy variables defined? When I
>> understand what's needed, I can give you a patch to try (if required)
>
> resolv.conf doesn't work in that proxy scenario. DNS requests are
> handled by the proxy server.
>
> I set
> HTTP_PROXY=http://proxyserver:8888; export HTTP_PROXY
> http_proxy=http://proxyserver:8888; export http_proxy
> ftp_proxy=http://proxyserver:8888; export FTP_PROXY
> ftp_proxy=http://proxyserver:8888; export ftp_proxy
>
> NO_PROXY="localhost,127.0.0.1,..."; export NO_PROXY
>
> in /etc/profile and
> :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,HTTP_PROXY=http\c//proxyserver\c8888,FTP_PROXY=http\c//proxyserver\c8888,NO_PROXY=localhost\054127.0.0.1\054...:\
>
> in /etc/login.conf
>
wow, okay, so basically these 4 variables would have to be present in
the builder environment then?
I'll have to think about this. I'll probably have to add a feature like
a file like "/usr/local/etc/synth/<profile>-environment which will
append user environment variables to the stock ones.
That's not exactly a 1-line change, but would that solve this issue?
John
Lars Engels
Feb 10, 2016, 6:11:11 AM2/10/16
to
My rather short experience:
Synth configuration profile: LiveSystem
===============================================================================
[A] Ports directory /usr/ports
[B] Packages directory /var/synth/live_packages
[C] Distfiles directory /usr/ports/distfiles
[D] Port options directory /var/db/ports
[E] Build logs directory /var/log/synth
[F] Build base directory /usr/obj/synth-live
[G] System root directory /
[H] Compiler cache directory disabled
[I] Num. concurrent builders 6
[J] Max. jobs per builder 4
[K] Use tmpfs for work area true
[L] Use tmpfs for /usr/local true
[M] Display using ncurses true
[N] Fetch prebuilt packages true
[>] Switch/create profiles
[RET] Exit
Press key of selection:
root@fbsd01:~ # synth status
Querying system about current package installations.
Stand by, comparing installed packages against the ports tree.
Stand by, building pkg(8) first ... Failed!! (Synth must exit)
Unfortunately, the system upgrade failed.
root@fbsd01:~ # uname -a
Querying system about current package installations.
Stand by, comparing installed packages against the ports tree.
Stand by, building pkg(8) first ... Failed!! (Synth must exit)
Unfortunately, the system upgrade failed.
FreeBSD fbsd01 10.2-RELEASE-p9 FreeBSD 10.2-RELEASE-p9 #0: Thu Jan 14 01:32:46 UTC 2016 ro...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
root@fbsd01:~ #
Not a very verbose message why it actually failed.
I need a proxy server to access the internet. Could this be the problem?
*_[pP][rR][oO][xX][yY] env vars are all set, though.
John Marino
Feb 10, 2016, 6:33:23 AM2/10/16
to
On 2/9/2016 9:27 PM, John Marino wrote:
> On 2/9/2016 9:20 PM, Warren Block wrote:
>> On Tue, 9 Feb 2016, John Marino wrote:
>>
>>> On 2/9/2016 7:20 PM, Warren Block wrote:
>>>>> If you have the build log, I'd like to see it. Dewayne G. got an error
>>>>> after overriding CPUTYPE (do you do that too?) and I'm thinking it's
>>>>> sensitive to CPU and I'd like to know more.
>>>>
>>>> Yes, I use
>>>>
>>>> CPUTYPE?=core-avx2
>>>
>>> What happens when you try to build lang/gcc6-devel ?
>>> Same issue or does it complete?
>>
>> It builds successfully, in about 40 minutes.
>
> My suspicion is that due to the bootstrap, we'd have two possible options:
> A) turn on the full bootstrap which takes the same amount of time as
> gcc6-devel does (I'm not sure it will work but there's a chance)
> B) I put CPUTYPE=native in the gcc6-aux Makefile
>
> I am inclined towards B. It works on DragonFly but I need somebody else
> to test it on i7 on FreeBSD. I asked Dewayne, but I'd be grateful if
> you could test it as well.
Hi Warren,
Dewayne got back to me, and it appears the only solution is to put
"CPUTYPE=" in the gcc6-aux makefile. I think the bootstrap compiler
(the ada-capable compiler downloaded to build gcc6-aux) doesn't know
these instructions and that's the issue. The options are don't override
CPUTYPE or regenerate the bootstrap, but that might have other
consequences or won't fix every combination.
> On 2/9/2016 9:20 PM, Warren Block wrote:
>> On Tue, 9 Feb 2016, John Marino wrote:
>>
>>> On 2/9/2016 7:20 PM, Warren Block wrote:
>>>>> If you have the build log, I'd like to see it. Dewayne G. got an error
>>>>> after overriding CPUTYPE (do you do that too?) and I'm thinking it's
>>>>> sensitive to CPU and I'd like to know more.
>>>>
>>>> Yes, I use
>>>>
>>>> CPUTYPE?=core-avx2
>>>
>>> What happens when you try to build lang/gcc6-devel ?
>>> Same issue or does it complete?
>>
>> It builds successfully, in about 40 minutes.
>
> My suspicion is that due to the bootstrap, we'd have two possible options:
> A) turn on the full bootstrap which takes the same amount of time as
> gcc6-devel does (I'm not sure it will work but there's a chance)
> B) I put CPUTYPE=native in the gcc6-aux Makefile
>
> I am inclined towards B. It works on DragonFly but I need somebody else
> to test it on i7 on FreeBSD. I asked Dewayne, but I'd be grateful if
> you could test it as well.
Hi Warren,
Dewayne got back to me, and it appears the only solution is to put
"CPUTYPE=" in the gcc6-aux makefile. I think the bootstrap compiler
(the ada-capable compiler downloaded to build gcc6-aux) doesn't know
these instructions and that's the issue. The options are don't override
CPUTYPE or regenerate the bootstrap, but that might have other
consequences or won't fix every combination.
Lars Engels
Feb 10, 2016, 7:01:11 AM2/10/16
to
On Tue, Feb 09, 2016 at 06:28:11PM +0100, John Marino wrote:
> On 2/9/2016 4:15 PM, Lars Engels wrote:
> >
> On 2/9/2016 4:15 PM, Lars Engels wrote:
> >
> > root@fbsd01:~ # synth status
> > Querying system about current package installations.
> > Stand by, comparing installed packages against the ports tree.
> > Stand by, building pkg(8) first ... Failed!! (Synth must exit)
> > Unfortunately, the system upgrade failed.
>
> > Querying system about current package installations.
> > Stand by, comparing installed packages against the ports tree.
> > Stand by, building pkg(8) first ... Failed!! (Synth must exit)
> > Unfortunately, the system upgrade failed.
>
> Do you have a file called /var/log/synth/ports-mgmt___pkg.log ? If so,
> does it provide clues?
>
> John
> does it provide clues?
>
=> pkg-1.6.3.tar.xz doesn't seem to exist in /distfiles/.
=> Attempting to fetch http://files.etoilebsd.net/pkg/pkg-1.6.3.tar.xz
fetch: http://files.etoilebsd.net/pkg/pkg-1.6.3.tar.xz: No address record
=> Attempting to fetch http://distcache.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz
fetch: http://distcache.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz: No address record
=> Attempting to fetch http://distcache.us-east.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz
fetch: http://distcache.us-east.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz: No address record
=> Attempting to fetch http://distcache.eu.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz
fetch: http://distcache.eu.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz: No address record
=> Attempting to fetch http://distcache.us-west.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz
fetch: http://distcache.us-west.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz: No address record
=> Attempting to fetch http://mirror.shatow.net/freebsd/pkg/pkg-1.6.3.tar.xz
fetch: http://mirror.shatow.net/freebsd/pkg/pkg-1.6.3.tar.xz: No address record
=> Attempting to fetch http://distcache.FreeBSD.org/ports-distfiles/pkg-1.6.3.tar.xz
fetch: http://distcache.FreeBSD.org/ports-distfiles/pkg-1.6.3.tar.xz: No address record
=> Couldn't fetch it - please try to retrieve this
=> port manually into /distfiles/ and try again.
Guido Falsi
Feb 10, 2016, 8:34:26 AM2/10/16
to
failed too in configure phase.
It appears that any setting "higher" than nocona makes the gcc ports
fail, not only gcc6.
--
Guido Falsi <m...@madpilot.net>
Lars Engels
Feb 10, 2016, 4:54:17 PM2/10/16
to
On Wed, Feb 10, 2016 at 01:15:58PM -0800, Kevin Oberman wrote:
> > > While I like the ideas of synth, and hoped I could use it to just build
> > > my 3-8 ports with modified options, on first look I found many things
> > > suggesting that it's not yet ready:
> > >
> > > - shows uninteresting eye candy instead of build
> >
> > Every single port has it's own build log with far more detail that a
> > source build provides (similar to poudriere)
> >
> > > - stops at every conf file version mismatch requiring me to start make
> > > config by hand, and then to re-run when it discovers the next mismatch.
> > > I mean, WTF?
> >
> > This is incorrect. It lists *ALL* the configuration mismatches at once.
> > This is actually a huge "pro" for synth; no other tool detects this
> > mismatches. It is far worse to have cached options that do not match
> > the current port. The port can be misbuilt and it's a major pain to
> > troubleshoot. All build tools should be doing this. Are you really
> > proposing that a tool build a port with a bad configuration file? You
> > should be thanking Synth for alerting to a problem you obviously didn't
> > know you had.
> >
> > Also, once you fix it, then configuration problems are rare, they occur
> > when the port changes.
> >
>
> OK. I have been playing with synth and I must say that I find it
> impressive. Not that I am ready to put it into "production", but
> impressive, none the less. Maybe after a bit more testing and updating all
> ports after moving from 10 to 11 (which will not be too soon). Still, it is
> way better than poudriere for my limited purposes. I will certainly use it
> for that, even if I still use portmaster for my "development" system.
>
> The stale configuration file issue has me a bit confused. The man page does
> not make it clear just what makes a config "stale". All of my ports are up
> to date as of 11:00 UTC this morning. As far as I know, all of the configs
> are "current", although the actual config run may have been for a much
> older version. "synth status shows 46 cases. I looked at one
> (sysutils/tmux) and the options listed by "make showconfig" are no
> different from those in the current Makefile, so I don't understand why
> they are stale.
>
> I also have found at least one thing portmster can do that synth can't, but
> I expect pkg can, so I won't complain about it until I have tried using pkg
> to list all top-level ports (nothing depends on them) to use to re-install
> all ports. I could list all ports, it's just that this is a much longer
> list and portmaster did the job nicely with a simple example in the man
> page.
You need to uncomment the "leaf" alias in /usr/local/etc/pkg.conf
leaf 'query -e "%a == 0" "%n-%v"'
Then "pkg leaf" works like pkg_cutleaves(8) or the portmaster option.
> On Mon, Feb 8, 2016 at 1:55 AM, John Marino <free...@marino.st> wrote:
>
> > On 2/8/2016 10:30 AM, Mathias Picker wrote:
> > > Am Montag, den 08.02.2016, 08:35 +0100 schrieb John Marino:
>
> > On 2/8/2016 10:30 AM, Mathias Picker wrote:
> > > While I like the ideas of synth, and hoped I could use it to just build
> > > my 3-8 ports with modified options, on first look I found many things
> > > suggesting that it's not yet ready:
> > >
> > > - shows uninteresting eye candy instead of build
> >
> > Every single port has it's own build log with far more detail that a
> > source build provides (similar to poudriere)
> >
> > > - stops at every conf file version mismatch requiring me to start make
> > > config by hand, and then to re-run when it discovers the next mismatch.
> > > I mean, WTF?
> >
> > This is incorrect. It lists *ALL* the configuration mismatches at once.
> > This is actually a huge "pro" for synth; no other tool detects this
> > mismatches. It is far worse to have cached options that do not match
> > the current port. The port can be misbuilt and it's a major pain to
> > troubleshoot. All build tools should be doing this. Are you really
> > proposing that a tool build a port with a bad configuration file? You
> > should be thanking Synth for alerting to a problem you obviously didn't
> > know you had.
> >
> > Also, once you fix it, then configuration problems are rare, they occur
> > when the port changes.
> >
>
> OK. I have been playing with synth and I must say that I find it
> impressive. Not that I am ready to put it into "production", but
> impressive, none the less. Maybe after a bit more testing and updating all
> ports after moving from 10 to 11 (which will not be too soon). Still, it is
> way better than poudriere for my limited purposes. I will certainly use it
> for that, even if I still use portmaster for my "development" system.
>
> The stale configuration file issue has me a bit confused. The man page does
> not make it clear just what makes a config "stale". All of my ports are up
> to date as of 11:00 UTC this morning. As far as I know, all of the configs
> are "current", although the actual config run may have been for a much
> older version. "synth status shows 46 cases. I looked at one
> (sysutils/tmux) and the options listed by "make showconfig" are no
> different from those in the current Makefile, so I don't understand why
> they are stale.
>
> I also have found at least one thing portmster can do that synth can't, but
> I expect pkg can, so I won't complain about it until I have tried using pkg
> to list all top-level ports (nothing depends on them) to use to re-install
> all ports. I could list all ports, it's just that this is a much longer
> list and portmaster did the job nicely with a simple example in the man
> page.
You need to uncomment the "leaf" alias in /usr/local/etc/pkg.conf
leaf 'query -e "%a == 0" "%n-%v"'
Then "pkg leaf" works like pkg_cutleaves(8) or the portmaster option.
John Marino
Feb 11, 2016, 3:17:51 PM2/11/16
to
On 2/11/2016 9:08 PM, Royce Williams wrote:
> On Thu, Feb 11, 2016 at 10:33 AM, John Marino <free...@marino.st> wrote:
>>
>> On 2/11/2016 8:25 PM, Lev Serebryakov wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA512
>>>
>>> On 07.02.2016 17:28, John Marino wrote:
>>>
>>>> ports-mgmt/synth. I would love to hear what signficant thing
>>>> portmaster can do that Synth can't. (honestly)
>>> Be installed FROM PORTS without all this build-one-more-gcc stuff.
>>> Ada? For *port*management* tool? Are you joking?
>>
>> Let me guess. You've spent actually 0.0 nanoseconds preparing on the
>> subject before providing this enlightened take for the list.
>
>
> Having read the entire thread, separate from the relative merits of
> Synth, the core of Lev's incredulity isn't that off the mark.
>
> On the face of it, Synth requiring ncurses seems reasonable ... but
> its Ada dependency is a bit of a mild POLA violation.
>
> Don't get me wrong -- I actually think Ada is pretty cool, and Lev
> could have been nicer about it ;), but he's essentially right.
>
> People's instincts are that software management is core functionality,
> and should have few unusual dependencies.
>
> My earlier side-thread point stands. FreeBSD software management is
> fragmented. Until that is resolved, a lot of time and effort will be
> wasted treating the symptoms.
Actually, you missed the fact that synth (nor poudriere) doesnt
re-invent anything. Both are tightly integrated with pkg(8). You spoke
of both as if they were similar to portupgrade.
The "wrapper situation" that you proposed is already here. So the whole
"fragmented" thing is not really true.
Synth is a binary. There's no POLA there.
There's no requirement to build from ports, that's an unsubstanciated
invention. Notice that not a single person could defend that position
after a challenge. There's no technical basis for it; it's just emotional.
In a straight fly-off against any of the tools, Synth wins hands down
with any objective measurement. Poudriere is slightly more bulletproof
and more appropriate for a cluster (as it was targetted at) but for
average user Synth is better suited.
It's a concurrent builder. Ada is a concurrent language. How is its
suitability even a debate?
John
> On Thu, Feb 11, 2016 at 10:33 AM, John Marino <free...@marino.st> wrote:
>>
>> On 2/11/2016 8:25 PM, Lev Serebryakov wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA512
>>>
>>> On 07.02.2016 17:28, John Marino wrote:
>>>
>>>> ports-mgmt/synth. I would love to hear what signficant thing
>>>> portmaster can do that Synth can't. (honestly)
>>> Be installed FROM PORTS without all this build-one-more-gcc stuff.
>>> Ada? For *port*management* tool? Are you joking?
>>
>> Let me guess. You've spent actually 0.0 nanoseconds preparing on the
>> subject before providing this enlightened take for the list.
>
>
> Having read the entire thread, separate from the relative merits of
> Synth, the core of Lev's incredulity isn't that off the mark.
>
> On the face of it, Synth requiring ncurses seems reasonable ... but
> its Ada dependency is a bit of a mild POLA violation.
>
> Don't get me wrong -- I actually think Ada is pretty cool, and Lev
> could have been nicer about it ;), but he's essentially right.
>
> People's instincts are that software management is core functionality,
> and should have few unusual dependencies.
>
> My earlier side-thread point stands. FreeBSD software management is
> fragmented. Until that is resolved, a lot of time and effort will be
> wasted treating the symptoms.
Actually, you missed the fact that synth (nor poudriere) doesnt
re-invent anything. Both are tightly integrated with pkg(8). You spoke
of both as if they were similar to portupgrade.
The "wrapper situation" that you proposed is already here. So the whole
"fragmented" thing is not really true.
Synth is a binary. There's no POLA there.
There's no requirement to build from ports, that's an unsubstanciated
invention. Notice that not a single person could defend that position
after a challenge. There's no technical basis for it; it's just emotional.
In a straight fly-off against any of the tools, Synth wins hands down
with any objective measurement. Poudriere is slightly more bulletproof
and more appropriate for a cluster (as it was targetted at) but for
average user Synth is better suited.
It's a concurrent builder. Ada is a concurrent language. How is its
suitability even a debate?
John
Torsten Zuehlsdorff
Feb 12, 2016, 4:00:45 AM2/12/16
to
On 12.02.2016 07:21, Royce Williams wrote:
>>> I'm advocating that we stop quasi-providing four different flavors of
>>> apt-get. Until there is a single and official mechanism for both
>>> dependency resolution and configuration option management, the
>>> fragmentation remains.
>>
>> Why do you think this is the case? Ports defines the dependencies and
>> pkg respects them. I'm not seeing where there more than one method
>> here. What other ones are there?
>
>
> The current ports/pkg relationship is still fragile, perhaps because
> it's new. I almost abandoned FreeBSD entirely a couple of months ago
> when an interesting corner case of the use of pkg managed to
> unilaterally and without warning delete in its entirety the contents
> of /usr/local/etc/rc.d in of my jails.
>
> Contrast this with the Ubuntu world, where there is a well-baked
> "unattended-upgrades" option that automatically downloads and upgrades
> all security updates for both the OS and all third-party packages.
These are not well-baked, i did find multiple problems with them.
Also this is *not* something you really want. If security really is
important you do not install software without your explicit approval.
There are to many things which can go wrong and normally do. These
complains are often in the Ubuntu world.
The Ubuntu world is not so bright as you say. ;)
Greetings,
Torsten
>>> I'm advocating that we stop quasi-providing four different flavors of
>>> apt-get. Until there is a single and official mechanism for both
>>> dependency resolution and configuration option management, the
>>> fragmentation remains.
>>
>> Why do you think this is the case? Ports defines the dependencies and
>> pkg respects them. I'm not seeing where there more than one method
>> here. What other ones are there?
>
>
> The current ports/pkg relationship is still fragile, perhaps because
> it's new. I almost abandoned FreeBSD entirely a couple of months ago
> when an interesting corner case of the use of pkg managed to
> unilaterally and without warning delete in its entirety the contents
> of /usr/local/etc/rc.d in of my jails.
>
> Contrast this with the Ubuntu world, where there is a well-baked
> "unattended-upgrades" option that automatically downloads and upgrades
> all security updates for both the OS and all third-party packages.
These are not well-baked, i did find multiple problems with them.
Also this is *not* something you really want. If security really is
important you do not install software without your explicit approval.
There are to many things which can go wrong and normally do. These
complains are often in the Ubuntu world.
The Ubuntu world is not so bright as you say. ;)
Greetings,
Torsten
Lev Serebryakov
Feb 12, 2016, 7:24:04 AM2/12/16
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
On 12.02.2016 00:32, Matt Smith wrote:
>>> ports-mgmt/synth. I would love to hear what signficant thing
>>> portmaster can do that Synth can't. (honestly)
>> Be installed FROM PORTS without all this build-one-more-gcc
>> stuff. Ada? For *port*management* tool? Are you joking?
>
> Remember that before portmaster we had cvsup which was written in
>>> ports-mgmt/synth. I would love to hear what signficant thing
>>> portmaster can do that Synth can't. (honestly)
>> Be installed FROM PORTS without all this build-one-more-gcc
>> stuff. Ada? For *port*management* tool? Are you joking?
>
> Modula-3 and portupgrade which is written in Ruby. Whilst it is
> nice that portmaster is just a simple shell script with no
> dependancies that's a relatively new thing.
I remember cvsup (great tool, for sure) as
only-binary-package-on-my-self-build-system, yes. And it annoyed me a
bit every time, that I need to download binary package :)
- --
// Lev Serebryakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQJ8BAEBCgBmBQJWvc7ZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePDrUP/33yYFNyrBKwfeSXQwxuqHZ7
l9VlJFzEwSGqM4pXstYZjkrv8MGYTbfpD9KLd2vURClTO3J9QU1FNugRw+8XkLi3
4sekwg3sxfN+vVIYvB/Oy5lcvl3u6sdOt8SRar5OYVkpoqhE0PHYeGpyCUT45BXy
RgdZFeQiBjwsxR2cphZtNbeLJPZiZ+fROfFZdfWM5VB5XtPAGrRybYQbCnngMEPb
lr84Sdi7yMk1n2LOPUnhpTK1XROn1HcX5EOozhaWmQ3fpV741ji3YvnglwoFbqc2
hOEiPsfrSHFy7Pnykqi0GWyF+QVzSk9xMiuLQjdTBFOjuHlIjJt6oWjBsrDfj+Ki
ee2UFN3RgNQhM7gIammfiVJSA1RHlqU9JH8Xn0fihhDgytVZoehmmwXLa3FfMZOJ
EAC6kpxG+npJaqJcSsDebyTf+8yTfvBegVEhi+a84EIXQgQr5GqMAPoH/RZgkACE
VK+Odc8JvLFGQr5ytOO76N3gl4hcb+07stmrfLmtsoUzNL7mFcgSLQ64TDBTqXML
MMBABec/h75XpuWCmCKE2DPSzEhD9D7khoj41no0pRnLf8En9n5FXnqedLCczCmN
GwC7av++WeXrMKnBO4wS4vwGNnwO5rdOB6SaL3k1qFCYwEk+z8rWLz+VLPKsDhER
uPUiFcyU/BG8hSzV8aqW
=9MbF
-----END PGP SIGNATURE-----
Royce Williams
Feb 12, 2016, 10:39:06 AM2/12/16
to
On Fri, Feb 12, 2016 at 5:56 AM, Jim Ohlstein <j...@ohlste.in> wrote:
> On 2/11/16 7:22 PM, Royce Williams wrote:
>> Is the abstraction is happening at the equivalent level here? The
>> platforms that I'm thinking of -- that appear to have already solved
>> this entire class of problem long ago -- feature wrappers around
>> apt-get, not wrappers around dpkg.
> sometimes they're the best currently available tool for the job at hand. I'd
> need about thirty hands to use my fingers to count how many times apt-get
> has left me with a broken package system, though aptitude usually is able to
> fix that. Most often that has happened after adding a third party repo (it
> happened recently with using MariDB's own repo instead of the official
> package) or when compiling from source and trying to delete unnecessary
> cruft. The biggest drawback to those systems is that compiling software and
> registering it can be a pain in the ass. The second biggest problem is those
> systems (Debian and Ubuntu specifically) are built around users who are
> totally willing to have the developers choose which options will be compiled
> in to "official" and "non-official" repos. That is, people who compile their
> own binaries are really an afterthought in the Debian and Ubuntu world. Some
> might call that a strength, and yes, dpkg is a nice system for people who
> want that kind of thing. It's made Debian based systems very popular, no
> doubt about it.
Third-party repos are an entirely other kettle of fish, I think. At
that point, you're throwing yourself on the mercy of uncoordinated
third-party dependency information that conflicts with the official
one, and the dpkg/apt-get system should not be held responsible for
that.
> FreeBSD is different in that regard. The ports system is one of the things
> that makes it great. Being able to choose whether to compile everything,
> compile some ports and use official packages (or non-official repos) for
> others, or entirely to use pre-built binaries is one of the great strengths
> of FreeBSD and is one of the features that distinguishes it from most
> flavors of GNU/Linux. There are even tools for creating repos fairly easily.
> Have you ever tried to write a spec file for an RPM based distro? Ugh!
> Unfortunately, dpkg is not designed for people in those first two categories
> above. It can be made to work, but requires much more effort. Add in systemd
> and the nightmare continues...
Interestingly, my experience -- after having been an admin for 70+
FreeBSD boxes for a 50K+ ISP user base for 12 years -- is different.
It is the apt-get system that has never failed me, and it is FreeBSD
that has regularly left me with a software installation so wrecked
that I had to deinstall every third party package and start over, or
spending hours scripting a search-and-destroy mission to clean up the
mess. When people with significant FreeBSD experience regularly
recommend the "nuke it from orbit" remedy regularly to people in the
forums, that's a sign that something is deeply wrong.
My Linux/dpkg/apt-get experience is entirely different. I have pushed
dpkg-based systems through three major OS/ABI upgrades with one or two
commands, almost without having to perform any manual steps at all --
and when I did, someone had captured them as part of the package
system, informed me about it up front in the release notes, and almost
always empowered me to run a simple package command to do what needed
to be done automatically. To be clear, this is not "hey, the default
version of perl has changed, please do one of these five things, and
if they don't work, delete everything and start over"
/usr/ports/UPDATING equivalent. These were genuinely deep things that
justifiably required a human to decide which way they wanted to go.
And there was no ambiguity in the official documentation about which
commands I needed to run -- because there was a single, official
method included in the base OS.
Managing software across FreeBSD OS upgrades, by contrast, is replete
with manual software removal and reinstallation steps, hunting down
old library dependencies, etc. Recurring "nuke it from orbit"
debacles, coupled with the necessity of /usr/ports/UPDATING, makes the
ports system an order of magnitude less reliable than stock
Debian/Ubuntu ports. This upgrade/management friction makes me far
less likely to want to try to upgrade a FreeBSD system, which, in
turn, when faced with a new install of some kind, makes me far more
likely to use and recommend Ubuntu server over FreeBSD. This pains me
greatly, as I have been a FreeBSD advocate/fan for fifteen years, and
I believe that FreeBSD's tightly integrated kernel/userland/docs has
the potential to be far superior.
In the meantime, we keep reinventing the wheel. And each time,
/usr/ports/UPDATING survives. And each time, the list of possible
software management tools grows, such that each of them has to be
mentioned in /usr/ports/UPDATING. This is another sign that something
is deeply wrong. Any software management solution that does not kill
/usr/ports/UPDATING forever is insufficient.
There are other deep requirements of a software management tool suite
so compelling that it would make all others obsolete. Those
requirements should gathered and sponsored in an official way, instead
of being developed by heroes in a vacuum.
> This discussion is aimed at people who prefer to compile at least some of
> their own binaries, else they wouldn't need Portmaster or Synth or poudriere
> or portupgrade. Really and truly, and with due respect, speaking about dpkg
> is really a diversion, unintentional as it may be, and detracts from your
> main point about a totally unified package/ports system, which you believe
> belongs in base. I don't entirely disagree with that, but having choices
> about what wraps around pkg(8) should be up to the user. I use poudriere.
> For my purposes it's the best available tool. Even if you have half a dozen
> jails on one box poudriere + pkg makes distributing binaries to those jails
> a joy. Synth might do the same. Portmaster might be satisfactory for
> building a small number of ports in a system that mostly uses official
> packages. Portupgrade, if you can live with the ruby dependency and the
> occasional risk that it will crap out when upgrading a dependency, still
> works well for solitary systems using only ports. My point is that the main
> tool is there. It's pkg(8). It does a _reasonably_ good job of sussing out
> what's necessary, installing only run dependencies, and avoiding "dependency
> hell". For people who use only official packages I'd daresay it's superior
> to apt-get. Can it be improved? Yes. I have a wishlist in fact. However,
> it's a young tool that really is excellent, especially compared to what was
> (not) present previously. What tools, if any, a user chooses to employ
> around pkg is up to that user. On Debian and Ubuntu I need both apt-* tools
> and aptitude. On FreeBSD I currently use poudriere. Others only need pkg
> itself.
I have no disagreement with most of this. pkg is, indeed, a big move
in the right direction.
I do believe that the fact that different tools are needed for
different types and counts of deployment is also a sign that something
is wrong.
> In my use case, I compile everything myself because I like to customize
> options and there also may be a slight control issue there as well. ;) I use
> poudriere and maintain different repos for different options. Just the other
> day I spun up a new one for the yet to committed PHP 7.0 ports. It took a
> couple of minutes to do, though compiling some of the modules was an effort
> - separate issue. I created a jail, added that repo, installed php70, and
> was ready to test. To do that on Debian would probably have been a lot more
> effort, though I imagine someone has a repo out there with packages, if I
> wanted to use someone else's packages...
This is, indeed, a gap in the Debian world. It's one that the ports
system is a great start towards resolving. That's why I think that
ports + pkg could be a superior offering that people would flock to,
and which deserves more focus.
>>> Synth is a binary. There's no POLA there.
>>
>> If there were no ports system, and everything was package-driven, I'd
>> agree. Synth and its cousins exist because people work from ports --
>> which means that dependencies matter.
>> permeates FreeBSD is exactly what's wrong. The fact that half of the
>> documentation and quasi-official tools tell people "hey, use one of
>> these three ports management tools, or maybe packages, pick what works
>> for you -- oh, and be sure to check /usr/ports/UPDATING every time you
>> touch any port or package" is a deep symptom of this fragmentation.
>>
>> As long as the ports system exists (and I think it should!), the
>> management of compilation requirements -- especially for something
>> that might need to be bootstrapped early, like a software management
>> tool -- is a valid topic.
>>
>> To be clear: except for the Ada/ruby/whatever dependency chain, my
>> beef isn't with Synth qua Synth. It's that every time we spin up Yet
>> Another Optional Software Management Tool, we fragment further. If
>> Synth becomes the holy grail of package management -- so compelling
>> that it becomes the only choice people would want to make, which is
>> what I think we need -- then it should become part of base.
>>
>> If that happened, would we want to ship with Ada in base? If not, why
>> not?
>
> This is a good point. I still don't understand why pkg(8) is not in the base
> (though I imagine there's a reason and it takes less than a minute to
> install). There can't be many users who install a base system and use it
> without a single additional piece of software. However, for my $0.02, that
> is the only change I'd make to base at this point with respect to package
> management, aside from my pkg(8) wishlist. As an aside, and fwiw, unless
> there is a non-GPL'd Ada compiler out there, we won't see Ada or any
> Ada-based binaries in base, even if Synth turns out to be the best thing
> since sliced bread.
Agreed. And Matthew Seaman's point downthread that pkg is still young
and could, indeed, end up in base one day is an important one.
Jim, thanks for the thoughtful reply ... including the parts where we disagree!
> "Never argue with a fool, onlookers may not be able to tell the difference."
> - Mark Twain
I'm sure this is how John's feeling about me right now. ;)
Royce
> On 2/11/16 7:22 PM, Royce Williams wrote:
>> Is the abstraction is happening at the equivalent level here? The
>> platforms that I'm thinking of -- that appear to have already solved
>> this entire class of problem long ago -- feature wrappers around
>> apt-get, not wrappers around dpkg.
>>
>> I'm advocating that we stop quasi-providing four different flavors of
>> apt-get. Until there is a single and official mechanism for both
>> dependency resolution and configuration option management, the
>> fragmentation remains.
>
> Sadly, I also use dpkg-based systems, not my first choice, but because
>> I'm advocating that we stop quasi-providing four different flavors of
>> apt-get. Until there is a single and official mechanism for both
>> dependency resolution and configuration option management, the
>> fragmentation remains.
>
> sometimes they're the best currently available tool for the job at hand. I'd
> need about thirty hands to use my fingers to count how many times apt-get
> has left me with a broken package system, though aptitude usually is able to
> fix that. Most often that has happened after adding a third party repo (it
> happened recently with using MariDB's own repo instead of the official
> package) or when compiling from source and trying to delete unnecessary
> cruft. The biggest drawback to those systems is that compiling software and
> registering it can be a pain in the ass. The second biggest problem is those
> systems (Debian and Ubuntu specifically) are built around users who are
> totally willing to have the developers choose which options will be compiled
> in to "official" and "non-official" repos. That is, people who compile their
> own binaries are really an afterthought in the Debian and Ubuntu world. Some
> might call that a strength, and yes, dpkg is a nice system for people who
> want that kind of thing. It's made Debian based systems very popular, no
> doubt about it.
Third-party repos are an entirely other kettle of fish, I think. At
that point, you're throwing yourself on the mercy of uncoordinated
third-party dependency information that conflicts with the official
one, and the dpkg/apt-get system should not be held responsible for
that.
> FreeBSD is different in that regard. The ports system is one of the things
> that makes it great. Being able to choose whether to compile everything,
> compile some ports and use official packages (or non-official repos) for
> others, or entirely to use pre-built binaries is one of the great strengths
> of FreeBSD and is one of the features that distinguishes it from most
> flavors of GNU/Linux. There are even tools for creating repos fairly easily.
> Have you ever tried to write a spec file for an RPM based distro? Ugh!
> Unfortunately, dpkg is not designed for people in those first two categories
> above. It can be made to work, but requires much more effort. Add in systemd
> and the nightmare continues...
Interestingly, my experience -- after having been an admin for 70+
FreeBSD boxes for a 50K+ ISP user base for 12 years -- is different.
It is the apt-get system that has never failed me, and it is FreeBSD
that has regularly left me with a software installation so wrecked
that I had to deinstall every third party package and start over, or
spending hours scripting a search-and-destroy mission to clean up the
mess. When people with significant FreeBSD experience regularly
recommend the "nuke it from orbit" remedy regularly to people in the
forums, that's a sign that something is deeply wrong.
My Linux/dpkg/apt-get experience is entirely different. I have pushed
dpkg-based systems through three major OS/ABI upgrades with one or two
commands, almost without having to perform any manual steps at all --
and when I did, someone had captured them as part of the package
system, informed me about it up front in the release notes, and almost
always empowered me to run a simple package command to do what needed
to be done automatically. To be clear, this is not "hey, the default
version of perl has changed, please do one of these five things, and
if they don't work, delete everything and start over"
/usr/ports/UPDATING equivalent. These were genuinely deep things that
justifiably required a human to decide which way they wanted to go.
And there was no ambiguity in the official documentation about which
commands I needed to run -- because there was a single, official
method included in the base OS.
Managing software across FreeBSD OS upgrades, by contrast, is replete
with manual software removal and reinstallation steps, hunting down
old library dependencies, etc. Recurring "nuke it from orbit"
debacles, coupled with the necessity of /usr/ports/UPDATING, makes the
ports system an order of magnitude less reliable than stock
Debian/Ubuntu ports. This upgrade/management friction makes me far
less likely to want to try to upgrade a FreeBSD system, which, in
turn, when faced with a new install of some kind, makes me far more
likely to use and recommend Ubuntu server over FreeBSD. This pains me
greatly, as I have been a FreeBSD advocate/fan for fifteen years, and
I believe that FreeBSD's tightly integrated kernel/userland/docs has
the potential to be far superior.
In the meantime, we keep reinventing the wheel. And each time,
/usr/ports/UPDATING survives. And each time, the list of possible
software management tools grows, such that each of them has to be
mentioned in /usr/ports/UPDATING. This is another sign that something
is deeply wrong. Any software management solution that does not kill
/usr/ports/UPDATING forever is insufficient.
There are other deep requirements of a software management tool suite
so compelling that it would make all others obsolete. Those
requirements should gathered and sponsored in an official way, instead
of being developed by heroes in a vacuum.
> This discussion is aimed at people who prefer to compile at least some of
> their own binaries, else they wouldn't need Portmaster or Synth or poudriere
> or portupgrade. Really and truly, and with due respect, speaking about dpkg
> is really a diversion, unintentional as it may be, and detracts from your
> main point about a totally unified package/ports system, which you believe
> belongs in base. I don't entirely disagree with that, but having choices
> about what wraps around pkg(8) should be up to the user. I use poudriere.
> For my purposes it's the best available tool. Even if you have half a dozen
> jails on one box poudriere + pkg makes distributing binaries to those jails
> a joy. Synth might do the same. Portmaster might be satisfactory for
> building a small number of ports in a system that mostly uses official
> packages. Portupgrade, if you can live with the ruby dependency and the
> occasional risk that it will crap out when upgrading a dependency, still
> works well for solitary systems using only ports. My point is that the main
> tool is there. It's pkg(8). It does a _reasonably_ good job of sussing out
> what's necessary, installing only run dependencies, and avoiding "dependency
> hell". For people who use only official packages I'd daresay it's superior
> to apt-get. Can it be improved? Yes. I have a wishlist in fact. However,
> it's a young tool that really is excellent, especially compared to what was
> (not) present previously. What tools, if any, a user chooses to employ
> around pkg is up to that user. On Debian and Ubuntu I need both apt-* tools
> and aptitude. On FreeBSD I currently use poudriere. Others only need pkg
> itself.
I have no disagreement with most of this. pkg is, indeed, a big move
in the right direction.
I do believe that the fact that different tools are needed for
different types and counts of deployment is also a sign that something
is wrong.
> In my use case, I compile everything myself because I like to customize
> options and there also may be a slight control issue there as well. ;) I use
> poudriere and maintain different repos for different options. Just the other
> day I spun up a new one for the yet to committed PHP 7.0 ports. It took a
> couple of minutes to do, though compiling some of the modules was an effort
> - separate issue. I created a jail, added that repo, installed php70, and
> was ready to test. To do that on Debian would probably have been a lot more
> effort, though I imagine someone has a repo out there with packages, if I
> wanted to use someone else's packages...
This is, indeed, a gap in the Debian world. It's one that the ports
system is a great start towards resolving. That's why I think that
ports + pkg could be a superior offering that people would flock to,
and which deserves more focus.
>>> Synth is a binary. There's no POLA there.
>>
>> agree. Synth and its cousins exist because people work from ports --
>> which means that dependencies matter.
>>
>>> There's no requirement to build from ports, that's an unsubstanciated
>>> invention. Notice that not a single person could defend that position
>>> after a challenge. There's no technical basis for it; it's just
>>> emotional.
>>
>> The laissez-faire "there's no requirement to build from ports" that
>>> There's no requirement to build from ports, that's an unsubstanciated
>>> invention. Notice that not a single person could defend that position
>>> after a challenge. There's no technical basis for it; it's just
>>> emotional.
>>
>> permeates FreeBSD is exactly what's wrong. The fact that half of the
>> documentation and quasi-official tools tell people "hey, use one of
>> these three ports management tools, or maybe packages, pick what works
>> for you -- oh, and be sure to check /usr/ports/UPDATING every time you
>> touch any port or package" is a deep symptom of this fragmentation.
>>
>>> In a straight fly-off against any of the tools, Synth wins hands down
>>> with any objective measurement. Poudriere is slightly more bulletproof
>>> and more appropriate for a cluster (as it was targetted at) but for
>>> average user Synth is better suited.
>>>
>>> It's a concurrent builder. Ada is a concurrent language. How is its
>>> suitability even a debate?
>>
>> Because FreeBSD software management itself is not purely package based.
>>> In a straight fly-off against any of the tools, Synth wins hands down
>>> with any objective measurement. Poudriere is slightly more bulletproof
>>> and more appropriate for a cluster (as it was targetted at) but for
>>> average user Synth is better suited.
>>>
>>> It's a concurrent builder. Ada is a concurrent language. How is its
>>> suitability even a debate?
>>
>>
>> As long as the ports system exists (and I think it should!), the
>> management of compilation requirements -- especially for something
>> that might need to be bootstrapped early, like a software management
>> tool -- is a valid topic.
>>
>> To be clear: except for the Ada/ruby/whatever dependency chain, my
>> beef isn't with Synth qua Synth. It's that every time we spin up Yet
>> Another Optional Software Management Tool, we fragment further. If
>> Synth becomes the holy grail of package management -- so compelling
>> that it becomes the only choice people would want to make, which is
>> what I think we need -- then it should become part of base.
>>
>> If that happened, would we want to ship with Ada in base? If not, why
>> not?
>
> This is a good point. I still don't understand why pkg(8) is not in the base
> (though I imagine there's a reason and it takes less than a minute to
> install). There can't be many users who install a base system and use it
> without a single additional piece of software. However, for my $0.02, that
> is the only change I'd make to base at this point with respect to package
> management, aside from my pkg(8) wishlist. As an aside, and fwiw, unless
> there is a non-GPL'd Ada compiler out there, we won't see Ada or any
> Ada-based binaries in base, even if Synth turns out to be the best thing
> since sliced bread.
Agreed. And Matthew Seaman's point downthread that pkg is still young
and could, indeed, end up in base one day is an important one.
Jim, thanks for the thoughtful reply ... including the parts where we disagree!
> "Never argue with a fool, onlookers may not be able to tell the difference."
> - Mark Twain
I'm sure this is how John's feeling about me right now. ;)
Royce
Kevin Oberman
Feb 14, 2016, 12:58:49 PM2/14/16
to
On Sun, Feb 14, 2016 at 3:37 AM, Steven Hartland <kil...@multiplay.co.uk>
wrote:
> On 14/02/2016 11:25, Michelle Sullivan wrote:
>
>> Kevin Oberman wrote:
>>
>>> My experience is that pkg(8) has been wonderfully robust since 1.3.
>>> before
>>> 1.3 it was a real pain in the neck, though I never had a need to rebuild
>>> the DB, I did ave to do a bit of fix-up. I really, really wish Bapt had
>>> listened and held up the default to pkg for a bit. Much as I like it, it
>>> really was not ready for prime time when it became the default. The early
>>> issues chased too many people away. E.g. you.
>>>
>>>
>> Nailed it!
>>
> The problem with that is its a chicken and egg situation, without it
> hitting prime time it likely wouldn't have got the needed use to identify
> and subsequently fix the issues you're referring to; at the very least it
> would have slowed that process down :(
>
> Regards
> Steve
>
Sorry, but I'm afraid not.
There was spirited discussion at the time about the weaknesses and problems
with pkg. It finally came to a head over portmaster. Its author and
maintainer refused to put revisions to support pkg(8) because he felt
strongly that issues with it had to be dealt with first.
To be clear, I was one of those who wanted more development before making
pkg the default. I really, really wanted pkg to help me deal with issues at
work with maintaining FreeBSD that led to its replacement with Linux. As
much as I wanted pkg, it seemed clear to me that it needed more work.
Obviously, I was not on the winning side and there is no going back now
that pkg has become a stable and robust tool that was critical to the
growth of FreeBSD.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkob...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
wrote:
> On 14/02/2016 11:25, Michelle Sullivan wrote:
>
>> Kevin Oberman wrote:
>>
>>> My experience is that pkg(8) has been wonderfully robust since 1.3.
>>> before
>>> 1.3 it was a real pain in the neck, though I never had a need to rebuild
>>> the DB, I did ave to do a bit of fix-up. I really, really wish Bapt had
>>> listened and held up the default to pkg for a bit. Much as I like it, it
>>> really was not ready for prime time when it became the default. The early
>>> issues chased too many people away. E.g. you.
>>>
>>>
>> Nailed it!
>>
> The problem with that is its a chicken and egg situation, without it
> hitting prime time it likely wouldn't have got the needed use to identify
> and subsequently fix the issues you're referring to; at the very least it
> would have slowed that process down :(
>
> Regards
> Steve
>
Sorry, but I'm afraid not.
There was spirited discussion at the time about the weaknesses and problems
with pkg. It finally came to a head over portmaster. Its author and
maintainer refused to put revisions to support pkg(8) because he felt
strongly that issues with it had to be dealt with first.
To be clear, I was one of those who wanted more development before making
pkg the default. I really, really wanted pkg to help me deal with issues at
work with maintaining FreeBSD that led to its replacement with Linux. As
much as I wanted pkg, it seemed clear to me that it needed more work.
Obviously, I was not on the winning side and there is no going back now
that pkg has become a stable and robust tool that was critical to the
growth of FreeBSD.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkob...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
John Marino
Feb 15, 2016, 12:53:25 PM2/15/16
to
On 2/15/2016 6:31 PM, Michelle Sullivan wrote:
> Actually it made perfect sense... (for a change) ... make pkgng the
> default on 10.x and allow people to use either on 8.4 and 9.x ... this
> made perfect sense... Make base packaging using similar/same tools as
> part of 11+ makes perfect sense...
It might make sense if you had zero knowledge of how ports are developed
and made the assumption they are synchronized to three base branches.
They aren't.
One ports tree, developed independently.
> ....No, though... arbitrary date set, f**k real users, f**k whether it
> works or not, because we need people to put it in production so we can
> test our buggy software...
Even with asterisks, I'm not happy with swear words like this on a mail
list. Can we keep it cleaner?
> Line drawn - at the next major version... that's an easy win... people
> can complain, but they can't argue that it isn't a good decision because
> they can choose... upgrade/don't upgrade... we didn't get the chance to
> choose ... it was forced down peoples necks... working or not.
> Fortunately I was able to get the old system working again... and in
> fact keep it up to date until about 3 months ago... (and only stopped
> there because I have other things to do - will go back to it again later.)
See above, ports isn't tied to base releases and never has been AFAIK.
There were technical options to extend the time, the simplest being:
Don't update the ports tree!
Bring in security updates manually is a lot easier than migrating 50
servers and it's not that big a deal for a few months, and as I said, I
am sure your organisation could have paid a reasonable amount for
somebody to do it for you.
> Well I didn't know - despite following the conversations on the public
> lists - until 3 weeks before the event that the change was going to
> deliberately and irrevocably break the old systems... again...
As I said, I sympathize, but are you really going to point the fingers
at others before yourself here?
> Dunno about Roger, but I am and I had been campaigning internally about
> getting support for FreeBSD as a platform and support for the foundation
> in the way of devs and/or cash... that is *never* going to happen now.
> Money has been allocated and sent to Redhat (nothing to do with me, but
> the pkgng debacle left me without legs to argue the case, so the
> decision makers stuffed that.)
And the next linux-related fiasco experiences can be traced back to a
rash and technically questionable decision by all involved. Good luck I
guess. And what was the cost of the transition and what will be the TCO
over the next 10 years? None of that money would have been better spent
on the encumbent system. That's really hard to believe.
> That I can't (and won't) comment on, but I will tell you that's the
> reason all new servers I manage are being installed with CentOS+paid
> support contract and not FreeBSD+donation. The bed was made by people,
> they can sleep in it.
And you probably spent magnitudes more than just getting a consultant to
help for a few months for a few hours a month. It's easy to say
foundation would have gotten money but harder to believe if they never
got a donation in the past when everything was working okay, right?
John
> Actually it made perfect sense... (for a change) ... make pkgng the
> default on 10.x and allow people to use either on 8.4 and 9.x ... this
> made perfect sense... Make base packaging using similar/same tools as
> part of 11+ makes perfect sense...
It might make sense if you had zero knowledge of how ports are developed
and made the assumption they are synchronized to three base branches.
They aren't.
One ports tree, developed independently.
> ....No, though... arbitrary date set, f**k real users, f**k whether it
> works or not, because we need people to put it in production so we can
> test our buggy software...
Even with asterisks, I'm not happy with swear words like this on a mail
list. Can we keep it cleaner?
> Line drawn - at the next major version... that's an easy win... people
> can complain, but they can't argue that it isn't a good decision because
> they can choose... upgrade/don't upgrade... we didn't get the chance to
> choose ... it was forced down peoples necks... working or not.
> Fortunately I was able to get the old system working again... and in
> fact keep it up to date until about 3 months ago... (and only stopped
> there because I have other things to do - will go back to it again later.)
See above, ports isn't tied to base releases and never has been AFAIK.
There were technical options to extend the time, the simplest being:
Don't update the ports tree!
Bring in security updates manually is a lot easier than migrating 50
servers and it's not that big a deal for a few months, and as I said, I
am sure your organisation could have paid a reasonable amount for
somebody to do it for you.
> Well I didn't know - despite following the conversations on the public
> lists - until 3 weeks before the event that the change was going to
> deliberately and irrevocably break the old systems... again...
As I said, I sympathize, but are you really going to point the fingers
at others before yourself here?
> Dunno about Roger, but I am and I had been campaigning internally about
> getting support for FreeBSD as a platform and support for the foundation
> in the way of devs and/or cash... that is *never* going to happen now.
> Money has been allocated and sent to Redhat (nothing to do with me, but
> the pkgng debacle left me without legs to argue the case, so the
> decision makers stuffed that.)
And the next linux-related fiasco experiences can be traced back to a
rash and technically questionable decision by all involved. Good luck I
guess. And what was the cost of the transition and what will be the TCO
over the next 10 years? None of that money would have been better spent
on the encumbent system. That's really hard to believe.
> That I can't (and won't) comment on, but I will tell you that's the
> reason all new servers I manage are being installed with CentOS+paid
> support contract and not FreeBSD+donation. The bed was made by people,
> they can sleep in it.
And you probably spent magnitudes more than just getting a consultant to
help for a few months for a few hours a month. It's easy to say
foundation would have gotten money but harder to believe if they never
got a donation in the past when everything was working okay, right?
John
dr.k...@gmx.at
Feb 15, 2016, 12:55:32 PM2/15/16
to
Am Montag, 15. Februar 2016 schrieb Roger Marquis:
> There are lots of reasons why Linux has effectively eclipsed BSD
> including device drivers, unattended deployments and install menus but
> 8.X's wholesale throwing of so many of us under the bus was by far the
> worst.
Well, have you experience with "systemd"? That's the Linux nemesis that drives people to *BSD - including me.
Nik
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> There are lots of reasons why Linux has effectively eclipsed BSD
> including device drivers, unattended deployments and install menus but
> 8.X's wholesale throwing of so many of us under the bus was by far the
> worst.
Well, have you experience with "systemd"? That's the Linux nemesis that drives people to *BSD - including me.
Nik
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
Michelle Sullivan
Feb 15, 2016, 3:40:31 PM2/15/16
to
John Marino wrote:
> On 2/15/2016 6:32 PM, Roger Marquis wrote:
>
>>> This makes no sense. Ports are not tied to base releases.
>>> And you think lack of developer resources is an invalid reason?
>>>
>> There was no mid-release issue with base as far as I know. The issue was
>> with ports and by extension pkgng (and related -ngs).
>>
>
> ports are developed independently. They do not follow release
> schedules. Ports have to support all supported releases, that's the
> only connection.
>
Yeah, I'd agree with this... except...
pkg_* tools don't exist on 10.x only pkgng... that makes it base os
thing.. even if it's downloaded in/via ports..
So sorry don't claim it's only part of the ports system, because whilst
it maybe built and administered there, the tools it replaced were
removed from the base OS at the very beginning of 10.x...
Michelle
--
Michelle Sullivan
http://www.mhix.org/
> On 2/15/2016 6:32 PM, Roger Marquis wrote:
>
>>> This makes no sense. Ports are not tied to base releases.
>>> And you think lack of developer resources is an invalid reason?
>>>
>> There was no mid-release issue with base as far as I know. The issue was
>> with ports and by extension pkgng (and related -ngs).
>>
>
> ports are developed independently. They do not follow release
> schedules. Ports have to support all supported releases, that's the
> only connection.
>
Yeah, I'd agree with this... except...
pkg_* tools don't exist on 10.x only pkgng... that makes it base os
thing.. even if it's downloaded in/via ports..
So sorry don't claim it's only part of the ports system, because whilst
it maybe built and administered there, the tools it replaced were
removed from the base OS at the very beginning of 10.x...
Michelle
--
Michelle Sullivan
http://www.mhix.org/
Michelle Sullivan
Feb 15, 2016, 6:45:12 PM2/15/16
to
John Marino wrote:
> 10.x?
Which port, I wasn't even aware the pkg_* tools where there? Not
forgetting they wouldn't actually work because the ports tree actively
installs and uses pkg (no matter what options you have) so you're
screwed regardless.
> You're just talking about them being removed from base, but you
> weren't prohibited from using the tools until they were removed from the
> ports tree (and then you could have just frozen the tree while they were
> still present)
>
Nice idea except there were a slew of vulnerabilities (notable openssl
IIRC) which had to be patched... and IIRC it wasn't even back ported to
the quarterly.. I know I asked for several patches to be put into the
quarterly and they never were (and one of those patches was on a port I
maintained.)
> Plus now you're in a weird place where you can freely migrate to the
> latest release (10.x) but can't freely migrate package tools?
>
Sorry?
pre 8.4 pkg_* only.
8.4 + 9.x pkg_* or pkgng - user choice.
10.x pkgng only.
Seems to be a good path to get people to switch without the pain.
> Michelle, it's seriously very weak to say ports are tied to releases
> because something moved out of base. Stuff moves out of base all the
> time (and actually not fast enough).
>
Wasn't the point I was making, but people will jump on that to give
weight to their argument. I was supporting someone else's notion that
it would have been a lot more sensible and painless had it been done ...
(eg like I suggested above) ... however it wasn't.. arbitrary date
set... That said, you cannot deny.. 10.x didn't have working pkg_*
tools (as in usable - because bapt (and others) made sure there were so
many version checks so if you were on 10.x the ports tree would not use
pkg_* tools even if you went to the source and compiled them like I
did... seems to me like they had already chosen to go the way I
suggested above, but too many people stayed clear of 10.0 so they forced
the issue on everyone else... Here's the fact: I run configure and my
systems, not some random wheeny that wants me to debug their software.
I know the 'wheeny' is friends with people on here.. and a lot more
respected by many than I ever will be when it comes to this mailing
list, but I really don't care, I say it how it is, you may agree or
disagree with me, I will respect you if you do, however you will never
change my mind nor will I just shut up and go away whilst I have a
single box affected (which means until they are all migrated.)
> On 2/15/2016 9:40 PM, Michelle Sullivan wrote:
>
>> Yeah, I'd agree with this... except...
>>
>> pkg_* tools don't exist on 10.x only pkgng... that makes it base os
>> thing.. even if it's downloaded in/via ports..
>>
>> So sorry don't claim it's only part of the ports system, because whilst
>> it maybe built and administered there, the tools it replaced were
>> removed from the base OS at the very beginning of 10.x...
>>
>
> What stopped you from installing pkg_* tools from the ports tree on
>
>> Yeah, I'd agree with this... except...
>>
>> pkg_* tools don't exist on 10.x only pkgng... that makes it base os
>> thing.. even if it's downloaded in/via ports..
>>
>> So sorry don't claim it's only part of the ports system, because whilst
>> it maybe built and administered there, the tools it replaced were
>> removed from the base OS at the very beginning of 10.x...
>>
>
> 10.x?
Which port, I wasn't even aware the pkg_* tools where there? Not
forgetting they wouldn't actually work because the ports tree actively
installs and uses pkg (no matter what options you have) so you're
screwed regardless.
> You're just talking about them being removed from base, but you
> weren't prohibited from using the tools until they were removed from the
> ports tree (and then you could have just frozen the tree while they were
> still present)
>
Nice idea except there were a slew of vulnerabilities (notable openssl
IIRC) which had to be patched... and IIRC it wasn't even back ported to
the quarterly.. I know I asked for several patches to be put into the
quarterly and they never were (and one of those patches was on a port I
maintained.)
> Plus now you're in a weird place where you can freely migrate to the
> latest release (10.x) but can't freely migrate package tools?
>
Sorry?
pre 8.4 pkg_* only.
8.4 + 9.x pkg_* or pkgng - user choice.
10.x pkgng only.
Seems to be a good path to get people to switch without the pain.
> Michelle, it's seriously very weak to say ports are tied to releases
> because something moved out of base. Stuff moves out of base all the
> time (and actually not fast enough).
>
Wasn't the point I was making, but people will jump on that to give
weight to their argument. I was supporting someone else's notion that
it would have been a lot more sensible and painless had it been done ...
(eg like I suggested above) ... however it wasn't.. arbitrary date
set... That said, you cannot deny.. 10.x didn't have working pkg_*
tools (as in usable - because bapt (and others) made sure there were so
many version checks so if you were on 10.x the ports tree would not use
pkg_* tools even if you went to the source and compiled them like I
did... seems to me like they had already chosen to go the way I
suggested above, but too many people stayed clear of 10.0 so they forced
the issue on everyone else... Here's the fact: I run configure and my
systems, not some random wheeny that wants me to debug their software.
I know the 'wheeny' is friends with people on here.. and a lot more
respected by many than I ever will be when it comes to this mailing
list, but I really don't care, I say it how it is, you may agree or
disagree with me, I will respect you if you do, however you will never
change my mind nor will I just shut up and go away whilst I have a
single box affected (which means until they are all migrated.)
Baho Utot
Feb 15, 2016, 6:48:40 PM2/15/16
to
Michelle Sullivan wrote:
> John Marino wrote:
>> On 2/15/2016 5:59 PM, Roger Marquis wrote:
> John Marino wrote:
>>
>>> It was actually worse than that. Those of us who questioned the wisdom
>>> of such disruptive and backwards-incompatible changes being implemented
>>> mid-release instead of at a release boundry were A) ignored, B) told that
>>> there were not enough (developer) resources, and C) even the announcement
>>> was unprofessional and lacked justification for the rush job:
>>>
>> This makes no sense. Ports are not tied to base releases.
>> And you think lack of developer resources is an invalid reason?
>>
>> This makes no sense. Ports are not tied to base releases.
>> And you think lack of developer resources is an invalid reason?
>>
> Actually it made perfect sense... (for a change) ... make pkgng the
> default on 10.x and allow people to use either on 8.4 and 9.x ... this
> made perfect sense... Make base packaging using similar/same tools as
> part of 11+ makes perfect sense...
>
>
> default on 10.x and allow people to use either on 8.4 and 9.x ... this
> made perfect sense... Make base packaging using similar/same tools as
> part of 11+ makes perfect sense...
>
>
> ....No, though... arbitrary date set, f**k real users, f**k whether it
> works or not, because we need people to put it in production so we can
> test our buggy software...
>
>>
>>> There comes a time in the life cycle of just about every software
> works or not, because we need people to put it in production so we can
> test our buggy software...
>
>>
>>> package that it has bee re-evaluated, refreshed, deprecated or just
>>> retired.
>>>
>>> It is time that we bid farewell to the old pkg_* software that has been
>>> part of FreeBSD since the beginning, and has served us well. After
>>> years of development, testing, and playing, pkg(8) has become a
>>> suitable replacement.
>>>
>>> "there comes a time"? "time that we bid farewell"? These are not
>>> suitable criteria IMO for dropping support of mission-critical
>>> subsystems. The FreeBSD Foundation SHOULD have played a part in insuring
>>> a smoother transition to pkgng (much less portsng and, gack, rcng) but
>>> this doesn't seem to have been on their radar.
>>>
>> You know good and well that people kick the can down the road FOREVER.
>> You could have announced it 3 years ahead and people would still scream
>> NOT YET! NOT YET! This would NEVER happen in Linux!
>>
>> It doesn't matter where you draw the line, you will never get everyone
>> to respect it. It's never enough time.
>>
> Line drawn - at the next major version... that's an easy win... people
> can complain, but they can't argue that it isn't a good decision because
> they can choose... upgrade/don't upgrade... we didn't get the chance to
> choose ... it was forced down peoples necks... working or not.
> Fortunately I was able to get the old system working again... and in
> fact keep it up to date until about 3 months ago... (and only stopped
> there because I have other things to do - will go back to it again later.)
>
>>>> From my perspective as an advocate and long-time user (since 2.0.5) this
> Line drawn - at the next major version... that's an easy win... people
> can complain, but they can't argue that it isn't a good decision because
> they can choose... upgrade/don't upgrade... we didn't get the chance to
> choose ... it was forced down peoples necks... working or not.
> Fortunately I was able to get the old system working again... and in
> fact keep it up to date until about 3 months ago... (and only stopped
> there because I have other things to do - will go back to it again later.)
>
>>>>
>>> marked a low-point in the viability of FreeBSD vis-a-vis other FOSS
>>> distributions. Thankfully, going forward from FreeBSD 11 the release
>>> cycle has been lengthened and base is going to be packaged. Those of use
>>> who support large numbers of dev and production systems can at least
>>> expect that future upgrades won't be as time-consuming or, hopefully, as
>>> buggy.
>>>
>> "large numbers of dev and production systems" (push to memory stack)
>>
>>
>>
>>
>>> I believe this is factually incorrect. We were aware but the decisions
>>> were being made by core developers who were not, apparently, interested
>>> in our concerns or the expected fallout.
>>>
>> So you chose to ignore the deadlines in the hopes the pleading would
>> work? You intentionally did not prepare against the published timetable?
>>
> Well I didn't know - despite following the conversations on the public
> lists - until 3 weeks before the event that the change was going to
> deliberately and irrevocably break the old systems... again...
>
>>
>>>> There was always the option of freezing the tree and pulling in the
> Well I didn't know - despite following the conversations on the public
> lists - until 3 weeks before the event that the change was going to
> deliberately and irrevocably break the old systems... again...
>
>>
>>>> security updates manually until you were ready to migrate to pkg(8) too.
>>>>
>>> Sure, if you can afford to pay a full-time core dev there's the option of
>>> backporting but even this was made impractical by the simultaneous
>>> deprecation of the pre-ng ports tree, make version and pkg format.
>>>
>> No, it's not fully time. You just said "large numbers of dev and
>> production systems", so I am pretty confident the business case would
>> have been there for this.
>>
>> It's a business, right? You aren't talking about a shoestring hobby.
>>
> Dunno about Roger, but I am and I had been campaigning internally about
> getting support for FreeBSD as a platform and support for the foundation
> in the way of devs and/or cash... that is *never* going to happen now.
> Money has been allocated and sent to Redhat (nothing to do with me, but
> the pkgng debacle left me without legs to argue the case, so the
> decision makers stuffed that.)
>
> Dunno about Roger, but I am and I had been campaigning internally about
> getting support for FreeBSD as a platform and support for the foundation
> in the way of devs and/or cash... that is *never* going to happen now.
> Money has been allocated and sent to Redhat (nothing to do with me, but
> the pkgng debacle left me without legs to argue the case, so the
> decision makers stuffed that.)
>
>>> There are lots of reasons why Linux has effectively eclipsed BSD
>>> including device drivers, unattended deployments and install menus but
>>> 8.X's wholesale throwing of so many of us under the bus was by far the
>>> worst.
>>>
>> And now the fully circle. This is FreeBSD's Godwin's law. You know the
>>> including device drivers, unattended deployments and install menus but
>>> 8.X's wholesale throwing of so many of us under the bus was by far the
>>> worst.
>>>
>> discussion is over when somebody says that "[issue] of the day" is the
>> root cause of BSD being eclipsed by Linux. Since I've heard [issue]
>> replaced about 200 times, I'm kind of doubting it. I guess it's purpose
>> is to make everyone involved with "[issue]" to feel personally
>> responsible and oh what could have been if you hadn't of made the wrong
>> decision....
>>
> That I can't (and won't) comment on, but I will tell you that's the
> reason all new servers I manage are being installed with CentOS+paid
> support contract and not FreeBSD+donation. The bed was made by people,
> they can sleep in it.
>
> Michelle
> That I can't (and won't) comment on, but I will tell you that's the
> reason all new servers I manage are being installed with CentOS+paid
> support contract and not FreeBSD+donation. The bed was made by people,
> they can sleep in it.
>
What time of the month is it?
I seem to of lost my place.
Michelle Sullivan
Feb 15, 2016, 6:59:17 PM2/15/16
to
Jim Ohlstein wrote:
> Hello,
> it you're not going to drink it.
One of the reasons that over the last few months I have been ignoring
most threads on here and IRC... just looking for something I need to
know about only.
>
> If you want to be using a 2014 OS in 2022, then a RHEL derived system
> is the product for you. Enjoy it. I don't believe that there is an
> upgrade path in RHEL, so you'll either have to retire hardware or nuke
> your systems to upgrade.
I don't, I'm forced to now.
>
> No one forced you to use 10.x before you were ready. 9 is still
> supported to this day. And as has been pointed out, pkg_ tools were in
> ports should you have wanted to continue to use them, and you could
> have kept them and frozen your ports tree, as has been pointed out.
I don't have a 10.x box. I do still have 40+ 9.x boxes and a non-frozen
ports tree where i have backported many of the new changes to the old
pkg_* system ... just because in the immortal words "these changes
cannot work with pkg_* tools, we needed to change everything to move
forward." (or something very close to those words.)
>
> Could the pkg(8) roll out have been handled better? Yes!
> Red Hat, which is now your preferred product,
No, it's the product I have to use because that is now company policy.
> is a for-profit company with over 8000 paid employees, many of whom
> are testing and testing and testing. They never update anything except
> at the point of a gun, and then only after extensive testing. On the
> plus side, it's stable. It never really changes. FreeBSD, on the other
> hand, is a comparatively small organization and an operating system
> that moves forward, though sometimes it's two steps forward and one
> back.. Some things need to be tested in the field to find out where
> and what needs to be changed/fixed/improved. That's the way it is. Was
> this an epic fail? That's a matter of opinion, though we all already
> know yours. The fact is that you had choices. You made those choices
> with your eyes open (if you didn't then shame on you!)
I have very little choice because whilst my eyes were open, I missed one
message ... *ONE* message that said (paraphrasing), "as of the EOL date
the old tools will be broken"
> and things didn't go as smoothly as you'd have liked. As I said, it's
> time to move on. Your arguments are specious.
>
>
Your assumptions about me and my motives are very specious. I have
already moved on professionally (as in, in my job) and I replied to this
thread only to let the original poster know there were not alone in
their thoughts or arguments. Others, you included have persisted in
telling me how and why I'm wrong without realising that if I amd wrong
so are you, just as if I am right so are you because I am talking about
my experience, observations and opinion, which are mine and mine alone,
you will keep the argument going whilst ever you deny my observations
and opinions.
> Hello,
>
> On 2/15/16 3:40 PM, Michelle Sullivan wrote:
>> John Marino wrote:
>>> On 2/15/2016 6:32 PM, Roger Marquis wrote:
>>>
>>>>> This makes no sense. Ports are not tied to base releases.
>>>>> And you think lack of developer resources is an invalid reason?
>>>>>
>>>> There was no mid-release issue with base as far as I know. The
>>>> issue was
>>>> with ports and by extension pkgng (and related -ngs).
>>>>
>>>
>>> ports are developed independently. They do not follow release
>>> schedules. Ports have to support all supported releases, that's the
>>> only connection.
>>>
>> Yeah, I'd agree with this... except...
>>
>> pkg_* tools don't exist on 10.x only pkgng... that makes it base os
>> thing.. even if it's downloaded in/via ports..
>>
>> So sorry don't claim it's only part of the ports system, because whilst
>> it maybe built and administered there, the tools it replaced were
>> removed from the base OS at the very beginning of 10.x...
>
> This is like milking a dead cow here. Even if you get something out of
> On 2/15/16 3:40 PM, Michelle Sullivan wrote:
>> John Marino wrote:
>>> On 2/15/2016 6:32 PM, Roger Marquis wrote:
>>>
>>>>> This makes no sense. Ports are not tied to base releases.
>>>>> And you think lack of developer resources is an invalid reason?
>>>>>
>>>> There was no mid-release issue with base as far as I know. The
>>>> issue was
>>>> with ports and by extension pkgng (and related -ngs).
>>>>
>>>
>>> ports are developed independently. They do not follow release
>>> schedules. Ports have to support all supported releases, that's the
>>> only connection.
>>>
>> Yeah, I'd agree with this... except...
>>
>> pkg_* tools don't exist on 10.x only pkgng... that makes it base os
>> thing.. even if it's downloaded in/via ports..
>>
>> So sorry don't claim it's only part of the ports system, because whilst
>> it maybe built and administered there, the tools it replaced were
>> removed from the base OS at the very beginning of 10.x...
>
> it you're not going to drink it.
One of the reasons that over the last few months I have been ignoring
most threads on here and IRC... just looking for something I need to
know about only.
>
> If you want to be using a 2014 OS in 2022, then a RHEL derived system
> is the product for you. Enjoy it. I don't believe that there is an
> upgrade path in RHEL, so you'll either have to retire hardware or nuke
> your systems to upgrade.
I don't, I'm forced to now.
>
> No one forced you to use 10.x before you were ready. 9 is still
> supported to this day. And as has been pointed out, pkg_ tools were in
> ports should you have wanted to continue to use them, and you could
> have kept them and frozen your ports tree, as has been pointed out.
I don't have a 10.x box. I do still have 40+ 9.x boxes and a non-frozen
ports tree where i have backported many of the new changes to the old
pkg_* system ... just because in the immortal words "these changes
cannot work with pkg_* tools, we needed to change everything to move
forward." (or something very close to those words.)
>
> Could the pkg(8) roll out have been handled better? Yes!
> Red Hat, which is now your preferred product,
No, it's the product I have to use because that is now company policy.
> is a for-profit company with over 8000 paid employees, many of whom
> are testing and testing and testing. They never update anything except
> at the point of a gun, and then only after extensive testing. On the
> plus side, it's stable. It never really changes. FreeBSD, on the other
> hand, is a comparatively small organization and an operating system
> that moves forward, though sometimes it's two steps forward and one
> back.. Some things need to be tested in the field to find out where
> and what needs to be changed/fixed/improved. That's the way it is. Was
> this an epic fail? That's a matter of opinion, though we all already
> know yours. The fact is that you had choices. You made those choices
> with your eyes open (if you didn't then shame on you!)
I have very little choice because whilst my eyes were open, I missed one
message ... *ONE* message that said (paraphrasing), "as of the EOL date
the old tools will be broken"
> and things didn't go as smoothly as you'd have liked. As I said, it's
> time to move on. Your arguments are specious.
>
>
Your assumptions about me and my motives are very specious. I have
already moved on professionally (as in, in my job) and I replied to this
thread only to let the original poster know there were not alone in
their thoughts or arguments. Others, you included have persisted in
telling me how and why I'm wrong without realising that if I amd wrong
so are you, just as if I am right so are you because I am talking about
my experience, observations and opinion, which are mine and mine alone,
you will keep the argument going whilst ever you deny my observations
and opinions.
Kevin Oberman
Feb 16, 2016, 2:45:07 PM2/16/16
to
On Tue, Feb 16, 2016 at 7:57 AM, <kpn...@pobox.com> wrote:
> On Mon, Feb 15, 2016 at 06:14:02PM +0100, John Marino wrote:
> > And now the fully circle. This is FreeBSD's Godwin's law. You know the
> > discussion is over when somebody says that "[issue] of the day" is the
> > root cause of BSD being eclipsed by Linux. Since I've heard [issue]
> > replaced about 200 times, I'm kind of doubting it. I guess it's purpose
> > is to make everyone involved with "[issue]" to feel personally
> > responsible and oh what could have been if you hadn't of made the wrong
> > decision....
>
> I was under the impression that what really hurt BSD vs Linux was the
> AT&T vs UCB lawsuit. If that lawsuit hadn't happened Linus would not have
> created Linux. He's said so himself.
> --
> Kevin P. Neal http://www.pobox.com/~kpn/
>
Yes, the license uncertainty of the period is why Linux exists and why it
gained immediate popularity. Inertia can be a wonderful thing.
But that was then and this is now and the popularity of Linux vs. BSD and
of various distributions of them is driven by many factors. Linux has FAR
more developers and has long been able to have support for newer devices
much more quickly than BSD. This has, in turn, fed the growth of Linux.
OTOH, BSD had become rather popular in the embedded systems space. Its
license and strong support for servers and embedded systems has helped. I
think systemd has been a big mistake for Linux and is moving many people to
BSD, even those who had not previously used it. In recent years the distros
seem to be intent on behaving like Windows. I look at the directions of
e.g. Gnome and, to a lesser extent KDE as the result of devs who grew up
with Windows as trying to make their environment more "Windows like". This
is combined with a philosophy that allowing and even encouraging a wide
variety of configuration changes as has traditionally been the norm for all
UNIX-type systems was frightening off too many people.
It is a combination of these and other factors that control the ebb and
flow of OS and distro popularity. I think trying to be popular is best
served by maximizing functionality and usability in general and for
specific purposes. In general, I think FreeBSD is doing a pretty good job
ATM and, while I don't always agree with everything, I think I'll probably
continue using it as my OS of choice. I'll also continue to speak up when I
disagree with the direction. I already see the looming battle over a future
replacement of the init system with something both more functional and
manageable. I think systemd went way too heavily toward "functional" and
ignored the manageable side. I hope FreeBSD does better, especially in
avoiding over-reach.
I see much that I like (and a fair bit I don't) in launchd, for example and
I really need to keep a better eye on what NextBSD is doing. It is
certainly interesting and has some really good people working on it.
> On Mon, Feb 15, 2016 at 06:14:02PM +0100, John Marino wrote:
> > And now the fully circle. This is FreeBSD's Godwin's law. You know the
> > discussion is over when somebody says that "[issue] of the day" is the
> > root cause of BSD being eclipsed by Linux. Since I've heard [issue]
> > replaced about 200 times, I'm kind of doubting it. I guess it's purpose
> > is to make everyone involved with "[issue]" to feel personally
> > responsible and oh what could have been if you hadn't of made the wrong
> > decision....
>
> AT&T vs UCB lawsuit. If that lawsuit hadn't happened Linus would not have
> created Linux. He's said so himself.
> --
> Kevin P. Neal http://www.pobox.com/~kpn/
>
Yes, the license uncertainty of the period is why Linux exists and why it
gained immediate popularity. Inertia can be a wonderful thing.
But that was then and this is now and the popularity of Linux vs. BSD and
of various distributions of them is driven by many factors. Linux has FAR
more developers and has long been able to have support for newer devices
much more quickly than BSD. This has, in turn, fed the growth of Linux.
OTOH, BSD had become rather popular in the embedded systems space. Its
license and strong support for servers and embedded systems has helped. I
think systemd has been a big mistake for Linux and is moving many people to
BSD, even those who had not previously used it. In recent years the distros
seem to be intent on behaving like Windows. I look at the directions of
e.g. Gnome and, to a lesser extent KDE as the result of devs who grew up
with Windows as trying to make their environment more "Windows like". This
is combined with a philosophy that allowing and even encouraging a wide
variety of configuration changes as has traditionally been the norm for all
UNIX-type systems was frightening off too many people.
It is a combination of these and other factors that control the ebb and
flow of OS and distro popularity. I think trying to be popular is best
served by maximizing functionality and usability in general and for
specific purposes. In general, I think FreeBSD is doing a pretty good job
ATM and, while I don't always agree with everything, I think I'll probably
continue using it as my OS of choice. I'll also continue to speak up when I
disagree with the direction. I already see the looming battle over a future
replacement of the init system with something both more functional and
manageable. I think systemd went way too heavily toward "functional" and
ignored the manageable side. I hope FreeBSD does better, especially in
avoiding over-reach.
I see much that I like (and a fair bit I don't) in launchd, for example and
I really need to keep a better eye on what NextBSD is doing. It is
certainly interesting and has some really good people working on it.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkob...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkob...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
0 new messages