BIND REPLACE_BASE option

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mat,

Can you please explain why this option was removed? It's been in the
ports for over 13 years, and lots of users utilized it.

I realize that BIND is no longer in the base in 10.x, but that would
be a reason to make the option conditional, to continue to support the
substantial user base that is still on 8.x and 9.x.

Please cc me on your reply, as I am not subscribed to the list.

Thanks,

Doug
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJUr06JAAoJEFzGhvEaGryE4gAH/3QHW3HDmvgq6sM1yI/c00O/
mMayUGB34TtneYYh1lIZJD7AeNa/rMm3QiFEa7GwgMTrks1DDNZ/JFFKz1/VLnGY
ZvJSNd0F0Hn4zWVoovG+9Vhp9UA15dK2aGjdTdY6rUkXAu+xko8aL7XELOUFHZPa
N4qL2aWbpk2xzYl7lOidfgcazGz/tGU1u33suBpXJqO+v1K8Bl1IvbdXZ65rve1J
+7K7craZBsKJn7KVkhMG1Zzj7rdLIY/Bd5fA3v/Qqmk+AXLVxwFUNX5hRjH50aRj
9bpw3nqdDCt8JoA/o7j2YlB4BFJjxTo7lon5bqB5ppum3yCmdx5M5npR7UNFcQg=
=FeSn
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Mathieu Arnold]

+--On 8 janvier 2015 19:44:09 -0800 Doug Barton  wrote:
| Can you please explain why this option was removed? It's been in the
| ports for over 13 years, and lots of users utilized it.
| 
| I realize that BIND is no longer in the base in 10.x, but that would
| be a reason to make the option conditional, to continue to support the
| substantial user base that is still on 8.x and 9.x.

I only removed it from bind99, it was never there in bind910.  I removed it
because it was a poor design idea to begin with, and it was making the port
harder to maintain.  Also, it was overwriting files in the base system,
which is a thing we do not want to do.

All you need to do is add:

named_program="/usr/local/sbin/named"

to your rc.conf, like the message says when you install the port.

It was a bit like the /usr/bin/perl symlink, it was time for it to go.

-- 
Mathieu Arnold
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[The BSD Dreamer]

On 2015-01-09 07:42, Mathieu Arnold wrote:

+--On 8 janvier 2015 19:44:09 -0800 Doug Barton  wrote:
| Can you please explain why this option was removed? It's been in the
| ports for over 13 years, and lots of users utilized it.
|
| I realize that BIND is no longer in the base in 10.x, but that would
| be a reason to make the option conditional, to continue to support the
| substantial user base that is still on 8.x and 9.x.

I only removed it from bind99, it was never there in bind910.  I removed it
because it was a poor design idea to begin with, and it was making the port
harder to maintain.  Also, it was overwriting files in the base system,
which is a thing we do not want to do.

All you need to do is add:

named_program="/usr/local/sbin/named"

to your rc.conf, like the message says when you install the port.

It was a bit like the /usr/bin/perl symlink, it was time for it to go.


But, it was a huge and sudden pain for it to suddenly disappear and break 
everything...


I can only abandon FreeBSD as our DNS platform as fast as replacement systems 
appear.


Why have we decided that we're going to cease FreeBSD for our DNS servers 
(after I had made such a strong case for FreeBSD?)  Count the PORTREVISIONs 
to bind before 9.9.4 and after.  Plus look at all the other annoying changes 
in those PORTREVISIONs without that things have been working fine for the 
rest of us before.


I should've been home hours ago...if I haven't been stuck dealing with 
bizarre problems caused by updating a bunch of packages.


Now I have update nagios-plugins, since base nslookup is gone.  Does it end?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Julian H. Stacey]

Hi, Reference:
> From: The BSD Dreamer 
> Date: Sat, 10 Jan 2015 21:25:11 -0600

The BSD Dreamer wrote:
> 
> On 2015-01-09 07:42, Mathieu Arnold wrote:
> > +--On 8 janvier 2015 19:44:09 -0800 Doug Barton  wrote:
> > | Can you please explain why this option was removed? It's been in the
> > | ports for over 13 years, and lots of users utilized it.
> > |
> > | I realize that BIND is no longer in the base in 10.x, but that would
> > | be a reason to make the option conditional, to continue to support the
> > | substantial user base that is still on 8.x and 9.x.
> > 
> > I only removed it from bind99, it was never there in bind910.  I removed it
> > because it was a poor design idea to begin with, and it was making the port
> > harder to maintain.  Also, it was overwriting files in the base system,
> > which is a thing we do not want to do.
> > 
> > All you need to do is add:
> > 
> > named_program="/usr/local/sbin/named"
> > 
> > to your rc.conf, like the message says when you install the port.
> > 
> > It was a bit like the /usr/bin/perl symlink, it was time for it to go.
> 
> But, it was a huge and sudden pain for it to suddenly disappear and break 
> everything...
> 
> I can only abandon FreeBSD as our DNS platform as fast as replacement systems 
> appear.
> 
> Why have we decided that we're going to cease FreeBSD for our DNS servers 
> (after I had made such a strong case for FreeBSD?)  Count the PORTREVISIONs 
> to bind before 9.9.4 and after.  Plus look at all the other annoying changes 
> in those PORTREVISIONs without that things have been working fine for the 
> rest of us before.
> 
> I should've been home hours ago...if I haven't been stuck dealing with 
> bizarre problems caused by updating a bunch of packages.
> 
> Now I have update nagios-plugins, since base nslookup is gone.  Does it end?


( ... As another user/admin of named for years, I've also gnashed teeth
as FreeBSD re-arranged var & chroot & rndc paths yet again, per
version; Needing more version dependent additions to my multi
version wrapper shell. OK, perhaps inevitable, but ... )

The latest FreeBSD named annoyance, ripping named out of src/ (&
apparently abandoning the chroot too I've read ?!), caused me &
presumably numerous other user admins to _Not_ upgrade FreeBSD boxes
until extra free time could be found to deal with FreeBSD gratuitously
consuming user time.

Years back FreeBSD had too many broken ports, but at least then
broken code was still in ports/ even if not enough was marked with
Makefile BROKEN="cause", & often we needed numerous setenv DUDS
"onemore `printenv DUDS`" .

Now FreeBSD ports is in some ways Worse, it regularly loses not
just broken but even working ports, for no Good reason (eg demime
& majordomo etc).

Ports get regularly axed, so user admins know for each FreeBSD
upgrade we've first got to stumble over what ports commiters have
axed, then discover when axed, then recover back from svn to ports/,
then install marked BROKEN=, then develop a fix (if a fix is even
necessary!), then store the patch for automatic application by local
script, (in case FreeBSD fail to accept it ) then convince FreeBSD
that a butchered port thould be restored.

FreeBSD ports axe men are damaging FreeBSD, they should just
assert BROKEN= on broken ports, & Never removing working ports/ !

Cheers,
Julian
-- 
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
 Indent previous with "> ".  Interleave reply paragraphs like a play script.
 Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.
 Practice French & support democracy ? Buy on 14 Jan http://www.charliehebdo.fr
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Loganaden Velvindron]

On Sun, Jan 11, 2015 at 5:13 PM, Julian H. Stacey  wrote:
> Hi, Reference:
>> From: The BSD Dreamer 
>> Date: Sat, 10 Jan 2015 21:25:11 -0600
>
> The BSD Dreamer wrote:
>>
>> On 2015-01-09 07:42, Mathieu Arnold wrote:
>> > +--On 8 janvier 2015 19:44:09 -0800 Doug Barton  
>> > wrote:
>> > | Can you please explain why this option was removed? It's been in the
>> > | ports for over 13 years, and lots of users utilized it.
>> > |
>> > | I realize that BIND is no longer in the base in 10.x, but that would
>> > | be a reason to make the option conditional, to continue to support the
>> > | substantial user base that is still on 8.x and 9.x.
>> >
>> > I only removed it from bind99, it was never there in bind910.  I removed it
>> > because it was a poor design idea to begin with, and it was making the port
>> > harder to maintain.  Also, it was overwriting files in the base system,
>> > which is a thing we do not want to do.
>> >
>> > All you need to do is add:
>> >
>> > named_program="/usr/local/sbin/named"
>> >
>> > to your rc.conf, like the message says when you install the port.
>> >
>> > It was a bit like the /usr/bin/perl symlink, it was time for it to go.
>>
>> But, it was a huge and sudden pain for it to suddenly disappear and break
>> everything...
>>
>> I can only abandon FreeBSD as our DNS platform as fast as replacement systems
>> appear.
>>
>> Why have we decided that we're going to cease FreeBSD for our DNS servers
>> (after I had made such a strong case for FreeBSD?)  Count the PORTREVISIONs
>> to bind before 9.9.4 and after.  Plus look at all the other annoying changes
>> in those PORTREVISIONs without that things have been working fine for the
>> rest of us before.
>>
>> I should've been home hours ago...if I haven't been stuck dealing with
>> bizarre problems caused by updating a bunch of packages.
>>
>> Now I have update nagios-plugins, since base nslookup is gone.  Does it end?
>
>
> ( ... As another user/admin of named for years, I've also gnashed teeth
> as FreeBSD re-arranged var & chroot & rndc paths yet again, per
> version; Needing more version dependent additions to my multi
> version wrapper shell. OK, perhaps inevitable, but ... )
>
> The latest FreeBSD named annoyance, ripping named out of src/ (&
> apparently abandoning the chroot too I've read ?!), caused me &

Is there a rationale behind abandoing chroot() ?

Is there a URL for that ?

> presumably numerous other user admins to _Not_ upgrade FreeBSD boxes
> until extra free time could be found to deal with FreeBSD gratuitously
> consuming user time.
>
> Years back FreeBSD had too many broken ports, but at least then
> broken code was still in ports/ even if not enough was marked with
> Makefile BROKEN="cause", & often we needed numerous setenv DUDS
> "onemore `printenv DUDS`" .
>
> Now FreeBSD ports is in some ways Worse, it regularly loses not
> just broken but even working ports, for no Good reason (eg demime
> & majordomo etc).
>
> Ports get regularly axed, so user admins know for each FreeBSD
> upgrade we've first got to stumble over what ports commiters have
> axed, then discover when axed, then recover back from svn to ports/,
> then install marked BROKEN=, then develop a fix (if a fix is even
> necessary!), then store the patch for automatic application by local
> script, (in case FreeBSD fail to accept it ) then convince FreeBSD
> that a butchered port thould be restored.
>
> FreeBSD ports axe men are damaging FreeBSD, they should just
> assert BROKEN= on broken ports, & Never removing working ports/ !
>
> Cheers,
> Julian
> --
> Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
>  Indent previous with "> ".  Interleave reply paragraphs like a play script.
>  Send plain text, not quoted-printable, HTML, base64, or 
> multipart/alternative.
>  Practice French & support democracy ? Buy on 14 Jan 
> http://www.charliehebdo.fr
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"



-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Roger Marquis]

The BSD Dreamer wrote:

+--On 8 janvier 2015 19:44:09 -0800 Doug Barton  wrote:

| Can you please explain why this option was removed? It's been in the
| ports for over 13 years, and lots of users utilized it.
|
I only removed it from bind99, it was never there in bind910.  I removed it
because it was a poor design idea to begin with, and it was making the port
harder to maintain.  Also, it was overwriting files in the base system,
which is a thing we do not want to do.


That sounds like the crux of the issue.  Named shouldn't have been in
base in the first place.  Removing the port option instead of the base
binary, IMO, makes two wrongs not one right.  My way or the highway might
be ok for Windows, Mac and Linux but port options are a big reason many
of us use and spec FreeBSD.


It was a bit like the /usr/bin/perl symlink, it was time for it to go.


"time for it to go", by whose definition?  Good code doesn't have a fixed
lifespan and the claimed rational doesn't constitute a good business case.

On the other hand it should be easy enough to write a bindXX-base wrapper
port.  Anyone care to quote bind10-base/Makefile?  That and fixing
openssh-portable's dialog option for overwrite_base which when selected
fails with "openssh-portable-6.7.p1_1,1 Overwrite base option is no
longer supported.."  Have to wonder how that got past the port
maintainers.

This is not unlike postfix-base and others which, in many cases, are
significantly improved by offering a cross-platform compatibility options
and not being short-sighted regarding the scope of $PREFIX.

Sometimes you really have to wonder whether these feature deprecations
are due less to resource shortages than to special interests outside of
FreeBSD's user-base.

IMO,
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Mark Linimon]

On Sun, Jan 11, 2015 at 03:54:39PM -0800, Roger Marquis wrote:
> "time for it to go", by whose definition?  Good code doesn't have a
> fixed lifespan and the claimed rationale doesn't constitute a good
> business case.

It was believed to be a bad design pattern to let ports modify anything
in base.  There had been a few exceptions that crept in over the years,
for one reason or another.  Apparently 10.0 seemed like the appropriate
time to get rid of the bad pattern.  (Note: I was not involved in the
decision.)

We've been essentially rewriting the entire ports infrastructure in-place
for the past 6 or 7 years.  IMVHO this was entirely necessary: the old
pkg_* tools were buggy, underdocumented, and no longer suited to the task
of keeping up with over 20,000 ports.  Along the way we've had to throw
out a lot of rotten code both in the infrastructure and various ports --
*and* keep the absolute majority of ports working in the meantime.  This
was no mean feat.
 
> Sometimes you really have to wonder whether these feature deprecations
> are due less to resource shortages than to special interests outside of
> FreeBSD's user-base.

They are mostly due to the idea of not shipping things that do not work
consistently, and in the way one "might expect".  On rare occasion, yes,
that will mean breaking POLA.

(Also note I'm not defending the way this change was or was not documented.)

As for "special interests", this is specious.  AFAIK the companies that
embed FreeBSD into their products are primarily interested in the kernel,
the networking stack, the file systems, and so on.  I do not know of any
such company that even _uses_ FreeBSD ports.

Thus, they could have no influence on the outcome.

tl;dr: the FreeBSD ports community is pretty well self-contained.

mcl
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Russell L. Carter]

On 01/11/15 21:01, Mark Linimon wrote:

On Sun, Jan 11, 2015 at 03:54:39PM -0800, Roger Marquis wrote:

"time for it to go", by whose definition?  Good code doesn't have a
fixed lifespan and the claimed rationale doesn't constitute a good
business case.


It was believed to be a bad design pattern to let ports modify anything
in base.  There had been a few exceptions that crept in over the years,
for one reason or another.  Apparently 10.0 seemed like the appropriate
time to get rid of the bad pattern.  (Note: I was not involved in the
decision.)

We've been essentially rewriting the entire ports infrastructure in-place
for the past 6 or 7 years.  IMVHO this was entirely necessary: the old
pkg_* tools were buggy, underdocumented, and no longer suited to the task
of keeping up with over 20,000 ports.  Along the way we've had to throw
out a lot of rotten code both in the infrastructure and various ports --
*and* keep the absolute majority of ports working in the meantime.  This
was no mean feat.


Sometimes you really have to wonder whether these feature deprecations
are due less to resource shortages than to special interests outside of
FreeBSD's user-base.


They are mostly due to the idea of not shipping things that do not work
consistently, and in the way one "might expect".  On rare occasion, yes,
that will mean breaking POLA.

(Also note I'm not defending the way this change was or was not documented.)


"documented"

This is the problem. There is /usr/ports/UPDATING, but those of us who
sensibly use cron & poudriere to update our [ports & pkg] tree never
see the contents of /usr/ports/UPDATING.  Even with systemd cancer 
spreading all through debian I have only had one system fail, using

apt-get dist-upgrade.  Because notice is given in the "upgrade" process
that incompatible changes are being made.

The discussion of recent pinentry related stuff comes to mind.  Since I
have already ranted at length on why this is a show stopper,
on basic human security grounds, I'll stop here.  (Nope, as you can see,
I'm not using anything that pinentry was intended to facilitate.  How
could I, on FreeBSD?)

Russell


As for "special interests", this is specious.  AFAIK the companies that
embed FreeBSD into their products are primarily interested in the kernel,
the networking stack, the file systems, and so on.  I do not know of any
such company that even _uses_ FreeBSD ports.

Thus, they could have no influence on the outcome.

tl;dr: the FreeBSD ports community is pretty well self-contained.

mcl
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Roger Marquis]

Mark Linimon wrote:

It was believed to be a bad design pattern to let ports modify anything
in base.


Believed by who?  Surely not those of us advocating FreeBSD in mixed
environments where the Linux and Windows admins are pushing for something
closer to a monoculture.


Apparently 10.0 seemed like the appropriate time to get rid of the
bad pattern.


"seemed like the appropriate time" isn't a business case and "bad
pattern" it likely wasn't considering A) someone requested it, B) someone
spent money and/or time writing it and C) many people were using it.


We've been essentially rewriting the entire ports infrastructure in-place
for the past 6 or 7 years.  IMVHO this was entirely necessary: the old
pkg_* tools were buggy, underdocumented, and no longer suited to the task


Not sure what this has to do with a small number of mission-critical
ports that need to write to base to accommodate large, cross-platform,
installed bases.  Could you elaborate?


They are mostly due to the idea of not shipping things that do not work
consistently, and in the way one "might expect".  On rare occasion, yes,
that will mean breaking POLA.


Are you saying, then, that bind, postfix and other ports that have
overwritten base for years "do not work consistently"?  That hasn't been
my experience nor that of those who I work with.


AFAIK the companies that embed FreeBSD into their products are primarily
interested in the kernel, the networking stack, the file systems, and so
on. I do not know of any such company that even _uses_ FreeBSD ports.


I see your point but it indicates your experience is missing a large
portion of FreeBSD users.  The financial institution where I work for
example, runs hundreds of FreeBSD boxes and uses ports and port options
on all of them.


Thus, they could have no influence on the outcome.


If large numbers of BSD servers and engineers with decades of BSD
advocacy really have no influence, and it appears we don't, at least
the reason for our favorite OS' shrinking user-base is clear.

Statements like "buggy, underdocumented, and no longer suited to the
task" and "could have no influence on the outcome" are perhaps a downside
of exclusively developer-driven ecosystems.  Redhat's understands this,
which is why they involve sales, sysadmins and management in similar
decisions, not just devs who are looking to spend less time maintaining
"old" code.  (They're also paying people to maintain code, something I
wish we could find a way to do.)


tl;dr: the FreeBSD ports community is pretty well self-contained.


Do you mean in contrast with, for example, the Debian community?


Roger
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Craig Rodrigues]

On Jan 11, 2015 8:01 PM, "Mark Linimon"  wrote:
>
>  AFAIK the companies that
> embed FreeBSD into their products are primarily interested in the kernel,
> the networking stack, the file systems, and so on.  I do not know of any
> such company that even _uses_ FreeBSD ports.
>

Wrong.  I've worked at 3 companies over the years that make direct use of
the ports tree when creating an embedded product based on FreeBSD.

In 2015, it is my experience that the stuff in /usr/src is only the bare
minimum to get going for a product.  ports are extremely important for a
modern embedded product based on FreeBSD.

--
Craig
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Michelle Sullivan]

I'm going to wade in with a +1 at the top for your original message, and
add some thoughts of my own inline.

Roger Marquis wrote:
> Mark Linimon wrote:
>> It was believed to be a bad design pattern to let ports modify anything
>> in base.
>
> Believed by who?  Surely not those of us advocating FreeBSD in mixed
> environments where the Linux and Windows admins are pushing for something
> closer to a monoculture.

Dunno about who believed what, however it has always struck me as odd
that servers are installed in the base and then only patched with the
OS.  The notable exceptions are things like BIND where you could select
a later BIND from the ports tree and install over the base version. 
This initially I found confusing and likely to cause more security
issues than it resolved...  However, I then thought about it, and
realised that what should really have been considered is this (in my
opinion):

*NO* servers installed in Base (no sendmail, no NTPD, no BIND etc) then
in the ports tree a "dns/bind-base" port where it would install a bind
server into the base OS, a 'mail/postfix-base', a 'mail/sendmail-base'
etc... or better still a /usr/ports/base where you can find postfix,
sendmail, bind etc...

This way there are no base ports installed by default, base packages are
available with the OS and the specific '-base' port can always be
patched as part of freebsd-update, it can be built as part of a /usr/src
building/patching process and therefore it can be patched as the user
needs in short order (particularly important when you have issues such
as the latest root exploit for ntpd... not saying the way that security
moved and patched it in a few days wasn't good, it was awesome...
however the problem is I had servers ranging from 6.0 -> 9.3 at various
patch levels - I now have most of my servers either 6.x or 9.2+ (the 6.x
servers are all behind firewalls with only specific services (apache
and/or postfix) exposed where necessary so the exploit is mitigated)...

BUT the patching from 7.3, 8.4 and 9.0 of 27 of the servers 15 of them
became unbootable for a variety of reasons... Corrupt loader on 2
occasions, unable to initiate network interface or RAID card on several
occasions and changing of critical permissions in others (9.3-RELEASE ->
9.3-p5 broke sudo-1.8(latest) on 3 of the machines by changing
permissions on 'something')... having /usr/ports/base where one could
find 'ntpd' and install it in base would be an excellent solution as one
could update/patch oneself if security@ didn't consider the priority as
high as the user.  It would also mean that the base source code is not
polluted and one can install what one needs as and when needed.

>
>> Apparently 10.0 seemed like the appropriate time to get rid of the
>> bad pattern.
>
> "seemed like the appropriate time" isn't a business case and "bad
> pattern" it likely wasn't considering A) someone requested it, B) someone
> spent money and/or time writing it and C) many people were using it.

Roger, you can forget arguing that, I've tried it falls on deaf ears and
people just put you on ignore like they have with me... doesn't matter
if you're right or not..  Some at the top have a mark to make and being
right or wrong won't get in the way of that mark.

>
>> We've been essentially rewriting the entire ports infrastructure
>> in-place
>> for the past 6 or 7 years.  IMVHO this was entirely necessary: the old
>> pkg_* tools were buggy, underdocumented, and no longer suited to the
>> task

Which is why pkg_* tools are now removed when you 'delete-old' and all
the *.mk keep changing to remove pkg_* support even though those of us
that have spent the time to put it back have found that it still works
with little changes...  Everything in the source seems to point to
someone making their mark to remove the pkg_ tools rather than any
specific need...  Why it couldn't have been left for pre 10.x and then
make 10.x pkgng only I don't know... oh wait I do.. it didn't have many
people using it so it was decided to force people to change...  Lets
think of that for a moment... people tried it decided it wasn't "ready"
and didn't migrate, so Bapt wrote patches and deployed on 1/9/2014 not
to EOL pkg_* but specifically to break pkg_* then discouraged anyone
from back patching (including security fixes) to the quarterly to force
the upgrade on production systems.
>
> Not sure what this has to do with a small number of mission-critical
> ports that need to write to base to accommodate large, cross-platform,
> installed bases.  Could you elaborate?
Breaking out the servers from /usr/src is good idea, removing -base
functionality (IMHO) is not... but it is a good idea to make it simpler
because the -base options (especially when not always translated in
version changes) did cause me a few issues in the past.

>
>> They are mostly due to the idea of not shipping things that do not work
>> consistently, and in the way one "might expect".  On rare occasion, yes,
>> that will me

Re: BIND REPLACE_BASE option

[Mark Linimon]

On Sun, Jan 11, 2015 at 10:38:50PM -0800, Craig Rodrigues wrote:
> Wrong.  I've worked at 3 companies over the years that make direct use of
> the ports tree when creating an embedded product based on FreeBSD.

OK, then this is the first I've heard of it.  My mistake.

mcl
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Michelle Sullivan]

Mark Linimon wrote:
> On Sun, Jan 11, 2015 at 10:38:50PM -0800, Craig Rodrigues wrote:
>   
>> Wrong.  I've worked at 3 companies over the years that make direct use of
>> the ports tree when creating an embedded product based on FreeBSD.
>> 
>
> OK, then this is the first I've heard of it.  My mistake.
>   

Just a thought: "FreeNAS" .. I know it uses ports, would one consider
any (home NAS) device that ships with FreeNAS as it's OS as an embedded
device?   (Don't know if there are any, but it was the first thing that
came to mind.)

-- 
Michelle Sullivan
http://www.mhix.org/

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Mark Linimon]

On Mon, Jan 12, 2015 at 01:29:32PM +0100, Michelle Sullivan wrote:
> Just a thought: "FreeNAS"

FreeNAS uses ports ... in their own way.  Yes, they do contribute back
changes as well.

The point that I was trying to make, even though I used bad data, was
that Ports aren't being driven by external influence.

mcl
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Michelle Sullivan]

Mark Linimon wrote:
> On Mon, Jan 12, 2015 at 01:29:32PM +0100, Michelle Sullivan wrote:
>   
>> Just a thought: "FreeNAS"
>> 
>
> FreeNAS uses ports ... in their own way.  Yes, they do contribute back
> changes as well.
>
> The point that I was trying to make, even though I used bad data, was
> that Ports aren't being driven by external influence.
>   

No disputing that, just thinking, is FreeBSD being driven by user need,
financial contributer need, developer need, security need, making things
'better' or just by people wanting to make their mark in a warped sense
of "it'll all get better"...?

Questions people should ask are:

Do we want to make things easier for existing users.
Do we want to make things easier for users to convert from other OSes
Do we want to develop for anyone paying for changes regardless of the
cost (to users)
Do we want people to develop what they want for their own purpose

My thoughts on all those questions:

We should not make anything harder for existing users, and make things
easier if possible - however if they are existing users the chances are
they already know how to make things work so we should not break stuff
already working.

We should make things easier for people to migrate to us, and that may
mean the work should concentrate on fixing bugs and updating docs as a
priority over new features (Microsoft for years went down the route of
new features over security or docs, look where it got them)

Develop for anyone?  Yes and No, what is requested should be evaluated
for benefit to the community as a whole and prioritized based on cost
and contributions, and rejected out right if it is considered
detrimental to the community as a whole (and we should listen to
minorities when evaluating, because sometimes the smaller voices can
provide saner/long term paths to the same goal.)

People develop for their own purpose... well that's what the ports tree
is therefore isn't it? ;-)

Probably more questions and answers can be added, but they are the first
to come to mind.

Michelle

-- 
Michelle Sullivan
http://www.mhix.org/

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Kurt Jaeger]

Hi!

> No disputing that, just thinking, is FreeBSD being driven by user need,
> financial contributer need, developer need, security need, making things
> 'better' or just by people wanting to make their mark in a warped sense
> of "it'll all get better"...?

Probably by developer *capacity* (not need) and fire-fighting,
like most IT stuff 8-(

-- 
p...@opsec.eu+49 171 3101372 5 years to go !
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Royce Williams]

On Mon, Jan 12, 2015 at 4:08 AM, Kurt Jaeger  wrote:

>> No disputing that, just thinking, is FreeBSD being driven by user need,
>> financial contributer need, developer need, security need, making things
>> 'better' or just by people wanting to make their mark in a warped sense
>> of "it'll all get better"...?
>
> Probably by developer *capacity* (not need) and fire-fighting,
> like most IT stuff 8-(

But like most IT stuff, resources are being asymmetrically applied to
the root causes of the fires.

Read the list of projects from last quarter:

- Address Space Layout Randomization (ASLR)
- amd64 Xen Paravirtualization
- bhyve
- Chelsio iSCSI Offload Support
- Debian GNU/kFreeBSD
- FreeBSD Preseed Installation (PXE)
- Jenkins Continuous Integration for FreeBSD
- New Automounter
- QEMU bsd-user-Enabled Ports Building
- VMWare VAAI and Microsoft ODX Acceleration in CTL
- ZFSguru
- Intel GPU Driver Update
- SDIO Driver
- UEFI Boot
- Updated vt(4) System Console
- Updating OpenCrypto
- FreeBSD on Newer ARM Boards
- FreeBSD/arm64
- LLDB Debugger Port
- LLVM Address Sanitizer (Asan)
- SSE Variants of libc Routines for amd64
- FreeBSD Python Ports
- GNOME/FreeBSD
- KDE on FreeBSD
- The Graphics Stack on FreeBSD
- Xfce

The Foundation section also lists these items not overlapping with the above:

- FreeBSD Journal
- PostgreSQL performance improvements
- Ongoing release process
- Development snapshots
- VM images for releases
- Secure Boot planning
- Infrastructure hardware
- Java licensing
- Summits and summit sponsorship
- Travel grants, tutorials, and talks
- New Design and Implementation book
- Recruitment flyers

Are there long-term improvement projects that aren't being listed?  If
so, they should be.

At face value, the main project list is heavily weighted towards
relatively esoteric OS features. The Foundation list is heavily
weighted towards advocacy and communication (as it should be).

What is missing are high-level projects to help sysadmins maintain and
use FreeBSD on an ongoing basis.

Here are some projects that would help to close the sysadmin gap:

- Automatic error reporting and analysis
- OS and port debugging tools for sysadmins
- Independent project-wide usability analysis
- Ports dependency isolation and reduction framework
- Ports system reliability parity with Linuxes
- Searchable, taggable project FAQ
- Searchable hardware support matrix integrated with bug tracker
- Wiki curation and platform improvements

These projects decentralize and improve support for sysadmins and new
adopters.  As a business case for the Foundation, these projects
should also deeply free up developer resources to focus on other major
projects.

In the past, when I have pointed out this "sysadmin gap", I receive
one of two answers:

1. Sounds great. Let us know when you have it finished.

2. We're too busy to do any of those things.

... to which I answer:

1. These projects require technical skill and political capital within
the project.  They are ideally suited for well-established independent
FreeBSD consultants with large blocks of time sponsored by the FreeBSD
Foundation.  I can help (especially with the wiki work), but cannot
tackle these deeper problems in the way that others can.

2. The reason you're busy is that you don't have these things.

I applaud recent work on Jenkins and cluster infrastructure.  I also
appreciate Colin Percivals's automated error reporting work, because
it directly attacks the sysadmin gap.  And I know that getting
releases out the door is time-consuming and keeps the lights on.

But the overall project list needed to be rebalanced towards system
administration.  I request that the Foundation consider this when
calling for proposals for the next round of funded projects.

Royce
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Chris H]

On Mon, 12 Jan 2015 07:10:46 -0900 Royce Williams  wrote

> On Mon, Jan 12, 2015 at 4:08 AM, Kurt Jaeger  wrote:
> 
> >> No disputing that, just thinking, is FreeBSD being driven by user need,
> >> financial contributer need, developer need, security need, making things
> >> 'better' or just by people wanting to make their mark in a warped sense
> >> of "it'll all get better"...?
> >
> > Probably by developer *capacity* (not need) and fire-fighting,
> > like most IT stuff 8-(
> 
> But like most IT stuff, resources are being asymmetrically applied to
> the root causes of the fires.
> 
> Read the list of projects from last quarter:
> 
> - Address Space Layout Randomization (ASLR)
> - amd64 Xen Paravirtualization
> - bhyve
> - Chelsio iSCSI Offload Support
> - Debian GNU/kFreeBSD
> - FreeBSD Preseed Installation (PXE)
> - Jenkins Continuous Integration for FreeBSD
> - New Automounter
> - QEMU bsd-user-Enabled Ports Building
> - VMWare VAAI and Microsoft ODX Acceleration in CTL
> - ZFSguru
> - Intel GPU Driver Update
> - SDIO Driver
> - UEFI Boot
> - Updated vt(4) System Console
> - Updating OpenCrypto
> - FreeBSD on Newer ARM Boards
> - FreeBSD/arm64
> - LLDB Debugger Port
> - LLVM Address Sanitizer (Asan)
> - SSE Variants of libc Routines for amd64
> - FreeBSD Python Ports
> - GNOME/FreeBSD
> - KDE on FreeBSD
> - The Graphics Stack on FreeBSD
> - Xfce
> 
> The Foundation section also lists these items not overlapping with the above:
> 
> - FreeBSD Journal
> - PostgreSQL performance improvements
> - Ongoing release process
> - Development snapshots
> - VM images for releases
> - Secure Boot planning
> - Infrastructure hardware
> - Java licensing
> - Summits and summit sponsorship
> - Travel grants, tutorials, and talks
> - New Design and Implementation book
> - Recruitment flyers
> 
> Are there long-term improvement projects that aren't being listed?  If
> so, they should be.
> 
> At face value, the main project list is heavily weighted towards
> relatively esoteric OS features. The Foundation list is heavily
> weighted towards advocacy and communication (as it should be).
> 
> What is missing are high-level projects to help sysadmins maintain and
> use FreeBSD on an ongoing basis.
> 
> Here are some projects that would help to close the sysadmin gap:
> 
> - Automatic error reporting and analysis
> - OS and port debugging tools for sysadmins
> - Independent project-wide usability analysis
> - Ports dependency isolation and reduction framework
> - Ports system reliability parity with Linuxes
> - Searchable, taggable project FAQ
> - Searchable hardware support matrix integrated with bug tracker
> - Wiki curation and platform improvements
> 
> These projects decentralize and improve support for sysadmins and new
> adopters.  As a business case for the Foundation, these projects
> should also deeply free up developer resources to focus on other major
> projects.
> 
> In the past, when I have pointed out this "sysadmin gap", I receive
> one of two answers:
> 
> 1. Sounds great. Let us know when you have it finished.
> 
> 2. We're too busy to do any of those things.
> 
> ... to which I answer:
> 
> 1. These projects require technical skill and political capital within
> the project.  They are ideally suited for well-established independent
> FreeBSD consultants with large blocks of time sponsored by the FreeBSD
> Foundation.  I can help (especially with the wiki work), but cannot
> tackle these deeper problems in the way that others can.
FWIW I'm already in the process of creating a wiki that will serve
as a FreeBSD Documentation Factory. I've created the wiki, and am
currently plugging in all the necessary "bits". This will permit
"live" documentation creation, and editing -- including man(1)
pages. It's currently backed by git(1), but conversions to other
RCS, SCM, VCS, {...} are all possible. In fact, I already have the
conversion methods available. This all makes it possible to import
any revision of any doc/man page as an "official" doc set.

Point being; as FreeBSD is Open Source, it heavily depends on
user-contribution. I'm not attempting to discount your previous
points, however. Just saying. As to the "sysadmin gap" a look to
the ports tree seems to indicate quite a volume of "sysadmin"
related ports. Are some missing?

All the best.

--Chris
> 
> 2. The reason you're busy is that you don't have these things.
> 
> I applaud recent work on Jenkins and cluster infrastructure.  I also
> appreciate Colin Percivals's automated error reporting work, because
> it directly attacks the sysadmin gap.  And I know that getting
> releases out the door is time-consuming and keeps the lights on.
> 
> But the overall project list needed to be rebalanced towards system
> administration.  I request that the Foundation consider this when
> calling for proposals for the next round of funded projects.
> 
> Royce
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.or

Re: BIND REPLACE_BASE option

[Royce Williams]

On Mon, Jan 12, 2015 at 7:38 AM, Chris H  wrote:

> As to the "sysadmin gap" a look to
> the ports tree seems to indicate quite a volume of "sysadmin"
> related ports. Are some missing?

To the contrary -- there are too many.

A good project would be to survey which ones people actually use, and
why -- and then bring their best features into base.

This would be difficult to do as a independent skunkworks project, and
would be better suited as a high-level, Foundation-sponsored one.

(For example, in the Debian ecosystem, for most people, there is no
reason to use something other than apt-get, because it does what it
should and does it well. Every time I upgrade a port, I have to study
/usr/ports/UPDATING, read multiple mailing lists, and hold my breath.
I cannot remember the last time I worried about running apt-get.
Arguments about flexibility and diversity ecosystem don't hold up well
when the basics fail on a regular basis.)

Royce
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Chris H]

On Mon, 12 Jan 2015 07:55:45 -0900 Royce Williams  wrote

> On Mon, Jan 12, 2015 at 7:38 AM, Chris H  wrote:
> 
> > As to the "sysadmin gap" a look to
> > the ports tree seems to indicate quite a volume of "sysadmin"
> > related ports. Are some missing?
> 
> To the contrary -- there are too many.
> 
> A good project would be to survey which ones people actually use, and
> why -- and then bring their best features into base.
I agree something like thishas value. But obtaining access to the
usage matrix is the key.

> 
> This would be difficult to do as a independent skunkworks project, and
> would be better suited as a high-level, Foundation-sponsored one.
see above.
> 
> (For example, in the Debian ecosystem, for most people, there is no
> reason to use something other than apt-get, because it does what it
> should and does it well. Every time I upgrade a port, I have to study
> /usr/ports/UPDATING, read multiple mailing lists, and hold my breath.
> I cannot remember the last time I worried about running apt-get.
> Arguments about flexibility and diversity ecosystem don't hold up well
> when the basics fail on a regular basis.)
Here is where we will clash; I've been riding *BSD for over 20yrs.
It's *biggest* asset has been in it's flexibility -- it wasn't another
Linux "dist", that required me to essentially become a "clone" of
every other Linux install. The Ports system, and /src allowed one to
tailor my build/install to meet *my* needs. I wasn't required, in fact
I was *encouraged*, to have a unique system. Frankly the new pkg(8)
*requirement* was a complete 180 on this philosophy. It's implementation
was also flawed in many respects (which speaks to your point). I have no
objection to pkg(8), per se; But it *should* have been optional, it
*should* have been better (longer) tested, *before* pushed into the
ecosystem, and should *not* have been implemented with a backend with
single-point-of-failue (sqlite3(1). Honestly; why did pkg(8) have to
be *required*? Is FreeBSD simply hoping to become a new "distro"?
But, given it's there, and how it's there. You have/bring up some valid,
points; it *is* a bit of a game of roulette. I *too* get a knot in my
stomach even at the *thought* of an upgrade. Sure there are plenty of
choices in an upgrade path/implementation. But, as it sits now, I'm
not sure I can say it's gotten any easier, or "trouble free", as a
result of pkg(8).

--Chris
> 
> Royce
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


--Chris

---


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Royce Williams]

On Mon, Jan 12, 2015 at 8:24 AM, Chris H  wrote:
> On Mon, 12 Jan 2015 07:55:45 -0900 Royce Williams  wrote
>
>> On Mon, Jan 12, 2015 at 7:38 AM, Chris H  wrote:
>>
>> > As to the "sysadmin gap" a look to
>> > the ports tree seems to indicate quite a volume of "sysadmin"
>> > related ports. Are some missing?
>>
>> To the contrary -- there are too many.
>>
>> A good project would be to survey which ones people actually use, and
>> why -- and then bring their best features into base.
> I agree something like thishas value. But obtaining access to the
> usage matrix is the key.

A fair point.  Instrumenting the OS now to make this usage possible
later would be a good idea.

IIRC, PC-BSD integrated BSDstats a while back.  If FreeBSD did the
same, and prompted at install for "Would you like to help the project
by reporting anonymous hardware and software inventory information?",
we could start to build that matrix.

>> This would be difficult to do as a independent skunkworks project, and
>> would be better suited as a high-level, Foundation-sponsored one.
> see above.
>>
>> (For example, in the Debian ecosystem, for most people, there is no
>> reason to use something other than apt-get, because it does what it
>> should and does it well. Every time I upgrade a port, I have to study
>> /usr/ports/UPDATING, read multiple mailing lists, and hold my breath.
>> I cannot remember the last time I worried about running apt-get.
>> Arguments about flexibility and diversity ecosystem don't hold up well
>> when the basics fail on a regular basis.)

> Here is where we will clash; I've been riding *BSD for over 20yrs.
> It's *biggest* asset has been in it's flexibility -- it wasn't another
> Linux "dist", that required me to essentially become a "clone" of
> every other Linux install. The Ports system, and /src allowed one to
> tailor my build/install to meet *my* needs. I wasn't required, in fact
> I was *encouraged*, to have a unique system. Frankly the new pkg(8)
> *requirement* was a complete 180 on this philosophy. It's implementation
> was also flawed in many respects (which speaks to your point). I have no
> objection to pkg(8), per se; But it *should* have been optional, it
> *should* have been better (longer) tested, *before* pushed into the
> ecosystem, and should *not* have been implemented with a backend with
> single-point-of-failue (sqlite3(1). Honestly; why did pkg(8) have to
> be *required*? Is FreeBSD simply hoping to become a new "distro"?
> But, given it's there, and how it's there. You have/bring up some valid,
> points; it *is* a bit of a game of roulette. I *too* get a knot in my
> stomach even at the *thought* of an upgrade. Sure there are plenty of
> choices in an upgrade path/implementation. But, as it sits now, I'm
> not sure I can say it's gotten any easier, or "trouble free", as a
> result of pkg(8).

I basically agree.  pkg(8)'s heart is in the right place, but it was
not baked long enough.

I like the idea of being flexible as a proving ground, and then
selecting best of breed as the baseline.

Royce
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Kurt Jaeger]

Hi!

> Honestly; why did pkg(8) have to be *required*?

Because those that are really active in maintaining it had the choice of
either

- keeping the old system running, and breaking down on the burden of doing so 

or

- migrating to the pkgng setup which allows to cope with the rate of
  change in the non-freebsd-base software world

It's an economics question: Those players in the open-source OS market
that have the resources to keep going will stay afloat.

FreeBSD had the choice to loose more active maintainers trying to
keep the old state or attract new ones with the new state. It's a
gamble, and if enough people like the old style more, they probably
have to fork.

I've used both styles for a while and yes, the switchover takes
time and patience, but it's not the end-of-the-world.

-- 
p...@opsec.eu+49 171 3101372 5 years to go !
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Warren Block]

On Mon, 12 Jan 2015, Chris H wrote:


Here is where we will clash; I've been riding *BSD for over 20yrs.
It's *biggest* asset has been in it's flexibility -- it wasn't another
Linux "dist", that required me to essentially become a "clone" of
every other Linux install. The Ports system, and /src allowed one to
tailor my build/install to meet *my* needs. I wasn't required, in fact
I was *encouraged*, to have a unique system. Frankly the new pkg(8)
*requirement* was a complete 180 on this philosophy.


Huh?  It is the same as the old package system, required if you want to 
use ports or packages.  The difference is that pkg is not in base, so it 
can be easily upgraded without doing an OS upgrade.  Ports continue to 
work as they did with the old package system, only package operations 
are faster and more reliable.


My main complaint with pkg is the persistent misunderstanding that 
binary packages are a direct replacement for ports.

http://www.wonkity.com/~wblock/docs/html/pkg.html

As for the original topic, BIND in base had the same upgrade problems as 
the old package system.  The port overwriting the base was a convenient 
but nasty hack.  Not even that convenient, because all that changes with 
the port is the config files are in /usr/local/etc rather than /etc.  A 
chroot adds little security or isolation, and if you want that it should 
be in a jail or other type of VM anyway.

https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-ezjail.html#jails-ezjail-example-bind
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Chris H]

On Mon, 12 Jan 2015 11:57:26 -0700 (MST) Warren Block 
wrote

> On Mon, 12 Jan 2015, Chris H wrote:
> 
> > Here is where we will clash; I've been riding *BSD for over 20yrs.
> > It's *biggest* asset has been in it's flexibility -- it wasn't another
> > Linux "dist", that required me to essentially become a "clone" of
> > every other Linux install. The Ports system, and /src allowed one to
> > tailor my build/install to meet *my* needs. I wasn't required, in fact
> > I was *encouraged*, to have a unique system. Frankly the new pkg(8)
> > *requirement* was a complete 180 on this philosophy.
> 
> Huh?  It is the same as the old package system, required if you want to 
> use ports or packages.  The difference is that pkg is not in base, so it 
> can be easily upgraded without doing an OS upgrade.  Ports continue to 
> work as they did with the old package system, only package operations 
> are faster and more reliable.
Sure, it's intended to *feel* like pkg_, but the (way) it's implemented
bears little resemblance to pkg_, and it's implementation also *abruptly*
pulled the rug out from under many years of development work, carefully
crafted work by development shops to keep their stream flowing smoothly
and more efficiently. [I'm kicking a dead horse here]

> 
> My main complaint with pkg is the persistent misunderstanding that 
> binary packages are a direct replacement for ports.
> http://www.wonkity.com/~wblock/docs/html/pkg.html
I'd be inclined to agree here.

> 
> As for the original topic, BIND in base had the same upgrade problems as 
> the old package system.  The port overwriting the base was a convenient 
> but nasty hack.  Not even that convenient, because all that changes with 
> the port is the config files are in /usr/local/etc rather than /etc.  A 
> chroot adds little security or isolation, and if you want that it should 
> be in a jail or other type of VM anyway.
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-ezjail.html#
Speaking of kicking "dead horses"; I'm still amazed that this topic
still continues. I remember the initial discussion on this about 9mos ago,
and thought;
OK. That seems to make sense. I'd better see if I can cobble up
something that mimic's the old setup, so I can keep things going, until
I find a suitable replacement for the BIND.
Took me less than 2hrs. Point being; there was a fair amount of time
before the BIND got yanked (unlike the pkg change). So I'm amazed so
many people are, well, amazed.

--Chris

---


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Mark Linimon]

Thanks to the various folks in this thread for reminding me why I
stepped down from portmgr.

I really don't have the heart these days to argue with people.

Y'all have fun.  I won't be contributing any more to this thread.

mcl
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Mathieu Arnold]

I'm only going to answer that part, the rest of the thread being, I feel,
mostly FUD.

+--On 10 janvier 2015 21:25:11 -0600 The BSD Dreamer 
wrote:
| Count the
| PORTREVISIONs to bind before 9.9.4 and after.  Plus look at all the other
| annoying changes in those PORTREVISIONs without that things have been
| working fine for the rest of us before.

Yes, let's say there are two kinds of maintainers, those who keep the bugs
they find in the port until there is a new release to an absolute minimum
so that people are not scared of the number of changes, and there are
those, like me, that would rather have a dozen updates between releases,
each addressing a bug when it arises.

The BIND ports were in such a miserable way, with kludges everywhere, when
I took over that it took me some time to get them right.

-- 
Mathieu Arnold
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Chris H]

On Tue, 13 Jan 2015 16:12:32 +0100 Mathieu Arnold  wrote

> I'm only going to answer that part, the rest of the thread being, I feel,
> mostly FUD.
Apologies for any contribution(s) I might have made in that area.
> 
> +--On 10 janvier 2015 21:25:11 -0600 The BSD Dreamer 
> wrote:
> | Count the
> | PORTREVISIONs to bind before 9.9.4 and after.  Plus look at all the other
> | annoying changes in those PORTREVISIONs without that things have been
> | working fine for the rest of us before.
> 
> Yes, let's say there are two kinds of maintainers, those who keep the bugs
> they find in the port until there is a new release to an absolute minimum
> so that people are not scared of the number of changes, and there are
> those, like me, that would rather have a dozen updates between releases,
> each addressing a bug when it arises.
> 
> The BIND ports were in such a miserable way, with kludges everywhere, when
> I took over that it took me some time to get them right.
I saw that mess -- more than once. Thank you for taking that on!

--Chris
> 
> -- 
> Mathieu Arnold
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Patrick Powell]

On 01/12/15 11:46, Chris H wrote:



My main complaint with pkg is the persistent misunderstanding that
binary packages are a direct replacement for ports.
http://www.wonkity.com/~wblock/docs/html/pkg.html

I'd be inclined to agree here.


There are some ports that almost demand a local version - apr (Apache 
Portability Library) being one of them.
Currently,  I am locking 'apr' so that pkg upgrade does not clobber 
apr,  and this has worked so far.


Just an observation.

--
Patrick Powell Astart Technologies
papow...@astart.com1530 Jamacha Rd, Suite X
Network and System San Diego, CA 92019
  Consulting   858-874-6543 FAX 858-751-2435
Web: www.astart.com

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Matthew Seaman]

On 01/13/15 15:24, Patrick Powell wrote:
> On 01/12/15 11:46, Chris H wrote:
>>
>>> My main complaint with pkg is the persistent misunderstanding that
>>> binary packages are a direct replacement for ports.
>>> http://www.wonkity.com/~wblock/docs/html/pkg.html
>> I'd be inclined to agree here.

The aim with pkg(8) in this regard was to make it possible to maintain a
machine using only binary packages.  Something that it has succeeded at,
given the proviso that you have access to a repo with all the
customizations you need available.  If the default options don't cut it
for you, in order to use only binary packages that means you need to run
your own poudriere setup -- which is well worth it if you're managing
several machines / jails etc.  You don't need a ports tree on every
single machine, and the length of your intervention on a production
server is pretty much as long as 'pkg upgrade' takes to run, which is
much quicker and less intrusive than running builds locally.

However, while pkg(8) now has the right mechanics to maintain a machine
with binaries only, the ports tree is still (despite all the work that
has been going into it recently) not yet set up to support doing that
very effectively.  In essence, we'd need to be building several
different 'flavours' for certain packages, along with various other
enhancements like sub-packages and PROVIDES/REQUIRES style dependencies.

Note that *none* of this is going to impede building stuff straight out
of ports in the time honoured fashion.  That simply is not on the pkg(8)
agenda.

> There are some ports that almost demand a local version - apr (Apache
> Portability Library) being one of them.
> Currently,  I am locking 'apr' so that pkg upgrade does not clobber
> apr,  and this has worked so far.
> 
> Just an observation.

Yes, absolutely.  The configurability with the ports tree is one of it's
major benefits, and yet also a significant hindrance in many circumstances.

Cheers,

Matthew






signature.asc
Description: OpenPGP digital signature

Re: BIND REPLACE_BASE option

[Kurt Jaeger]

Hi!

> customizations you need available.  If the default options don't cut it
> for you, in order to use only binary packages that means you need to run
> your own poudriere setup -- which is well worth it if you're managing
> several machines / jails etc.

poudriere allows you to manage several seperate pkg trees with different
options, so you can:

- build a default tree (and pkg repo), provide it to all generic hosts
- build a seperate tree (and pkg repo) with modified options, and
  provide it to the special hosts

It helps to keep the poudriere build tree on fast flash/SSD drives 8-}

This all works and is very, very good! Thanks for the work!

-- 
p...@opsec.eu+49 171 3101372 5 years to go !
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Chris H]

On Tue, 13 Jan 2015 16:55:53 +0100 Kurt Jaeger  wrote

> Hi!
> 
> > customizations you need available.  If the default options don't cut it
> > for you, in order to use only binary packages that means you need to run
> > your own poudriere setup -- which is well worth it if you're managing
> > several machines / jails etc.
> 
> poudriere allows you to manage several seperate pkg trees with different
> options, so you can:
> 
> - build a default tree (and pkg repo), provide it to all generic hosts
> - build a seperate tree (and pkg repo) with modified options, and
>   provide it to the special hosts
I use a similar, but somewhat different strategy. Which works
nice if you have any spare hardware available.
I simply use a fresh install of whatever RELEASE/RELENG I'm chasing.
 * create a dump(8) to external storage
 * build/install (custom) world/kernel
 * (batch) build install clean ports with desired options
 * dump to external storage

 * restore to target host/machine
and as Kurt mentioned; flash/SSD media *is* the way to go! :)

I ended up going this route because I found the builds ran
quicker, and it all ended up being a bit "tidier". Also makes it
trivial to "rollback" to any chosen revision.

--Chris
> 
> It helps to keep the poudriere build tree on fast flash/SSD drives 8-}
> 
> This all works and is very, very good! Thanks for the work!
> 
> -- 
> p...@opsec.eu+49 171 3101372 5 years to go
> ! ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Roger Marquis]

Mathieu Arnold wrote:

I'm only going to answer that part, the rest of the thread being, I feel,
mostly FUD.
...
The BIND ports were in such a miserable way, with kludges everywhere, when
I took over that it took me some time to get them right.


I wish people wouldn't make statements like this.  The thread has been
informative in many ways and clearly not FUD.  I also wish people would
not insult previous base and port maintainers by labelling their work
buggy or kludgy.  All code has bugs.  Even having a REPLACE_BASE that
only prints "REPLACE_BASE is no longer supported" can be considered a
bug.  Having two identically named binaries on a system that differ only
by path and version can also be considered a kludge (not to mention a
security issue).

While I'm not personally impacted by the bind port's deprecation of
REPLACE_BASE clearly others are.  As Doug pointed out this option has
been around for well over a decade and like other ports with a
REPLACE_BASE option has saved FreeBSD admins a lot of work in
cross-platform environments.

One question while we're on the topic of deprecations, has 'make pkg ||
make package' been deprecated in favor of poudriere?

Roger
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Mathieu Arnold]

+--On 13 janvier 2015 08:33:13 -0800 Roger Marquis 
wrote:
| Even having a REPLACE_BASE that
| only prints "REPLACE_BASE is no longer supported" can be considered a
| bug.

Would you rather the port installing BIND in /usr/local without telling you
anything, silently breaking your installation completely ?

I thought people would rather have the port telling them the option is no
longer supported so that they can fix their installation before it blows
up.  But maybe it's just me.

-- 
Mathieu Arnold
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Roger Marquis]

Mathieu Arnold wrote:
> Would you rather the port installing BIND in /usr/local without telling you
> anything, silently breaking your installation completely ?

Certainly not but it's unprofessional to present the end-user with a dialog
option that can be selected only to subsequently inform them that the option
is deprecated.  It might take a little programming but the error message
printed when one port would overwrite files installed by another would, IMO,
be better i.e., recommending removal of the conflict before installation.

Roger

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Mathieu Arnold]

+--On 13 janvier 2015 15:39:47 -0800 Roger Marquis 
wrote:
| Mathieu Arnold wrote:
|> Would you rather the port installing BIND in /usr/local without telling
|> you anything, silently breaking your installation completely ?
| 
| Certainly not but it's unprofessional to present the end-user with a
| dialog option that can be selected only to subsequently inform them that
| the option is deprecated.  It might take a little programming but the
| error message printed when one port would overwrite files installed by
| another would, IMO, be better i.e., recommending removal of the conflict
| before installation.

The dialog option you talk about says:

   [ ] REPLACE_BASEEOL, no longer supported

I'm quite sure the end-user you're talking about can get a clue from it,
and if he either already had selected it before, or he just selected it, he
will get:

  ===>  bind99-9.9.6P1_3 REPLACE_BASE is no longer supported.

The end-user can then get another clue and maybe unselect it.

Regards,

-- 
Mathieu Arnold
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Roger Marquis]

The dialog option you talk about says:
  [ ] REPLACE_BASEEOL, no longer supported
I'm quite sure the end-user you're talking about can get a clue from it,
and if he either already had selected it before, or he just selected it, he
will get:
 ===>  bind99-9.9.6P1_3 REPLACE_BASE is no longer supported.
The end-user can then get another clue and maybe unselect it.


Maybe you're right but, to perhaps better illustrate the point, you would
never see something like this in Ubuntu, Debian, Redhat, or SuSE.

Roger
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Russell L. Carter]

On 01/13/15 20:11, Roger Marquis wrote:

The dialog option you talk about says:
  [ ] REPLACE_BASEEOL, no longer supported
I'm quite sure the end-user you're talking about can get a clue from it,
and if he either already had selected it before, or he just selected
it, he
will get:
 ===>  bind99-9.9.6P1_3 REPLACE_BASE is no longer supported.
The end-user can then get another clue and maybe unselect it.


Maybe you're right but, to perhaps better illustrate the point, you would
never see something like this in Ubuntu, Debian, Redhat, or SuSE.


I agree but lets back out just a bit.  This fundamentally sound pkg
infrastructure is very new to FreeBSD, and it completely rocks.  As
much as I grit my teeth over certain road bumps I have to acknowledge
that local customizable binary repos... well that's fantastic.

But that's the infrastructure.  People take time to learn what having
such an infrastructure really means in terms of the expectations of
developers looking toward users, and users looking into packages (and
not necessarily caring if a developer even exists).

It took a very long time for those linux distros to get their pkg
upgrade process as smooth as it is now, and a large part of that time
was spent acculterating the individual pkg maintainers (an evolving
population) into the idea that an installed pkg should continue to
"just work" if it already does.  If it can't continue to "just work",
then there are lots of handholding instructions suitable for very
stupid people generally provided, as barriers, during the upgrade
process.  All that extra packaging effort is devoted by far to the
clueless (sometimes willfully clueless) fraction of the luser base.
It's apparent that the FreeBSD community in the main does not have
that mentality now.  It's part of the attraction, to be clear, myself
included.  But now with superb package management capabilities in
place, I think we will see, over a decade or so, the same sort of
smoothness that the best linux distros display gradually emerge in
FreeBSD.  Craig R is a hero here.

In the meantime I'm going to be trying harder to cut the pkg
maintainers more slack.  It's a sometimes hard, mostly thankless job
that is absolutely crucial.

2c,
Russell


Roger
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Chris H]

On Tue, 13 Jan 2015 19:11:50 -0800 (PST) Roger Marquis 
wrote

> > The dialog option you talk about says:
> >   [ ] REPLACE_BASEEOL, no longer supported
> > I'm quite sure the end-user you're talking about can get a clue from it,
> > and if he either already had selected it before, or he just selected it, he
> > will get:
> >  ===>  bind99-9.9.6P1_3 REPLACE_BASE is no longer supported.
> > The end-user can then get another clue and maybe unselect it.
> 
> Maybe you're right but, to perhaps better illustrate the point, you would
> never see something like this in Ubuntu, Debian, Redhat, or SuSE.
Honestly. Need I remind you, this is FreeBSD, *not* Linux?
In all honesty, I am *not* pleased with the current efforts to
turn the FreeBSD motto "The Power to Serve" into
"FreeBSD, it's the new Linux". But I [begrudgingly] understand the
inclination to do so.
That said. While I understand your inclination to think FreeBSD
must somehow be broken, when it doesn't operate as you're accustomed
with Linux. This is FreeBSD, after all, and as hard as everyone works
to eliminate the element of surprise, this is still FreeBSD.
So celebrate the difference. Don't curse it, or more importantly;
it's hard working developers. :)

--Chris
> 
> Roger
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Royce Williams]

On Tue, Jan 13, 2015 at 7:15 PM, Chris H  wrote:
> On Tue, 13 Jan 2015 19:11:50 -0800 (PST) Roger Marquis 
> wrote
>
>> > The dialog option you talk about says:
>> >   [ ] REPLACE_BASEEOL, no longer supported
>> > I'm quite sure the end-user you're talking about can get a clue from it,
>> > and if he either already had selected it before, or he just selected it, he
>> > will get:
>> >  ===>  bind99-9.9.6P1_3 REPLACE_BASE is no longer supported.
>> > The end-user can then get another clue and maybe unselect it.
>>
>> Maybe you're right but, to perhaps better illustrate the point, you would
>> never see something like this in Ubuntu, Debian, Redhat, or SuSE.
> Honestly. Need I remind you, this is FreeBSD, *not* Linux?
> In all honesty, I am *not* pleased with the current efforts to
> turn the FreeBSD motto "The Power to Serve" into
> "FreeBSD, it's the new Linux". But I [begrudgingly] understand the
> inclination to do so.

The Power to Serve can only be brought to bear if a small-shop
sysadmin isn't afraid to touch their ports.

> That said. While I understand your inclination to think FreeBSD
> must somehow be broken, when it doesn't operate as you're accustomed
> with Linux. This is FreeBSD, after all, and as hard as everyone works
> to eliminate the element of surprise, this is still FreeBSD.
> So celebrate the difference. Don't curse it, or more importantly;
> it's hard working developers. :)

None of this is intended to disparage the teams.

Royce
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Erwin Lansing]

On Tue, Jan 13, 2015 at 08:33:13AM -0800, Roger Marquis wrote:
> 
> One question while we're on the topic of deprecations, has 'make pkg ||
> make package' been deprecated in favor of poudriere?
> 

No, they serve to completely different purposes, though there is some
overlap.  Poudriere is a self-contained build system that can be used to
bulk build any number of packages that can be used on any number of
other systems.  This is very useful if you need different features or
options than the packages provided by the FreeBSD project.  "make
package" will build a single package of one port from the system it is
run from.  That means that the port, and all of its dependencies, will
be installed on the host.  Depending on your needs, this can be a good
or a bad thing.  They're two completely different beasts and neither can
replace the other.

Erwin

-- 
Erwin Lansinghttp://droso.dk
er...@freebsd.orghttp:// www.FreeBSD.org


pgpeD1nmt8Wy7.pgp
Description: PGP signature

Re: BIND REPLACE_BASE option

[Mathieu Arnold]

+--On 13 janvier 2015 19:11:50 -0800 Roger Marquis 
wrote:
|> The dialog option you talk about says:
|>   [ ] REPLACE_BASEEOL, no longer supported
|> I'm quite sure the end-user you're talking about can get a clue from it,
|> and if he either already had selected it before, or he just selected it,
|> he will get:
|>  ===>  bind99-9.9.6P1_3 REPLACE_BASE is no longer supported.
|> The end-user can then get another clue and maybe unselect it.
| 
| Maybe you're right but, to perhaps better illustrate the point, you would
| never see something like this in Ubuntu, Debian, Redhat, or SuSE.

Well, like I said, REPLACE_BASE was an abomination that should never have
existed, now that it's gone, it'll never get back, and you'll never see it
again.

-- 
Mathieu Arnold
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Matt Smith]

On Jan 14 12:15, Mathieu Arnold wrote:


Well, like I said, REPLACE_BASE was an abomination that should never have
existed, now that it's gone, it'll never get back, and you'll never see it
again.



Doug Barton who used to maintain BIND in both the base system and the 
port used to always say that the version in the base system was only 
designed to be used as a local resolver on a laptop/desktop. If it was 
used as a proper DNS server the port version was meant to be used 
instead. Based on this it makes perfect sense why BIND was replaced with 
local Unbound in the base, and the ports system still has BIND for 
people that were using it.


It should have been a very small minor change. If people didn't want to 
have two versions installed then the solution would have been to use 
WITHOUT_NAMED or WITHOUT_BIND whatever the knob was in src.conf so that 
those files were deleted or not installed in the first place. I do 
exactly this for NTPd, OpenSSH, and Unbound all of which I use the port 
versions for so don't need them in the base system.


--
Matt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Jeffrey Bouquet via freebsd-ports]

On 01/13/15 07:55, Kurt Jaeger wrote:
> Hi!
>
>> customizations you need available.  If the default options don't cut it
>> for you, in order to use only binary packages that means you need to run
>> your own poudriere setup -- which is well worth it if you're managing
>> several machines / jails etc.
> poudriere allows you to manage several seperate pkg trees with different
> options, so you can:
>
> - build a default tree (and pkg repo), provide it to all generic hosts
> - build a seperate tree (and pkg repo) with modified options, and
>   provide it to the special hosts
>
> It helps to keep the poudriere build tree on fast flash/SSD drives 8-}
>
> This all works and is very, very good! Thanks for the work!
>
As I probably won't ever know enough from experience, if one wants a
local lan
build tool is there any flowchart with use cases

1... foo foo bar use case >> tinderbox
2... foo foo bar use case >> build jail
3... foo foo bar use case >> bhyve
4... foo foo bar use case >> poudriere
5... foo foo bar use case >> csbd OR qjail OR ezjail OR man jail OR
bastille script
6... foo foo bar use case >> server on lan serving packages

And where they may overlap, which takes the least setup time, which
takes the
least maintenance time, which can be most easily migrated version >
version ...



Not to mention the wiki, but if that information was "[some term ] use
cases" like
virtualization or multi-machine or... on the freebsd.org page
prominently, it may
result in a larger userbase... more coders onboard.

Recognizing that a lot of this is emerging technology.  Apologies.  I've
a slight
interest in reading any such document, having read an hour or so
yesterday not
a few htm explaining jails, (10 pages of threads linked from
a search 'ezjail' in the forums, for example) to know that acquiring the
expertise of
a quickstart group of terms to focus on in any particular scenario is
something I don't
easily expect to acquire.

On the other hand, to include the wiki... vs links from it.


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Michelle Sullivan]

Matt Smith wrote:
> On Jan 14 12:15, Mathieu Arnold wrote:
>>
>> Well, like I said, REPLACE_BASE was an abomination that should never
>> have
>> existed, now that it's gone, it'll never get back, and you'll never
>> see it
>> again.
>>
>
> Doug Barton who used to maintain BIND in both the base system and the
> port used to always say that the version in the base system was only
> designed to be used as a local resolver on a laptop/desktop. If it was
> used as a proper DNS server the port version was meant to be used
> instead. Based on this it makes perfect sense why BIND was replaced
> with local Unbound in the base, and the ports system still has BIND
> for people that were using it.

Was this ever documented? (I've been using bind in base for servers for
many years and this is the first time I've heard of it - and it is
unlikely I'm the only one.)

>
> It should have been a very small minor change. If people didn't want
> to have two versions installed then the solution would have been to
> use WITHOUT_NAMED or WITHOUT_BIND whatever the knob was in src.conf so
> that those files were deleted or not installed in the first place. I
> do exactly this for NTPd, OpenSSH, and Unbound all of which I use the
> port versions for so don't need them in the base system.
>
..and for those using freebsd-update?

Oh and on setting up named after installing from ports it gets chrooted
and it has 'problems' seems the chroot mechanism chroots/links in
/etc/namedb rather than /usr/local/etc/namedb ... haven't fully gotten
to the bottom of it yet, but currently on all machines after
freebsd-update (and possibly new installs of 9.3) I ended up creating
links between /var/named/usr/local/etc/namedb/named.conf and
/usr/local/etc/namedb/named.conf and /etc/namedb/named.conf to get it
working.. so something is 'odd' in the mean time my deployment script
has been modified to create all the links to get it working so stopped
looking at it for the moment.

Michelle

-- 
Michelle Sullivan
http://www.mhix.org/

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Matt Smith]

On Jan 14 13:30, Michelle Sullivan wrote:

Matt Smith wrote:

Doug Barton who used to maintain BIND in both the base system and the
port used to always say that the version in the base system was only
designed to be used as a local resolver on a laptop/desktop. If it was
used as a proper DNS server the port version was meant to be used
instead. Based on this it makes perfect sense why BIND was replaced
with local Unbound in the base, and the ports system still has BIND
for people that were using it.


Was this ever documented? (I've been using bind in base for servers for
many years and this is the first time I've heard of it - and it is
unlikely I'm the only one.)



I'm not sure if it was documented anywhere in particular. I've just seen 
it mentioned lots of times on these mailing lists in the past.  
Specifically around the time he was experimenting with slaving the root 
and arpa zones and there were a few configuration changes to named.conf 
at that time.


The main reasoning is that the versions of things in the base system are 
usually old and rarely get updated. They occasionally get patches if 
there's a serious security vulnerability but for minor bugs it's 
unlikely you'll see any patch. And to patch it you quite often need to 
do a full O/S upgrade which is very time consuming and probably needs a 
reboot. The port versions are updated straight away, even for minor bugs 
and because you've not also updated half the O/S in the process you 
don't need to do anything other than restart named.


--
Matt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Michelle Sullivan]

Matt Smith wrote:
> On Jan 14 13:30, Michelle Sullivan wrote:
>> Matt Smith wrote:
>>> Doug Barton who used to maintain BIND in both the base system and the
>>> port used to always say that the version in the base system was only
>>> designed to be used as a local resolver on a laptop/desktop. If it was
>>> used as a proper DNS server the port version was meant to be used
>>> instead. Based on this it makes perfect sense why BIND was replaced
>>> with local Unbound in the base, and the ports system still has BIND
>>> for people that were using it.
>>
>> Was this ever documented? (I've been using bind in base for servers for
>> many years and this is the first time I've heard of it - and it is
>> unlikely I'm the only one.)
>>
>
> I'm not sure if it was documented anywhere in particular. I've just
> seen it mentioned lots of times on these mailing lists in the past. 
> Specifically around the time he was experimenting with slaving the
> root and arpa zones and there were a few configuration changes to
> named.conf at that time.
>
> The main reasoning is that the versions of things in the base system
> are usually old and rarely get updated. They occasionally get patches
> if there's a serious security vulnerability but for minor bugs it's
> unlikely you'll see any patch. And to patch it you quite often need to
> do a full O/S upgrade which is very time consuming and probably needs
> a reboot. The port versions are updated straight away, even for minor
> bugs and because you've not also updated half the O/S in the process
> you don't need to do anything other than restart named.
>
And that is precisely the reason I used the 'REPLACE_BASE' option...

BTW, what happens if you /usr/local/etc/rc.d/named start and
/etc/rc.d/named start now (particularly the latter) ? ... I'm assuming
some thought of this and removed /etc/rc.d/named as part of a
freebsd-update ...? (note: some of use cannot 'freebsd-update' the
'delete-old' stuff because some  got it also to
delete the pkg_* tools - which some of us have to use currently -
despite that same  attempting to force production
systems into untested configurations... even when patching exploits.

Regards,

-- 
Michelle Sullivan
http://www.mhix.org/

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Roger Marquis]

Thank you Matt.  It is refreshing to hear an actual business case for the
reasons REPLACE_BASE was created.  Thank you also for the pointers to a
way of avoid dulpicate binaries.  Do you know of more detailed
documentation on how to prevent installworld and freebsd-update from
installing these binaries in the first place?

That leaves the issue of cross-platform compatibility, which is still
broken without REPLACE_BASE.  What about those of us who support
environments that aren't BSD monocultures?

Roger Marquis




Well, like I said, REPLACE_BASE was an abomination that should never have
existed, now that it's gone, it'll never get back, and you'll never see it
again.


Doug Barton who used to maintain BIND in both the base system and the port 
used to always say that the version in the base system was only designed to 
be used as a local resolver on a laptop/desktop. If it was used as a proper 
DNS server the port version was meant to be used instead. Based on this it 
makes perfect sense why BIND was replaced with local Unbound in the base, and 
the ports system still has BIND for people that were using it.


It should have been a very small minor change. If people didn't want to have 
two versions installed then the solution would have been to use WITHOUT_NAMED 
or WITHOUT_BIND whatever the knob was in src.conf so that those files were 
deleted or not installed in the first place. I do exactly this for NTPd, 
OpenSSH, and Unbound all of which I use the port versions for so don't need 
them in the base system.

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Mathieu Arnold]

+--On 14 janvier 2015 07:23:01 -0800 Roger Marquis 
wrote:
| That leaves the issue of cross-platform compatibility, which is still
| broken without REPLACE_BASE.  What about those of us who support
| environments that aren't BSD monocultures?

By using the named_conf variable in /etc/rc.conf ?

-- 
Mathieu Arnold
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Roger Marquis]

On Tue, Jan 13, 2015 at 08:33:13AM -0800, Roger Marquis wrote:
... Poudriere is a self-contained build system that can be used to
bulk build any number of packages that can be used on any number of
other systems.  This is very useful if you need different features or
options than the packages provided by the FreeBSD project.  "make
package" will build a single package of one port from the system it is
run from.


The packages built by "make package" can also be used on any number of
other systems, like those built by Poudriere.

  That means that the port, and all of its dependencies, will

be installed on the host.  Depending on your needs, this can be a good
or a bad thing.  They're two completely different beasts and neither can
replace the other.


So one difference then would be that Poudriere determines which
dependencies are run-time vs build-time and creates packages for those by
default, is that correct?  I can see how that might be convenient for
packages with a large number of dependencies (like sssd) but it also
seems like a lot of additional infrastructure simply to build binaries on
one host to be used by many.

Roger
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Roger Marquis]

Maybe you're right but, to perhaps better illustrate the point, you would
never see something like this in Ubuntu, Debian, Redhat, or SuSE.


Honestly. Need I remind you, this is FreeBSD, *not* Linux?
In all honesty, I am *not* pleased with the current efforts to
turn the FreeBSD motto "The Power to Serve" into
"FreeBSD, it's the new Linux". But I [begrudgingly] understand the
inclination to do so.


Amen to that.  I also think a lot of people expect that emulating Linux'
binary package systems will stop our favorite OS' declining market share.
Unfortunately, there's a lot more to it.  FreeBSD has had binary packages
for years and they haven't had the desired effect.

What's missing is perhaps an understanding of what Linux differences
account for its success over FreeBSD.  Clearly the topic of this thread,
deprecating REPLACE_BASE, isn't going to help in this regards.  Portsng
and pkgng aren't helping yet either though their improvements have laid
the foundation for easier coding of new features (like better dependency
tracking, a non-cli menu, ad-hoc queries, ...).


That said. While I understand your inclination to think FreeBSD
must somehow be broken, when it doesn't operate as you're accustomed
with Linux.


Not my inclination :-)  Please take care with those attributes.


This is FreeBSD, after all, and as hard as everyone works
to eliminate the element of surprise, this is still FreeBSD.
So celebrate the difference. Don't curse it, or more importantly;
it's hard working developers. :)


I trust we are _all_ grateful to the developers who are doing a good job,
at least when not deprecating popular features and responding to the
resulting end-user frustration with statements like "REPLACE_BASE was an
abomination that should never have existed, now that it's gone, it'll
never get back, and you'll never see it again".  The hard work that goes
into so many ports _is_ BSD's primary advantage over Linux backed-up by
ZFS, jails, security and the BSD license.  Personally I believe that a
lot of this differential is due to the GPL which doesn't allow Linux
deltas to propagate back to BSD but nobody seems to be discussing way of
addressing this (like a CDDL BSD perhaps).

But getting back to the meta-topic i.e., where BSDs are at a
disadvantage, has anyone here used kickstart, satellite, sssd, IPA,
gparted, synaptic, a "live desktop" DVD or the Ubuntu GUI installer?

Roger Marquis
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Matthew Seaman]

On 2015/01/14 15:34, Roger Marquis wrote:
> So one difference then would be that Poudriere determines which
> dependencies are run-time vs build-time and creates packages for those by
> default, is that correct?  I can see how that might be convenient for
> packages with a large number of dependencies (like sssd) but it also
> seems like a lot of additional infrastructure simply to build binaries on
> one host to be used by many.

Poudriere by definition will create packages for all of the build- and
run-depends, as it needs the build-depends packages itself in order to
build everything.  It builds everything in temporary jails which it
installs all the needed dependencies to, and then destroys after that
package has been built.

However, when you go to install a package from the repo, pkg(8) will
only pull down the run-time dependencies of whatever you choose to
install.  That means there are a good chunk of packages you simply don't
need to have on your production servers any more.

Yes, poudriere does a lot of stuff, but if you didn't use a central
builder, you'ld end up replicating all of that stuff onto every machine
you wanted to manage.  Poudriere itself can run on a fairly modest
machine -- it depends on how many packages you need to build and how
quickly you want them.  It's quite feasible to use poudriere for a
small-ish repo on a machine at night, when it is otherwise quiet, and
then use the same machine for something else during the day.

Cheers,

Matthew


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Roger Marquis]

Mathieu Arnold wrote:

| That leaves the issue of cross-platform compatibility, which is still
| broken without REPLACE_BASE.  What about those of us who support
| environments that aren't BSD monocultures?

By using the named_conf variable in /etc/rc.conf ?


That enables configuration compatibility but doesn't address binaries or
their PATHs.

Named perhaps isn't the best example of a port with cross-platform
issues.  Postfix, OTOH, is a different animal.  I spent countless hours
trying to accommodate the default BSD PREFIX, usually just installing
from source without using ports, before paying Doug to write a patch for
postfix' INST_BASE option.  That investment has paid of manyfold over the
years.  Even more effort was put into porting freepbx but that effort
failed specifically due to cross-platform (PREFIX) issues, resulting in
several RH servers in an otherwise BSD shop.

Roger
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Roger Marquis]

Matthew Seaman wrote:

Yes, poudriere does a lot of stuff, but if you didn't use a central
builder, you'ld end up replicating all of that stuff onto every machine
you wanted to manage.


What stuff would you end up replicating?  I ask because our "make
package" host don't replicate anything other than the required binaries,
libraries and configs.

Roger
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Vince Hoffman]

On 14/01/2015 16:34, Roger Marquis wrote:
> Matthew Seaman wrote:
>> Yes, poudriere does a lot of stuff, but if you didn't use a central
>> builder, you'ld end up replicating all of that stuff onto every machine
>> you wanted to manage.
>
> What stuff would you end up replicating?  I ask because our "make
> package" host don't replicate anything other than the required binaries,
> libraries and configs.
This implies you are already using a central build host? Matthew's reply
was talking about replicating build-depends packages if you build on
each host separately.

The advantage for me for using poudriere has been I use one machine to
build 8.x 9.x and 10.x packages with a few flavours of each, its in a
nice easy to use form and builds the repos (which I serve via nginx) and
it handles all the jails/updating etc for me. Nothing I couldnt do
manually sure but saves me time and effort. I just need to remember to
check for new ports options from time to time.

Vince
>
> Roger
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Chris H]

On Wed, 14 Jan 2015 04:27:42 -0800 Jeffrey Bouquet via freebsd-ports
 wrote

> On 01/13/15 07:55, Kurt Jaeger wrote:
> > Hi!
> >
> >> customizations you need available.  If the default options don't cut it
> >> for you, in order to use only binary packages that means you need to run
> >> your own poudriere setup -- which is well worth it if you're managing
> >> several machines / jails etc.
> > poudriere allows you to manage several seperate pkg trees with different
> > options, so you can:
> >
> > - build a default tree (and pkg repo), provide it to all generic hosts
> > - build a seperate tree (and pkg repo) with modified options, and
> >   provide it to the special hosts
> >
> > It helps to keep the poudriere build tree on fast flash/SSD drives 8-}
> >
> > This all works and is very, very good! Thanks for the work!
> >
> As I probably won't ever know enough from experience, if one wants a
> local lan
> build tool is there any flowchart with use cases
> 
> 1... foo foo bar use case >> tinderbox
> 2... foo foo bar use case >> build jail
> 3... foo foo bar use case >> bhyve
> 4... foo foo bar use case >> poudriere
> 5... foo foo bar use case >> csbd OR qjail OR ezjail OR man jail OR
> bastille script
> 6... foo foo bar use case >> server on lan serving packages
> 
> And where they may overlap, which takes the least setup time, which
> takes the
> least maintenance time, which can be most easily migrated version >
> version ...
Excellent observation. These look like prime "install candidates".
A sort of meta-install, much like a Server, or Desktop install is
already. Maybe someone with good install-foo could easily cobble up
appropriate scripts to accommodate such a thing.

Thanks for bringing it up, Jeffrey!

--Chris
> 
> 
> 
> Not to mention the wiki, but if that information was "[some term ] use
> cases" like
> virtualization or multi-machine or... on the freebsd.org page
> prominently, it may
> result in a larger userbase... more coders onboard.
> 
> Recognizing that a lot of this is emerging technology.  Apologies.  I've
> a slight
> interest in reading any such document, having read an hour or so
> yesterday not
> a few htm explaining jails, (10 pages of threads linked from
> a search 'ezjail' in the forums, for example) to know that acquiring the
> expertise of
> a quickstart group of terms to focus on in any particular scenario is
> something I don't
> easily expect to acquire.
> 
> On the other hand, to include the wiki... vs links from it.
> 
> 
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Chris H]

On Wed, 14 Jan 2015 08:11:39 -0800 (PST) Roger Marquis 
wrote

> >> Maybe you're right but, to perhaps better illustrate the point, you would
> >> never see something like this in Ubuntu, Debian, Redhat, or SuSE.
> >
> > Honestly. Need I remind you, this is FreeBSD, *not* Linux?
> > In all honesty, I am *not* pleased with the current efforts to
> > turn the FreeBSD motto "The Power to Serve" into
> > "FreeBSD, it's the new Linux". But I [begrudgingly] understand the
> > inclination to do so.
> 
> Amen to that.  I also think a lot of people expect that emulating Linux'
> binary package systems will stop our favorite OS' declining market share.
> Unfortunately, there's a lot more to it.  FreeBSD has had binary packages
> for years and they haven't had the desired effect.
> 
> What's missing is perhaps an understanding of what Linux differences
> account for its success over FreeBSD.  Clearly the topic of this thread,
> deprecating REPLACE_BASE, isn't going to help in this regards.  Portsng
> and pkgng aren't helping yet either though their improvements have laid
> the foundation for easier coding of new features (like better dependency
> tracking, a non-cli menu, ad-hoc queries, ...).
> 
> > That said. While I understand your inclination to think FreeBSD
> > must somehow be broken, when it doesn't operate as you're accustomed
> > with Linux.
> 
> Not my inclination :-)  Please take care with those attributes.
Fair enough. My entire reply was *intended* to be light hearted.
But like you, I *too* have some issues with some of the decisions
made. I'm afraid I let that influence my reply. Sorry.
> 
> > This is FreeBSD, after all, and as hard as everyone works
> > to eliminate the element of surprise, this is still FreeBSD.
> > So celebrate the difference. Don't curse it, or more importantly;
> > it's hard working developers. :)
> 
> I trust we are _all_ grateful to the developers who are doing a good job,
> at least when not deprecating popular features and responding to the
> resulting end-user frustration with statements like "REPLACE_BASE was an
> abomination that should never have existed, now that it's gone, it'll
> never get back, and you'll never see it again".  The hard work that goes
> into so many ports _is_ BSD's primary advantage over Linux backed-up by
> ZFS, jails, security and the BSD license.  Personally I believe that a
> lot of this differential is due to the GPL which doesn't allow Linux
> deltas to propagate back to BSD but nobody seems to be discussing way of
> addressing this (like a CDDL BSD perhaps).
IMHO it's still too early to tell whether all the big changes made
during 2014 will, or have had, the positive, or desired affect intended.
But for sure, it's been a *wild* ride for many of us.
> 
> But getting back to the meta-topic i.e., where BSDs are at a
> disadvantage, has anyone here used kickstart, satellite, sssd, IPA,
> gparted, synaptic, a "live desktop" DVD or the Ubuntu GUI installer?
Thanks for your *thoughtful* reply, Roger.

--Chris
> 
> Roger Marquis
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
---


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Chris H]

On Wed, 14 Jan 2015 16:18:07 + Matthew Seaman  wrote

> On 2015/01/14 15:34, Roger Marquis wrote:
> > So one difference then would be that Poudriere determines which
> > dependencies are run-time vs build-time and creates packages for those by
> > default, is that correct?  I can see how that might be convenient for
> > packages with a large number of dependencies (like sssd) but it also
> > seems like a lot of additional infrastructure simply to build binaries on
> > one host to be used by many.
> 
> Poudriere by definition will create packages for all of the build- and
> run-depends, as it needs the build-depends packages itself in order to
> build everything.  It builds everything in temporary jails which it
> installs all the needed dependencies to, and then destroys after that
> package has been built.
> 
> However, when you go to install a package from the repo, pkg(8) will
> only pull down the run-time dependencies of whatever you choose to
> install.  That means there are a good chunk of packages you simply don't
> need to have on your production servers any more.
> 
> Yes, poudriere does a lot of stuff, but if you didn't use a central
> builder, you'ld end up replicating all of that stuff onto every machine
> you wanted to manage.  Poudriere itself can run on a fairly modest
> machine -- it depends on how many packages you need to build and how
> quickly you want them.  It's quite feasible to use poudriere for a
> small-ish repo on a machine at night, when it is otherwise quiet, and
> then use the same machine for something else during the day.
This might be a good place to put some links to how-to's for common
use-cases for poudriere. I see questions like this quite often on the
lists, and in the forums. Anyone have one?

--Chris
> 
> Cheers,
> 
> Matthew
> 
> 
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Erwin Lansing]

Hi Roger,

On Wed, Jan 14, 2015 at 08:34:35AM -0800, Roger Marquis wrote:
> Matthew Seaman wrote:
> > Yes, poudriere does a lot of stuff, but if you didn't use a central
> > builder, you'ld end up replicating all of that stuff onto every machine
> > you wanted to manage.
> 
> What stuff would you end up replicating?  I ask because our "make
> package" host don't replicate anything other than the required binaries,
> libraries and configs.
> 

This sounds like you, like many other people have done in the past, have
built an in-house solution based on the tools available at the time,
which includes 'make package', but you probably have other tools around
it to deal with the distribution.  In that case, there's no reason
for you to change anything.  If you in-house solution works for you,
keep using it.  Poudriere can provide the same functionality out of the
box, and would be my first recommendation for people starting a local
package repository, but if you already have a system in place, there's
probably no need to spend time to migrate to poudriere.

Erwin

-- 
Erwin Lansinghttp://droso.dk
er...@freebsd.orghttp:// www.FreeBSD.org


pgp8KYMwKlG87.pgp
Description: PGP signature

Re: BIND REPLACE_BASE option

[Roger Marquis]

This sounds like you, like many other people have done in the past, have
built an in-house solution based on the tools available at the time,
which includes 'make package'


I wouldn't call it an in-house solution since the package target is a
feature of the ports infrastructure.  We simply 'make package' and
install other systems from the resulting package.

This does not, however, appear to be as well supported by portsng/pkgng
as it was in the previous versions.  Now it just exits with no message
and a 0 exit-code without creating the package unless you've created
/usr/ports/packages and/or specified one or more of WRKDIRPREFIX,
PACKAGES and PKGREPOSITORY.

What documentation there is seems to be based on older versions (like
much of the FreeBSD website) and I haven't found anything on the
differences between 'make package' and Poudriere.

Roger
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Patrick Powell]

On 01/15/15 09:00, Roger Marquis wrote:

This sounds like you, like many other people have done in the past, have
built an in-house solution based on the tools available at the time,
which includes 'make package'


I wouldn't call it an in-house solution since the package target is a
feature of the ports infrastructure.  We simply 'make package' and
install other systems from the resulting package.

This does not, however, appear to be as well supported by portsng/pkgng
as it was in the previous versions.  Now it just exits with no message
and a 0 exit-code without creating the package unless you've created
/usr/ports/packages and/or specified one or more of WRKDIRPREFIX,
PACKAGES and PKGREPOSITORY.

What documentation there is seems to be based on older versions (like
much of the FreeBSD website) and I haven't found anything on the
differences between 'make package' and Poudriere.

Roger
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

This is actually a side effect of the STAGING implementation.  The 
package file is put into the
port (created) work sub directory.   Now if I could only find the 
documentation that tells me how to put, say,
WORK_DIRECTORY=/var/tmp/work  into the /etc/make.conf file or something 
similar I would be
a very (well, not so grumpy) happy camper.  I read this somewhere once 
but I cannot find

it again.  WRKDIRPREFIX?  WORKDIRPREFIX?

--
Patrick Powell Astart Technologies
papow...@astart.com1530 Jamacha Rd, Suite X
Network and System San Diego, CA 92019
  Consulting   858-874-6543 FAX 858-751-2435
Web: www.astart.com

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Vince Hoffman]

On 16/01/2015 15:51, Patrick Powell wrote:
> On 01/15/15 09:00, Roger Marquis wrote:
>>> This sounds like you, like many other people have done in the past,
>>> have
>>> built an in-house solution based on the tools available at the time,
>>> which includes 'make package'
>>
>> I wouldn't call it an in-house solution since the package target is a
>> feature of the ports infrastructure.  We simply 'make package' and
>> install other systems from the resulting package.
>>
>> This does not, however, appear to be as well supported by portsng/pkgng
>> as it was in the previous versions.  Now it just exits with no message
>> and a 0 exit-code without creating the package unless you've created
>> /usr/ports/packages and/or specified one or more of WRKDIRPREFIX,
>> PACKAGES and PKGREPOSITORY.
>>
>> What documentation there is seems to be based on older versions (like
>> much of the FreeBSD website) and I haven't found anything on the
>> differences between 'make package' and Poudriere.
>>
>> Roger
>> ___
>> freebsd-ports@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>>
> This is actually a side effect of the STAGING implementation.  The
> package file is put into the
> port (created) work sub directory.   Now if I could only find the
> documentation that tells me how to put, say,
> WORK_DIRECTORY=/var/tmp/work  into the /etc/make.conf file or
> something similar I would be
> a very (well, not so grumpy) happy camper.  I read this somewhere once
> but I cannot find
> it again.  WRKDIRPREFIX?  WORKDIRPREFIX?
>
>From looking in /usr/ports/Mk/bsd.port.mk
I think you want to set one of the following in make.conf

# WRKDIRPREFIX  - The place to root the temporary working directory
# hierarchy.
# Default: none
# WRKDIR- A temporary working directory that gets
*clobbered* on clean
# Default: ${WRKDIRPREFIX}${.CURDIR}/work

not the most intuitive place to look but I guess thats why the BUGS
section of PORTS(7) says
BUGS
 Ports documentation is split over four places --
 /usr/ports/Mk/bsd.port.mk, The Porter's Handbook, the ``Packages and
 Ports'' chapter of The FreeBSD Handbook, and this manual page.



Vince

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Dewayne Geraghty]

On 17/01/2015 2:51 AM, Patrick Powell wrote:
> On 01/15/15 09:00, Roger Marquis wrote:
>>> This sounds like you, like many other people have done in the past,
>>> have
>>> built an in-house solution based on the tools available at the time,
>>> which includes 'make package'
>>
>> I wouldn't call it an in-house solution since the package target is a
>> feature of the ports infrastructure.  We simply 'make package' and
>> install other systems from the resulting package.
>>
>> This does not, however, appear to be as well supported by portsng/pkgng
>> as it was in the previous versions.  Now it just exits with no message
>> and a 0 exit-code without creating the package unless you've created
>> /usr/ports/packages and/or specified one or more of WRKDIRPREFIX,
>> PACKAGES and PKGREPOSITORY.
>>
>> What documentation there is seems to be based on older versions (like
>> much of the FreeBSD website) and I haven't found anything on the
>> differences between 'make package' and Poudriere.
>>
>> Roger
>> ___
>> freebsd-ports@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>>
> This is actually a side effect of the STAGING implementation.  The
> package file is put into the
> port (created) work sub directory.   Now if I could only find the
> documentation that tells me how to put, say,
> WORK_DIRECTORY=/var/tmp/work  into the /etc/make.conf file or
> something similar I would be
> a very (well, not so grumpy) happy camper.  I read this somewhere once
> but I cannot find
> it again.  WRKDIRPREFIX?  WORKDIRPREFIX?
>
Patrick,
We have these in make.conf that may help with your research
WRKDIRPREFIX=   /var/ports
DISTDIR=/usr/distfiles
TMPDIR= /tmp
PACKAGES=   /packages
STAGEDIR= /usr/staging

which we've used for many years.  Only STAGEDIR was recently added.  Its
a great aid when you commence a rebuild to just
rm -R /usr/staging /var/ports/usr
Regards, Dewayne.


-- 
For the talkers: “The superior man acts before he speaks, and afterwards speaks 
according to his action.”
For everyone else: “Life is really simple, but we insist on making it 
complicated.”

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BIND REPLACE_BASE option

[Alfred Perlstein]

On 1/9/15 5:42 AM, Mathieu Arnold wrote:

+--On 8 janvier 2015 19:44:09 -0800 Doug Barton  wrote:
| Can you please explain why this option was removed? It's been in the
| ports for over 13 years, and lots of users utilized it.
|
| I realize that BIND is no longer in the base in 10.x, but that would
| be a reason to make the option conditional, to continue to support the
| substantial user base that is still on 8.x and 9.x.

I only removed it from bind99, it was never there in bind910.  I removed it
because it was a poor design idea to begin with, and it was making the port
harder to maintain.  Also, it was overwriting files in the base system,
which is a thing we do not want to do.

All you need to do is add:

named_program="/usr/local/sbin/named"

to your rc.conf, like the message says when you install the port.

It was a bit like the /usr/bin/perl symlink, it was time for it to go.

And on the 8395th day the ports team looked at the OS and declared it 
clean, and it was without users and their cumbersome legacy requirements 
and they rejoiced for now they could do all they needed any wanted.


And it was implemented in shell, C, and make just like the first day and 
no one was bothered by change, except the users.


And there was some rejoicing (not too much as honestly most of the users 
left) and it was good.


-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Fund a FreeBSD manager maybe ? Was: BIND REPLACE_BASE option

[Julian H. Stacey]

Michelle Sullivan wrote: Wed, 14 Jan 2015 13:30:59 +0100
> Matt Smith wrote:
> > On Jan 14 12:15, Mathieu Arnold wrote:
> >>
> >> Well, like I said, REPLACE_BASE was an abomination that should never
> >> have
> >> existed, now that it's gone, it'll never get back, and you'll never
> >> see it
> >> again.
> >>
> >
> > Doug Barton who used to maintain BIND in both the base system and the
> > port used to always say that the version in the base system was only
> > designed to be used as a local resolver on a laptop/desktop. If it was
> > used as a proper DNS server the port version was meant to be used
> > instead. Based on this it makes perfect sense why BIND was replaced
> > with local Unbound in the base, and the ports system still has BIND
> > for people that were using it.
> 
> Was this ever documented? (I've been using bind in base for servers for
> many years and this is the first time I've heard of it - and it is
> unlikely I'm the only one.)

Agreed, Ditto.  In 'man named' on 9.2-RELEASE there's no:
For local resolver only. Will be deleted on release 9.3.
Migrate to ports/dns/bind9[689]

About the same time, working ports demime & majordomo also got
butchered, delaying me;  deletions delayed that person late leaving
work who also mentioned nslookup & asked approx: "~Will it ever end ?~.

No. Unscheduled removals won't stop, unless FreeBSD gets a manager
to enforce proper warning schedules & discipline code butchers who
have intermittently damaged FreeBSD for years.  Many people hosting
FreeBSD dont have time to waste tracking many lists in case 
butchers delete code.  Un-warned deletions are Un-professional.

Labelling someone a manager is easy;  getting a good manager is
harder; one tough enough to suspend commiters (inc. perhaps friends)
yet harder; one effective without the range of carrots & sticks
available for paid employees, yet harder, & we'd hope that manager
be unpaid too ?  That reliable miracle hasn't happened yet.
Too much code has been deleted un-warned between releases.

Maybe the FreeBSD Foundation could fund a part time Change Warning Manager:
  - To impose regular unilateral 30/90 day suspensions on commiters,
without need of consuming core debate.
  - To implement SVN reversals of suspended commiters.
  - Not allowed to commit own stuff, just notices scheduling later changes,
  - Subject to being dismissed by a 2/3 vote of core.

It would make FreeBSD more professional & dependable, & benefit
user businesses who could consider with c...@freebsd.org &
https://www.freebsdfoundation.org/board how they might contribute
to & shape such a function.

Cheers,
Julian
-- 
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
 Indent previous with "> ".  Interleave reply paragraphs like a play script.
 Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"