Re: [CFT] packaging the base system with pkg(8)

[Allan Jude]

On 2016-04-20 01:12, Daniel Eischen wrote:
> On Tue, 19 Apr 2016, Russell L. Carter wrote:
>>
>> What is missing from this debate is some perspective from the POV of
>> actually existing packaging systems.  I've been maintaining
>> debian-stable + debian-testing systems for over 15 years.  The number
>> of packaging glitches I've had I can count on one hand.  (I've been
>> running FreeBSD systems since the *very* beginning.)
>>
>> It is much easier to maintain my debian systems than my FreeBSD
>> systems.  Actually, pkg + poudriere is like a dream.  Better than
>> apt-get, actually.  Except right now it doesn't maintain the base
>> system.
>>
>> So, how many packages are actually installed on one of my debian
>> boxes?
>>
>> debian-testing box with fvwm (ie no gnome/kde) userland:
>>
>> rcarter@aristotle> dpkg --list | wc --lines
>> 1571
>>
>> FreeBSD-10/stable with the same userland packaged from ports:
>>
>> rcarter@feyerabend> pkg info | wc -l
>> 833
>>
>> The debian system, for basically identical functionality, installs 738
>> more packages.  Obviously the FreeBSD box has no packages for the base
>> system, so that is probably a significant part of the difference in
>> installed packages.  And the debian box is dramatically easier to
>> maintain.  I typically will drag a debian box across several debian
>> release cycles, i.e., 6+ years, w/o ever doing anything more
>> complicated than doing apt-get update; apt-get dist-upgrade every week
>> or so.
> 
> For one of our Solaris 11 boxes, which also serves as a VNC
> thin client server and NFS server, we have:
> 
>   [sol11] $ pkg list | wc -l
>  968
> 
> That server includes the gnome desktop, firefox, thunderbird,
> perl, python, wireshark, CDR tools, etc.  So arguably, it is
> comparable to my FreeBSD desktop at home with KDE, firefox,
> thunderbird, and similar tools.  For that FreeBSD box, and
> just for ports packages (since I don't have base pkg'd):
> 
>   [freebsd11] $ pkg info | wc -l
>  865
> 
> [And it really bothers me that FreeBSD 'pkg list' behaves
>  like 'pkg files' or similar should.  It seems intuitive
>  that 'pkg list' should list the packages, not all the files
>  in all the packages.]
> 
> If you add in 750+ FreeBSD base packages (1600+), that seems
> like a very large number of packages.  And upgrading ports
> packages is not always painless.  For the 865 FreeBSD packages
> I have installed, only 27 of them are explicit - the rest are
> dependencies.  I do not look forward to updating my packages,
> even with poudriere.  There is usually manual intervention
> required.  So it is with this experience that I do sort of
> cringe at having 750+ FreeBSD base packages.
> 
> I do like maintaining Solaris 11 boxes much better with their
> pkg management, much better than the old patchadm.
> 

does 'pkg prime-list' give you watch you are looking for? (pkgs you
explicitly installed)

-- 
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Daniel Eischen]

On Wed, 20 Apr 2016, Julian Elischer wrote:



my problem with 400 packages is that is is hard to decide what you are 
actually running.. or is it FreeBSD 11? is it FreeBSD 10.95342453?
you have no way to tell exactly what you have without comparing all the 
packages to a known list.
uname doesn't mean much, nor does "__FreeBSD_version" if everything comes 
with its own versions.


And perhaps I missed it in the large number of missives on
pkg'ing base, but we should be able to list just base packages
or host port packages.  I don't know if that is on or off
the table.

the 'leaf' concept in pkg helps with this a bit, but we've always considered 
FreeBSD bas as a sort of monalithic entity that moves forward together.


you are running 10.1p8 pr 10.2p1  that tells you all you need to know.
If you now need to take into account 400 different dimensions you have a much 
harder way to describe what you have..


Solaris base packages seem to use the OS version in their pkg
version number, for instance:

sol11 $ pkg list | grep 0.5.11 | grep system/library
system/library   0.5.11-0.175.3.1.0.3.0
system/library/boot-management   0.5.11-0.175.3.0.0.30.0
system/library/c++-runtime   0.5.11-0.175.3.0.0.24.0
system/library/c++/sunpro0.5.11-0.168
system/library/iconv/unicode-core0.5.11-0.175.3.0.0.26.2
system/library/iconv/utf-8   0.5.11-0.175.3.0.0.26.2
system/library/install   0.5.11-0.175.3.0.0.30.0
system/library/install/libinstzones  0.5.11-0.175.3.0.0.30.0
system/library/liblayout 0.5.11-0.175.3.0.0.26.2
system/library/libv12n   0.5.11-0.175.3.0.0.30.0
system/library/math  0.5.11-0.175.3.0.0.19.0
system/library/mmheap0.5.11-0.175.3.0.0.7.0
system/library/openmp0.5.11-0.175.3.0.0.2.0
system/library/platform  0.5.11-0.175.3.0.0.30.0
system/library/policykit 0.5.11-0.175.3.0.0.30.0
system/library/processor 0.5.11-0.175.3.0.0.30.0
system/library/security/crypto   0.5.11-0.175.3.1.0.4.0
system/library/security/gss  0.5.11-0.175.3.0.0.30.0
system/library/security/gss/diffie-hellman   0.5.11-0.175.3.0.0.30.0
system/library/security/gss/spnego   0.5.11-0.175.3.0.0.30.0
system/library/security/libsasl  0.5.11-0.175.3.0.0.30.0
system/library/security/pkcs11   0.5.11-0.175.3.0.0.30.0
system/library/security/pkcs11_kernel0.5.11-0.175.3.0.0.30.0
system/library/security/pkcs11_softtoken 0.5.11-0.175.3.0.0.30.0
system/library/security/pkcs11_tpm   0.5.11-0.175.3.0.0.30.0
system/library/security/rpcsec   0.5.11-0.175.3.0.0.30.0
system/library/storage/libdiskmgt0.5.11-0.175.3.0.0.30.0
system/library/storage/libfcoe   0.5.11-0.175.3.0.0.30.0
system/library/storage/scsi-plugins  0.5.11-0.175.3.0.0.30.0
system/library/storage/snia-hbaapi   0.5.11-0.175.3.0.0.30.0
system/library/storage/snia-ima  0.5.11-0.175.3.0.0.30.0
system/library/storage/snia-mpapi0.5.11-0.175.3.0.0.30.0
system/library/storage/suri  0.5.11-0.175.3.0.0.30.0
system/library/storage/t11-sm-hba0.5.11-0.175.3.0.0.30.0
system/library/usb/libusb0.5.11-0.175.3.0.0.30.0
system/library/usb/libusbugen0.5.11-0.175.3.0.0.30.0

That's Solaris 11.3.  I'm assuming the 5.11 is Solaris 11 and
the 175.3 is the .3 update.  The remaining digits must be the
package versions.

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

Use MAX()/MIN() macros in world.

[Marcelo Araujo]

Hey,

As there is a kind of effort to clean up and do some cosmetic changes in
our source base.

I'm wondering if there is any objection to switch some codes to use MAX()
and MIN() macros from sys/param.h.

It will simplify code(readable), most of changes will be cosmetic changes
and not functional.

Thoughts?

Best,
-- 

-- 
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org    \/  \ ^
Power To Server. .\. /_)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Daniel Eischen]

On Tue, 19 Apr 2016, Russell L. Carter wrote:


What is missing from this debate is some perspective from the POV of
actually existing packaging systems.  I've been maintaining
debian-stable + debian-testing systems for over 15 years.  The number
of packaging glitches I've had I can count on one hand.  (I've been
running FreeBSD systems since the *very* beginning.)

It is much easier to maintain my debian systems than my FreeBSD
systems.  Actually, pkg + poudriere is like a dream.  Better than
apt-get, actually.  Except right now it doesn't maintain the base
system.

So, how many packages are actually installed on one of my debian
boxes?

debian-testing box with fvwm (ie no gnome/kde) userland:

rcarter@aristotle> dpkg --list | wc --lines
1571

FreeBSD-10/stable with the same userland packaged from ports:

rcarter@feyerabend> pkg info | wc -l
833

The debian system, for basically identical functionality, installs 738
more packages.  Obviously the FreeBSD box has no packages for the base
system, so that is probably a significant part of the difference in
installed packages.  And the debian box is dramatically easier to
maintain.  I typically will drag a debian box across several debian
release cycles, i.e., 6+ years, w/o ever doing anything more
complicated than doing apt-get update; apt-get dist-upgrade every week
or so.


For one of our Solaris 11 boxes, which also serves as a VNC
thin client server and NFS server, we have:

  [sol11] $ pkg list | wc -l
 968

That server includes the gnome desktop, firefox, thunderbird,
perl, python, wireshark, CDR tools, etc.  So arguably, it is
comparable to my FreeBSD desktop at home with KDE, firefox,
thunderbird, and similar tools.  For that FreeBSD box, and
just for ports packages (since I don't have base pkg'd):

  [freebsd11] $ pkg info | wc -l
 865

[And it really bothers me that FreeBSD 'pkg list' behaves
 like 'pkg files' or similar should.  It seems intuitive
 that 'pkg list' should list the packages, not all the files
 in all the packages.]

If you add in 750+ FreeBSD base packages (1600+), that seems
like a very large number of packages.  And upgrading ports
packages is not always painless.  For the 865 FreeBSD packages
I have installed, only 27 of them are explicit - the rest are
dependencies.  I do not look forward to updating my packages,
even with poudriere.  There is usually manual intervention
required.  So it is with this experience that I do sort of
cringe at having 750+ FreeBSD base packages.

I do like maintaining Solaris 11 boxes much better with their
pkg management, much better than the old patchadm.

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

Re: [CFT] packaging the base system with pkg(8)

[Julian Elischer]

On 20/04/2016 11:41 AM, Nathan Whitehorn wrote:



On 04/19/16 20:15, Warner Losh wrote:
On Apr 19, 2016, at 4:12 PM, Matthew Grooms  
wrote:


On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote:

As far as I know, nobody is taking the source code or the Makefiles
away, so if somebody doesn't like the system being distributed with
pkg, they can very well roll their own.

It's nice to see the level of enthusiasm the FreeBSD project can
muster, I just wish it wasn't always enthusiasm for stopping 
progress.


Maybe I missed an email in this thread, but I don't recall anyone 
completely rejecting the idea of packaging the base system. What I 
see is a discussion related to doing it in the best way possible.
Sadly the tenor and tone of the discussion isn’t one where progress 
is made. The tone has been a bit toxic and demanding, which grinds 
people into dust, rather than motivating them to fix things. You 
might call it a discussion, but it reads to me more as a bunch of 
angry villagers storming the castle. No good can come from that. 
Tone down the outrage by a factor of 100 and try to have the 
conversation again.


Warner


Yes, and that tone raises everyone's defensive hackles, which is 
never good. I'm going to make a patch for a reduced package count 
and hopefully we can restart this discussion then.


It would also be nice to get a statement of what the intended scope 
of these patches is from some of the people involved in the project. 
It's a major change to the system and it would be nice to have some 
kind of architectural document about what is happening. I'm not 
sure, for instance, what the release for 11 looks like with these 
changes, what changes need to be made to the installer (something of 
particular interest to me), how we build install media now that base 
is no longer self-contained (due to lack of pkg), what specific 
problems were intended to be solved, how package dependencies work, 
etc. Something like a few-page white paper would be *really* helpful 
for those of us who weren't at the BSDcan where this was discussed. 
Even a wiki page would help a lot.

-Nathan



my problem with 400 packages is that is is hard to decide what you are 
actually running.. or is it FreeBSD 11? is it FreeBSD 10.95342453?
you have no way to tell exactly what you have without comparing all 
the packages to a known list.
uname doesn't mean much, nor does "__FreeBSD_version" if everything 
comes with its own versions.


the 'leaf' concept in pkg helps with this a bit, but we've always 
considered FreeBSD bas as a sort of monalithic entity that moves 
forward together.


you are running 10.1p8 pr 10.2p1  that tells you all you need to know.
If you now need to take into account 400 different dimensions you have 
a much harder way to describe what you have..


I mentioned this before  but I think hte answer is to make a change on 
the way that "meta packages" are displayed by default in pkg.



If I install the meta package, I really don't want to see all the sub 
packages tat are unchanged unless I add '-v'.  On the other hand if I 
upgrade a sub package I want to see that in the context of the 
metapackage. Similarly if I uninstall of the subpackages.


so something like this would remove most of my objections:

# pkg info
= system packages
FreeBSD-networking-11.0.2_1FreeBSD networking subsystem and 
commands
 - ipfw-11.0.2-1   ipfw tools (uninstalled)
 - fbsd-tcpdump-11.0.2-1   Built in tcpdump tools (uninstalled)
 * openssl-11.0.2-2Openssl support (upgraded CVE-123456
FreeBSD-base-base-11.0.2-1 The absolute minimum booting base 
system
[...]
 external packages ==
apache22-2.2.31Version 2.2.x of Apache web server with prefork 
MPM.
apr-1.5.2.1.5.4Apache Portability Library
autoconf-2.69  Automatically configure source code on many Un*x 
platforms
autoconf-wrapper-20131203  Wrapper script for GNU autoconf
[...]


Maybe I uninstalled ipfw because I use pf and I install the ports 
tcpdump so I can remove the built in one.

I have installed a new openssl due to a bugfix..

This gives me a real instant feel for what I'm running..
if I add -v  then I see all 400 packages, but I really don't want to 
see them 99.99% of the time


I believe the "leaf" method gives close to this but if we could get 
the above I'd have absolutely no objections.




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





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

Re: [CFT] packaging the base system with pkg(8)

[Mark Linimon]

On Wed, Apr 20, 2016 at 05:37:00AM +0300, dan_partelly wrote:
> Year after year you hear about new GsoC projects, then nothing. I find
> it hard to believe that none of those actually produced any useful code.

The goal of GSoC is to introduce new people to FreeBSD more than it is
to produce committable code.

It's designed as a learning experience.

Sometimes, it has the pleasant property of producing code that can be
committed without rework, but not that often.

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

Клиентские базы тел +79133913837 Skype: prodawez389 Email: ammanakuw-7...@yopmail.com

[ammanakuw-7...@yopmail.com]

Соберем для Вас по интернет базу данных потенциальных клиентов для Вашего 
Бизнеса.
По базе можно звонить, писать, слать факсы и email, 
вести любые прямые активные продажи Ваших товаров и услуг
Узнайте подробнее по 
тел +79133913837 (whatsapp,viber,telegram) 
Skype: prodawez389 
Email: ammanakuw-7...@yopmail.com
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

> 
> "I've given your response all the consideration that I think it's due.
> Please have
> a nice day."


Thank you, Warner. Knowing you did, brings warm feelings in my hearth.
Please have a nice day. 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Glen Barber]

On Wed, Apr 20, 2016 at 07:15:22AM +0300, dan_partelly wrote:
> On Wed, 20 Apr 2016 04:07:11 +, Glen Barber  wrote:
> > On Wed, Apr 20, 2016 at 06:59:38AM +0300, dan_partelly wrote:
> >> 
> >> > 
> >> > Sadly the tenor and tone of the discussion isn’t one where progress
> is
> >> > made. The tone has been a bit toxic and demanding, which grinds
> people
> >> into
> >> > dust, rather than motivating them to fix things. You might call it a
> >> > discussion, but it reads to me more as a bunch of angry villagers
> >> storming
> >> > the castle. No good can come from that. Tone down the outrage by a
> >> factor
> >> > of 100 and try to have the conversation again.
> >> > 
> >> 
> >> I'm frankly perplexed by this statement. Its seldom I perceived so much
> 
> >> sorrow and bitterness in 6 lines. There is no castle Warner, unless you
> >> want one to exist, one where you can isolate yourself from the
> >> indentured
> >> peasants and anything they say. Beyond your thick walls you'll be well
> >> served,
> >> every idea outside your wals will be toned down by a factor of 100 by
> the
> >> time
> >> it reaches  the lord, becoming total agreement with anything the lord
> >> thinks. 
> >> 
> >> I cant believe I wrote this shit. But then again, I cant believe you
> just
> >> wrote
> >> what you did.
> >> 
> > 
> > And it's responses like this that are severely demotivating.
> 
> Such statements, such answers. But Im done with this. It degenerates
> in emotional outbursts, much to the shame of all parts involved.
> 

You're absolutely right.

I apologize for offending you and the countless hours spent on getting
this new model correct.

What was I thinking?

Glen



signature.asc
Description: PGP signature

Re: [CFT] packaging the base system with pkg(8)

[Warner Losh]

On Tue, Apr 19, 2016 at 9:59 PM, dan_partelly  wrote:

>
> >
> > Sadly the tenor and tone of the discussion isn’t one where progress is
> > made. The tone has been a bit toxic and demanding, which grinds people
> into
> > dust, rather than motivating them to fix things. You might call it a
> > discussion, but it reads to me more as a bunch of angry villagers
> storming
> > the castle. No good can come from that. Tone down the outrage by a
> factor
> > of 100 and try to have the conversation again.
> >
>
> I'm frankly perplexed by this statement. Its seldom I perceived so much
> sorrow and bitterness in 6 lines. There is no castle Warner, unless you
> want one to exist, one where you can isolate yourself from the indentured
> peasants and anything they say. Beyond your thick walls you'll be well
> served,
> every idea outside your wals will be toned down by a factor of 100 by the
> time
> it reaches  the lord, becoming total agreement with anything the lord
> thinks.
>
> I cant believe I wrote this shit. But then again, I cant believe you just
> wrote
> what you did.
>

"I've given your response all the consideration that I think it's due.
Please have
a nice day."

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

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

On Wed, 20 Apr 2016 04:07:11 +, Glen Barber  wrote:
> On Wed, Apr 20, 2016 at 06:59:38AM +0300, dan_partelly wrote:
>> 
>> > 
>> > Sadly the tenor and tone of the discussion isn’t one where progress
is
>> > made. The tone has been a bit toxic and demanding, which grinds
people
>> into
>> > dust, rather than motivating them to fix things. You might call it a
>> > discussion, but it reads to me more as a bunch of angry villagers
>> storming
>> > the castle. No good can come from that. Tone down the outrage by a
>> factor
>> > of 100 and try to have the conversation again.
>> > 
>> 
>> I'm frankly perplexed by this statement. Its seldom I perceived so much

>> sorrow and bitterness in 6 lines. There is no castle Warner, unless you
>> want one to exist, one where you can isolate yourself from the
>> indentured
>> peasants and anything they say. Beyond your thick walls you'll be well
>> served,
>> every idea outside your wals will be toned down by a factor of 100 by
the
>> time
>> it reaches  the lord, becoming total agreement with anything the lord
>> thinks. 
>> 
>> I cant believe I wrote this shit. But then again, I cant believe you
just
>> wrote
>> what you did.
>> 
> 
> And it's responses like this that are severely demotivating.

Such statements, such answers. But Im done with this. It degenerates
in emotional outbursts, much to the shame of all parts involved.

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

Re: [CFT] packaging the base system with pkg(8)

[Nathan Whitehorn]

On 04/19/16 21:07, Glen Barber wrote:

On Wed, Apr 20, 2016 at 06:59:38AM +0300, dan_partelly wrote:

Sadly the tenor and tone of the discussion isn’t one where progress is
made. The tone has been a bit toxic and demanding, which grinds people

into

dust, rather than motivating them to fix things. You might call it a
discussion, but it reads to me more as a bunch of angry villagers

storming

the castle. No good can come from that. Tone down the outrage by a

factor

of 100 and try to have the conversation again.


I'm frankly perplexed by this statement. Its seldom I perceived so much
sorrow and bitterness in 6 lines. There is no castle Warner, unless you
want one to exist, one where you can isolate yourself from the indentured
peasants and anything they say. Beyond your thick walls you'll be well
served,
every idea outside your wals will be toned down by a factor of 100 by the
time
it reaches  the lord, becoming total agreement with anything the lord
thinks.

I cant believe I wrote this shit. But then again, I cant believe you just
wrote
what you did.


And it's responses like this that are severely demotivating.

Glen



Yes, this is not helpful. Talking about walls and lords and whatever can 
only make people angry (or demotivated) and is never persuasive. This is 
really great work; there is a discussion about some nits in how to 
distribute the results that corresponds to maybe 1% of the total patch.

-Nathan

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

Re: [CFT] packaging the base system with pkg(8)

[Glen Barber]

On Wed, Apr 20, 2016 at 06:59:38AM +0300, dan_partelly wrote:
> 
> > 
> > Sadly the tenor and tone of the discussion isn’t one where progress is
> > made. The tone has been a bit toxic and demanding, which grinds people
> into
> > dust, rather than motivating them to fix things. You might call it a
> > discussion, but it reads to me more as a bunch of angry villagers
> storming
> > the castle. No good can come from that. Tone down the outrage by a
> factor
> > of 100 and try to have the conversation again.
> > 
> 
> I'm frankly perplexed by this statement. Its seldom I perceived so much 
> sorrow and bitterness in 6 lines. There is no castle Warner, unless you
> want one to exist, one where you can isolate yourself from the indentured 
> peasants and anything they say. Beyond your thick walls you'll be well
> served,
> every idea outside your wals will be toned down by a factor of 100 by the
> time
> it reaches  the lord, becoming total agreement with anything the lord
> thinks. 
> 
> I cant believe I wrote this shit. But then again, I cant believe you just
> wrote
> what you did.
> 

And it's responses like this that are severely demotivating.

Glen



signature.asc
Description: PGP signature

Re: qsort() documentation

[Warren Block]

On Tue, 19 Apr 2016, Aleksander Alekseev wrote:


Why Wikipedia, specifically?  There are a lot of places that describe
quicksort.  How about just

   Note: This implementation of qsort() is designed to avoid the
   worst-case complexity of N**2 that is often seen with standard
   versions.


I would say that this statement is just false. Worst-case complexity is
still N**2. How about something like:

"""
This implementation of qsort() has worst case complexity of N**2.
However measures were taken that make it very unlikely that for some
random input N**2 swaps will be made. It's still possible to generate
such an input on purpose though. See code below for more details.
"""


Okay:

  The quicksort algorithm worst-case is O(N**2), but this implementation
  has been designed to avoid that for most real data.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

> 
> Sadly the tenor and tone of the discussion isn’t one where progress is
> made. The tone has been a bit toxic and demanding, which grinds people
into
> dust, rather than motivating them to fix things. You might call it a
> discussion, but it reads to me more as a bunch of angry villagers
storming
> the castle. No good can come from that. Tone down the outrage by a
factor
> of 100 and try to have the conversation again.
> 

I'm frankly perplexed by this statement. Its seldom I perceived so much 
sorrow and bitterness in 6 lines. There is no castle Warner, unless you
want one to exist, one where you can isolate yourself from the indentured 
peasants and anything they say. Beyond your thick walls you'll be well
served,
every idea outside your wals will be toned down by a factor of 100 by the
time
it reaches  the lord, becoming total agreement with anything the lord
thinks. 

I cant believe I wrote this shit. But then again, I cant believe you just
wrote
what you did.



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

Re: [CFT] packaging the base system with pkg(8)

[Glen Barber]

On Tue, Apr 19, 2016 at 09:15:47PM -0600, Warner Losh wrote:
> 
> > On Apr 19, 2016, at 4:12 PM, Matthew Grooms  wrote:
> > 
> > On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote:
> >> As far as I know, nobody is taking the source code or the Makefiles
> >> away, so if somebody doesn't like the system being distributed with
> >> pkg, they can very well roll their own.
> >> 
> >> It's nice to see the level of enthusiasm the FreeBSD project can
> >> muster, I just wish it wasn't always enthusiasm for stopping progress.
> >> 
> > 
> > Maybe I missed an email in this thread, but I don't recall
> > anyone completely rejecting the idea of packaging the base system.
> > What I see is a discussion related to doing it in the best way
> > possible.
> 
> Sadly the tenor and tone of the discussion isn’t one where progress
> is made. The tone has been a bit toxic and demanding, which grinds
> people into dust, rather than motivating them to fix things. You
> might call it a discussion, but it reads to me more as a bunch of
> angry villagers storming the castle. No good can come from that.
> Tone down the outrage by a factor of 100 and try to have the
> conversation again.
> 

As probably the most demotivated person to read through this onslaught
of nonsense, I cannot agree more.

Glen



signature.asc
Description: PGP signature

Re: [CFT] packaging the base system with pkg(8)

[Nathan Whitehorn]

On 04/19/16 20:15, Warner Losh wrote:

On Apr 19, 2016, at 4:12 PM, Matthew Grooms  wrote:

On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote:

As far as I know, nobody is taking the source code or the Makefiles
away, so if somebody doesn't like the system being distributed with
pkg, they can very well roll their own.

It's nice to see the level of enthusiasm the FreeBSD project can
muster, I just wish it wasn't always enthusiasm for stopping progress.


Maybe I missed an email in this thread, but I don't recall anyone completely 
rejecting the idea of packaging the base system. What I see is a discussion 
related to doing it in the best way possible.

Sadly the tenor and tone of the discussion isn’t one where progress is made. 
The tone has been a bit toxic and demanding, which grinds people into dust, 
rather than motivating them to fix things. You might call it a discussion, but 
it reads to me more as a bunch of angry villagers storming the castle. No good 
can come from that. Tone down the outrage by a factor of 100 and try to have 
the conversation again.

Warner


Yes, and that tone raises everyone's defensive hackles, which is never 
good. I'm going to make a patch for a reduced package count and 
hopefully we can restart this discussion then.


It would also be nice to get a statement of what the intended scope of 
these patches is from some of the people involved in the project. It's a 
major change to the system and it would be nice to have some kind of 
architectural document about what is happening. I'm not sure, for 
instance, what the release for 11 looks like with these changes, what 
changes need to be made to the installer (something of particular 
interest to me), how we build install media now that base is no longer 
self-contained (due to lack of pkg), what specific problems were 
intended to be solved, how package dependencies work, etc. Something 
like a few-page white paper would be *really* helpful for those of us 
who weren't at the BSDcan where this was discussed. Even a wiki page 
would help a lot.

-Nathan

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

Re: [CFT] packaging the base system with pkg(8)

[Warner Losh]

> On Apr 19, 2016, at 4:12 PM, Matthew Grooms  wrote:
> 
> On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote:
>> As far as I know, nobody is taking the source code or the Makefiles
>> away, so if somebody doesn't like the system being distributed with
>> pkg, they can very well roll their own.
>> 
>> It's nice to see the level of enthusiasm the FreeBSD project can
>> muster, I just wish it wasn't always enthusiasm for stopping progress.
>> 
> 
> Maybe I missed an email in this thread, but I don't recall anyone completely 
> rejecting the idea of packaging the base system. What I see is a discussion 
> related to doing it in the best way possible.

Sadly the tenor and tone of the discussion isn’t one where progress is made. 
The tone has been a bit toxic and demanding, which grinds people into dust, 
rather than motivating them to fix things. You might call it a discussion, but 
it reads to me more as a bunch of angry villagers storming the castle. No good 
can come from that. Tone down the outrage by a factor of 100 and try to have 
the conversation again.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

On Tue, 19 Apr 2016 20:09:30 +, "Poul-Henning Kamp"
 wrote:
> As far as I know, nobody is taking the source code or the Makefiles
> away, so if somebody doesn't like the system being distributed with
> pkg, they can very well roll their own.
> 
> It's nice to see the level of enthusiasm the FreeBSD project can
> muster, I just wish it wasn't always enthusiasm for stopping progress.

Your statement, at least as pertaining to this particular exchange, is
unfair by any criteria.
I dont think anybody in their right mind would oppose the base packaging
project, all I seen 
where concerns regarding the pkg maturity, and how it handles the sheer
number of resulting packages. 
which, if you think a bit, are legitimate concerns, whatever you agree
with this stance or not.

Yes, it is high time for progress. It is high time that FreeBSD foundation
uses a more sizable chunk
of the donations it receives to pay for projects bringing progress in
FreeBSD.Maybe it is also high time
that companies which make millions using BSD OSes (like Juniper) would
give something substantial back. 
Speaking of progress, somebody should take a look at the autoexec.bat
system called rc, and pay (foundation money)
to have it rewritten in a modern form , which allows service sane service
management and a modern fault reporting
interface. Have the FreeBSD foundation pay to port those from Solaris. 
Also, while here, take a good look at the base system , and use same
foundation money to ensure you expose 
in libraries all critical interfaces to the OS. Next, get a decent IPC
system (there is already code there for this
in the form of Mach ports in NextBSD. Yeah, FreeBSD needs a better way to
do IPC that posix and plain unix domain sockets.


Code is speaking lauder than words, so please, use the opportunity created
by Hubbard and his NextBSD to get a much needed
IPC system in FreeBSD. To be fair, it is needed for progress. 

Lastly, look in a more timely manner to the summer of code projects which
might have produced some useful code. 
Year after year you hear about new GsoC projects, then nothing. I find it
hard to bleive that none of those actually 
produced any useful code.

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

Re: [CFT] packaging the base system with pkg(8)

[Alfred Perlstein]

On 4/19/16 1:09 PM, Poul-Henning Kamp wrote:

As far as I know, nobody is taking the source code or the Makefiles
away, so if somebody doesn't like the system being distributed with
pkg, they can very well roll their own.

It's nice to see the level of enthusiasm the FreeBSD project can
muster, I just wish it wasn't always enthusiasm for stopping progress.


+1000


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

Re: Mis-use of BUS_PASS_ORDER_MIDDLE

[Howard Su]

Can we only load the bus driver that is required by timer or pic? Then you
don't need worry about acpi_pci or pcib.

John Baldwin 于2016年4月20日周三 上午3:26写道：

> On Tuesday, April 19, 2016 03:42:40 PM Howard Su wrote:
> > On Tue, Apr 19, 2016 at 2:53 AM John Baldwin  wrote:
> >
> > > On Monday, April 18, 2016 11:10:12 PM Howard Su wrote:
> > > > I noticed several places there are code like this, especially in
> some arm
> > > > low level drivers.
> > > > EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver,
> aw_ccu_devclass,
> > > > 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE);
> > > >
> > > > ​I feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There are
> another
> > > > macro EARLY_DRIVER_MODULE_ORDERED, which take an additional parameter
> > > > "order". I believe BUS_PASS_ORDER_xxx is used for that parameter.
> > >
> > > No, this is actually correct.  The _ORDERED variants actually accept a
> > > SI_ORDER_* value to determine how drivers contained in a single .ko
> file
> > > are registered (in particular if you have several drivers in a .ko file
> > > you typically want the "top-most" driver to attach last so that all the
> > > other drivers are ready once the actual device is attached).
> > >
> > Why not use _ORDERED here to achieve same thing?  _ORDERED(,
> > SI_ORDER_LAST, BUS_PASS_BUS)?
> >
> > I am thinking to add some macro like BUS_DRIVER_MODULE,
> INT_DRIVER_MODULE,
> > TIMER_DRIVER_MODULE, so that the driver can declare itself in such way.
> If
> > we can avoid usage of BUS_PASS_ORDER_XXX, the macro is much cleaner.
> >
> > I am plan to do is: in autoconf phase, first load timer, int and some
> bus,
> > etc low level drivers first, then set cold=0, then load other driver to
> > work around the problem that driver needs special handling on cold which
> is
> > not necessary. of course, this may depends on your change of ap_startup.
> > thoughts?
>
> I would like to get to that, but the path on x86 is a bit messier.  Ideally
> the order looks something like this:
>
> - enumerate the tree (BUS_PASS_BUS)
> - reserve fixed-resources (things like acpi_sysres) (BUS_PASS_RESOURCE)
> - reserve existing resources that could be moved or disabled if
>   their is a conflict (think PCI BARs programmed by firmware and/or
>   doing an initial pass of BARs)
> - interrupt controllers (may need resources) (BUS_PASS_INTR)
> - timers (probably need resources, need interrupts) (BUS_PASS_TIMER)
>
> Then all the rest.
>
> However, it ends up a bit messier on x86 at least.  I have a WIP to at
> least start doing BUS_PASS_BUS for x86, but I found that I really need
> some ACPI bits to probe before the ACPI 'pcib' driver, so I've ended
> up with a kind of 'BUS_PASS_PREBUS' for acpi0, and even then it turns out
> that in some cases we need more granularity than just 'BUS_PASS_xxx'.
>
> SI_ORDER_* with ORDERED will not help as all the drivers are registered
> at SI_SUB_DRIVERS during boot (which is when the SI_ORDER_* applies),
> but the device tree is enumerated and attached at SI_SUB_CONFIGURE.
>
> And yes, the AP startup stuff is a precursor for this.
>
> --
> John Baldwin
>
-- 
-Howard
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Jonathan Anderson]

On 19 Apr 2016, at 19:42, Matthew Grooms wrote:

I suspect that most of the negative reactions people are having is due 
to the line being blurred between the base system and everything else. 
Historically there has always been a clear distinction. By packaging 
base and throwing it in with everything else, you erase that 
distinction.


I certainly agree that the distinction is changing, but I wouldn't say 
it's being erased. In fact, I'd argue that a packaged base system will 
clarify the conversation around the base/not-base dichotomy by forcing 
us to think about the underlying distinctions rather than of the 
delivery mechanism. For instance, I'd say that the biggest blurring 
between base and ports doesn't come from packages, it comes from vendor 
branches.


If the base system is "an atomic, maintained-by-us snapshot of all the 
stuff you need to get a computer running and bootstrap your 
applications"... well, first, stop me here if I'm wrong!


Assuming I'm not entirely wrong: we have lots of code in base that is 
"built by the FreeBSD project" and entirely maintained by "us". However, 
there is also a lot of code in base that comes from an upstream source 
and is primarily maintained by "them" (who may overlap with "us"), yet 
is essential to building or using the FreeBSD base system. This is a 
necessity of modern life (compilers are good), and yet I'm not entirely 
clear on the distinction between a lightly-patched compiler that lives 
in our source tree and a lightly-patched compiler that lives in the 
ports tree. So, now that the base compiler and a ports compiler will be 
installed using the same tools, it might be worth thinking about how 
they're really different (if at all).


Not that there are any good answers...


Jon
--
Jonathan Anderson
jonat...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Matthew Grooms]

On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote:

As far as I know, nobody is taking the source code or the Makefiles
away, so if somebody doesn't like the system being distributed with
pkg, they can very well roll their own.

It's nice to see the level of enthusiasm the FreeBSD project can
muster, I just wish it wasn't always enthusiasm for stopping progress.



Maybe I missed an email in this thread, but I don't recall anyone 
completely rejecting the idea of packaging the base system. What I see 
is a discussion related to doing it in the best way possible.


I suspect that most of the negative reactions people are having is due 
to the line being blurred between the base system and everything else. 
Historically there has always been a clear distinction. By packaging 
base and throwing it in with everything else, you erase that 
distinction. I suspect that if the 'base is different' concept was 
preserved in a more fundamental way, there would be less resistance. 
After all, is there that much difference between trusting freebsd-update 
to patch X files vs trusting pkg to update X packaged files?


What if there were two classes of packages, base and general? To 
interact with a base package set, perhaps an additional command line 
argument could be required. If you do a 'pkg info' after an install, an 
empty package set is shown. If you do a 'pkg info --base' ( or whatever 
) instead, you see the base package set installed. If you need to get 
back to just the base system, you run 'pkg delete *' without the --base 
arg. In other words, base retains it's distinction and pkg pretty much 
works the same as it does now ( without the new argument ).


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

Re: [CFT] packaging the base system with pkg(8)

[Maxim Sobolev]

I am sorry to maybe sound like an old grudge here, but can somebody take a
sweep at the bug reports filled against ports-mgt/pkg in the last year or
so? Packaging base system is surely challenging and exciting task, and
great bikesheed topic too, but there are lot of critical bugs in the code
that are pretty trivial and easy to fix. I owe at least one and it had no
attention whatsoever for a month or so. Almost to the point where I would
put my "no response from: maintainer" asbestos on and start checking in
some random patches. Searching bigzilla shows that I might not be alone. (

-Max

On Tue, Apr 19, 2016 at 2:17 PM, Wolfgang Zenker 
wrote:

> * Adrian Chadd  [160419 22:36]:
> > It's cool. I have positive and negative reactions, and I'm totally
> > happy to let people try it out at a larger scale and learn from
> > mistakes.
>
> right, thats what we have CURRENT for. Instead of discussing all
> the things that could theoretically go wrong or make our live
> easier/more difficult/whatever, let's just try it out and get
> a feeling for it.
>
> Wolfgang
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Wolfgang Zenker]

* Adrian Chadd  [160419 22:36]:
> It's cool. I have positive and negative reactions, and I'm totally
> happy to let people try it out at a larger scale and learn from
> mistakes.

right, thats what we have CURRENT for. Instead of discussing all
the things that could theoretically go wrong or make our live
easier/more difficult/whatever, let's just try it out and get
a feeling for it.

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

Re: [CFT] packaging the base system with pkg(8)

[Justin Hibbits]

On Tue, Apr 19, 2016 at 3:36 PM, Nathan Whitehorn
 wrote:
>
>
> On 04/19/16 13:26, Poul-Henning Kamp wrote:
>>
>> 
>> In message <1461096962.1232.32.ca...@freebsd.org>, Ian Lepore writes:
>>
>>> Oh yeah, now I remember:  Because in freebsd, design is decided by a
>>> race to commit rather than by discussion.
>>
>> No, that's not it.
>>
>> It is because code talks much louder than words.

> If it would help, I am happy to generate a patch to make the discussion
> concrete.
> -Nathan

Please do.  Practical is always better than theory, in practice.  It's
easier to debate on practical grounds.

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

Re: [CFT] packaging the base system with pkg(8)

[hiren panchasara]

On 04/19/16 at 01:36P, Nathan Whitehorn wrote:
> 
> 
> On 04/19/16 13:26, Poul-Henning Kamp wrote:
> > 
> > In message <1461096962.1232.32.ca...@freebsd.org>, Ian Lepore writes:
> >
> >> Oh yeah, now I remember:  Because in freebsd, design is decided by a
> >> race to commit rather than by discussion.
> > No, that's not it.
> >
> > It is because code talks much louder than words.
> >
> This is kind of a silly argument here since the code change is trivial. 
> There is a potentially large impact on the system that merits 
> discussion. Moreover, there is a whole bunch of other code still needs 
> to be written to make this workable in production that depends to some 
> degree on what choices are made here: what does pkg show for these? How 
> do upgrades work? The installer needs modifications to use pkg instead 
> of tar. It's not clear what the migration path to/from a packaged system 
> is, since the packaging is apparently optional.
> 
> If it would help, I am happy to generate a patch to make the discussion 
> concrete.

Thank you, Nathan.
"code wins" is not the correct argument in this discussion, imo.

Fwiw, I feel this is one of the sensible threads where things are being
discussed without shouting/yelling/shaming. But thats my opinion.

Cheers,
Hiren


pgpisYNukTf2G.pgp
Description: PGP signature

Re: [CFT] packaging the base system with pkg(8)

[Nathan Whitehorn]

On 04/19/16 13:26, Poul-Henning Kamp wrote:


In message <1461096962.1232.32.ca...@freebsd.org>, Ian Lepore writes:


Oh yeah, now I remember:  Because in freebsd, design is decided by a
race to commit rather than by discussion.

No, that's not it.

It is because code talks much louder than words.

This is kind of a silly argument here since the code change is trivial. 
There is a potentially large impact on the system that merits 
discussion. Moreover, there is a whole bunch of other code still needs 
to be written to make this workable in production that depends to some 
degree on what choices are made here: what does pkg show for these? How 
do upgrades work? The installer needs modifications to use pkg instead 
of tar. It's not clear what the migration path to/from a packaged system 
is, since the packaging is apparently optional.


If it would help, I am happy to generate a patch to make the discussion 
concrete.

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

Re: [CFT] packaging the base system with pkg(8)

[Roger Marquis]

Nathan Whitehorn wrote:
Thanks, Roger. That seems perfectly reasonable. I'm not sure that goal is 
really met by having 800 packages, though, or at least I see no particular 
gain relative to a handful (where things like OpenSSL or sendmail would be 
discrete things). (Almost) every single individual library in the base system 
is right now its own single-file package, which is what I am objecting to.


Hey Nathan.  I admit to not having looked at it with the goal of
consolidation.  Presumably there will be libs that can be grouped but we
should look at each consolidation's pros and cons.  Baptiste's rational
is the policy we have and, IMO, refinement should start at that (policy)
level.  The process has no doubt accelerated thanks this thread but
aside from debug, profile and a few others it's not clear if there are
grouping policies that would significantly bridge the gap between our
respective goals.

It's critical that we look at other distribution's package systems.  My
count packages on Linux and monolithinc-base FreeBSD desktops is about
2,500 and 700 respectively.  Adding 383 base packages (assuming no debug
or profile) would push this 28% ratio to 43% of Linux' package count.
Of course servers will be different and our FreeBSD package counts would
rise from the low to mid 100s to over 600 which is still only 60-70% of
the packages on Linux servers I have access to.  Having managed Linux
systems with 1000 to 3000 packages I can't say that I have real concerns
for pkgng in this regard.  The package management tools have to scale of
course but on a KIS scale more packages = less time spent for a given
level of functionality and security (in my experience).

I hope we can look forward to some top-level policy suggestions to
further refine the base package schema.

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

Re: [CFT] packaging the base system with pkg(8)

[K. Macy]

On Tuesday, April 19, 2016, Adrian Chadd  wrote:

> It's cool. I have positive and negative reactions, and I'm totally
> happy to let people try it out at a larger scale and learn from
> mistakes.
>
> Because, honestly - fuck it, we've been behind for too long. We need
> more mature tools and knowledge with this.
>
> The irony of course is the people rolling out docker are doing it
> after finding that OS packages aren't the best granularity, but
> "whatever the package systems in the software stack we're using, and
> then tar the whole mess up and distribute it" method. Kinda like
> FreeBSD
>
>
>
Those are different, semi-orthogonal problems. Please restate your last
paragraph. I can't interpret your intent.
-M


>
> -adrian
> ___
> freebsd-current@freebsd.org  mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
> "
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Adrian Chadd]

It's cool. I have positive and negative reactions, and I'm totally
happy to let people try it out at a larger scale and learn from
mistakes.

Because, honestly - fuck it, we've been behind for too long. We need
more mature tools and knowledge with this.

The irony of course is the people rolling out docker are doing it
after finding that OS packages aren't the best granularity, but
"whatever the package systems in the software stack we're using, and
then tar the whole mess up and distribute it" method. Kinda like
FreeBSD



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

Re: [CFT] packaging the base system with pkg(8)

[Poul-Henning Kamp]

In message <1461096962.1232.32.ca...@freebsd.org>, Ian Lepore writes:

>Oh yeah, now I remember:  Because in freebsd, design is decided by a
>race to commit rather than by discussion.

No, that's not it.

It is because code talks much louder than words.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Kurt Jaeger]

Hi!

>  I don't see anybody, who say "remove this packaging code, it is all
> completely wrong, BS, whatever". All objections are against mechanical
> splitting base to 700+ packages, not against packaged base per se.

I also run a bunch of boxes, and I do not have a problem with
700+ base packages on top of the other ones I use.

But: I have not tested pkg base yet. I'm just a happy pkg user 8-}

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

Re: [CFT] packaging the base system with pkg(8)

[Lev Serebryakov]

On 19.04.2016 23:10, K. Macy wrote:

 I don't like to see, as some participants of this thread write their
messages as if somebody in this thread are against packaging base with pkg.

 I don't see anybody, who say "remove this packaging code, it is all
completely wrong, BS, whatever". All objections are against mechanical
splitting base to 700+ packages, not against packaged base per se.

-- 
// Lev Serebryakov



signature.asc
Description: OpenPGP digital signature

Re: [CFT] packaging the base system with pkg(8)

[Ian Lepore]

On Tue, 2016-04-19 at 20:09 +, Poul-Henning Kamp wrote:
> As far as I know, nobody is taking the source code or the Makefiles
> away, so if somebody doesn't like the system being distributed with
> pkg, they can very well roll their own.
> 
> It's nice to see the level of enthusiasm the FreeBSD project can
> muster, I just wish it wasn't always enthusiasm for stopping
> progress.
> 

Why is it that anyone who tries to inject some aspect of concensus
design into something is automatically labeled anti-progess?

Oh yeah, now I remember:  Because in freebsd, design is decided by a
race to commit rather than by discussion.

-- Ian

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

Re: [CFT] packaging the base system with pkg(8)

[K. Macy]

On Tuesday, April 19, 2016, Poul-Henning Kamp  wrote:

> As far as I know, nobody is taking the source code or the Makefiles
> away, so if somebody doesn't like the system being distributed with
> pkg, they can very well roll their own.
>
> It's nice to see the level of enthusiasm the FreeBSD project can
> muster, I just wish it wasn't always enthusiasm for stopping progress.



+1



>
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> ___
> freebsd-current@freebsd.org  mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
> "
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Poul-Henning Kamp]

As far as I know, nobody is taking the source code or the Makefiles
away, so if somebody doesn't like the system being distributed with
pkg, they can very well roll their own.

It's nice to see the level of enthusiasm the FreeBSD project can
muster, I just wish it wasn't always enthusiasm for stopping progress.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Jeffrey Bouquet]

On Tue, 19 Apr 2016 20:18:40 +0300, Lev Serebryakov  wrote:

> On 19.04.2016 19:28, Nathan Whitehorn wrote:
> 
> > 3. Have ~10 meta packages that just depend on sets of the 755 packages
> > and hide the internal details. This gives the user experience of (1)
> > with the implementation of (2), and is marginally more complex than either.
>   How does it help Slawa with his broken system when "pkg upgrade"
> replace only half of "base" packages?
> 
>  Meta-packages as they are now: "no files, only dependencies" doesn't
> help here at all.
> 
>   Really, if I want "base but no sendmail" I want easy way to see it
> after 5 years after installation, and 755 packages, covered or not by
> meta-packages, will need me to read all list of 754 packages to see,
> that there is no sendmail, for example. It is trivial example, but it is
> completely valid. And there are many other such corner cases, which is
> common for administrators and ops, but not for developers.
> 
>  Please, consider ops and admins, who must support old installations,
> often made by other, not-reachable, people, and stuff like this,
> 
> -- 
> // Lev Serebryakov


Thoughts PRO pkg base from here:

 it can fix a broken installworld that breaks midway rendering the system no 
able to login, not
 able to compile or install futher, or some other event... Can those failures 
be crafted purposely
 to show how the could be readily  per procedure if a usual installworld fails?

Thoughts ANTI pkg base from here:
 Several, but I have thought of more work required for developers who have 
custom kernels and
  a large amount of code that is BETA and not READY yet and are slowed down by 
conforming
 to additional pkg-base requirements.. hindering creativity
 ...
 Sparse initial documentation or at some time not upto par
 ...
 *FLOWCHART" demonstrating precisely the relationship between a pure-pkg-base 
and  pure-svn-base
 system, a mixture of the two, how to migrate parts/all of one to the other, 
one edge a desired install
  or several types of same, the other (two) edges where one starts out from... 
that could be updated
 over the years for a comprehensive overview.
 
[ AS AN ASIDE,  ] I always tend to think that as missing already in pkg, 
svn, synth, poudriere, jails,
 chroot, wpa_supplicant, ndisalator, linux-c6, binutils >> << gcc , zfs, 
ssh_config, ipfw, pf, geli,
 gpart, UEFI, xorg.conf, some individual ports, [ I should stop typing 
here, because even as I
 type more things come to mind... problem with a port ? pr OR maintainer OR 
documentation OR...
 flowchart... etc ]
 stuff-to-leave-out-or-include-in-a-kernel, buildworld/installworld, 
ppp.conf, NOT AS CRITICISM but
 as "Why is it not at least as good for newbies to each concept or better 
than a WIKI !!!  as
 not only the simplified explanation sometimes can be made more apparent of 
which cli to issue next,
 but time spent reading stuff NOT specific to the task at hand is saved. 
 
  Adequate testing? some breakage bound to happen... fixing such breakage 
procedures in place?
  A UPDATING for pkg-base specifically? 

Again, not wishing to waste one's time, just writing down what I've thought of 
so far, freely simply file
it away rather than reply online...  my answers to any reply could simply 
re-iterate the background to the
above (I am NOT well versed in many topics of FreeBSD, just in the more useful 
ones at the
installs that I use daily... ).
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Russell L. Carter]

On 04/19/16 11:22, Nathan Whitehorn wrote:



On 04/19/16 10:55, Roger Marquis wrote:

Please, consider ops and admins, who must support old installations,
often made by other, not-reachable, people, and stuff like this,


Ops and admins such as myself are exactly the ones who will benefit most
from base packages.  Being able run to: 1) 'pkg audit' and see that base
ssl has a vulnerability, 2) 'pkg install -f' to update 3) only those
specific parts of base that need to be updated is far simpler (KIS) and
faster than what we go through now.  More than a few formerly bsd shops
have migrated to linux simply to avoid regular iterations of cd
/usr/src; svn up; make cleanworld; make buildworld installworld ...

The use cases for granular base packages are more numerous than even
these obvious ones.  The downside OTOH, seems to consist of not much
more than the size of the package list.  If I missed other issues please
do clarify.  Will base packages be improved, sure, but they're already
more useful and bugfree than pkgng when it was mandated.

In any case, if I'm not mistaken base packages are entirely optional.

Roger Marquis



Thanks, Roger. That seems perfectly reasonable. I'm not sure that goal
is really met by having 800 packages, though, or at least I see no
particular gain relative to a handful (where things like OpenSSL or
sendmail would be discrete things). (Almost) every single individual
library in the base system is right now its own single-file package,
which is what I am objecting to. The upside of that seems pretty dubious
and the downside is that it is much easier to accidentally put the
system into an inconsistent state. Is there a reason you want to have
such very fine discretization?
-Nathan


What is missing from this debate is some perspective from the POV of
actually existing packaging systems.  I've been maintaining
debian-stable + debian-testing systems for over 15 years.  The number
of packaging glitches I've had I can count on one hand.  (I've been
running FreeBSD systems since the *very* beginning.)

It is much easier to maintain my debian systems than my FreeBSD
systems.  Actually, pkg + poudriere is like a dream.  Better than
apt-get, actually.  Except right now it doesn't maintain the base
system.

So, how many packages are actually installed on one of my debian
boxes?

debian-testing box with fvwm (ie no gnome/kde) userland:

rcarter@aristotle> dpkg --list | wc --lines
1571

FreeBSD-10/stable with the same userland packaged from ports:

rcarter@feyerabend> pkg info | wc -l
 833

The debian system, for basically identical functionality, installs 738
more packages.  Obviously the FreeBSD box has no packages for the base
system, so that is probably a significant part of the difference in
installed packages.  And the debian box is dramatically easier to
maintain.  I typically will drag a debian box across several debian
release cycles, i.e., 6+ years, w/o ever doing anything more
complicated than doing apt-get update; apt-get dist-upgrade every week
or so.

Now I much prefer poudriere + pkg over apt-get, because I can tune my
package dependencies.  What I do is make the implicit meta-packages
effectively even more fine grained, by excluding stuff I don't need.
My conclusion is that it's not obvious that a large number of packages
makes a system harder to maintain.  It seems to me, the opposite.  Now
I watch a few debian lists so I know glitches happen, but not to me
very often.

I don't have much experience locking down a system to just major
releases with only security updates, but I don't think debian-stable
has very many issues doing exactly that.

In my opinion, what the package team is doing is extremely cool,
technically.  I run poudriere builds every night, keeping up to date
with ports-svn.  It's just so much better than debian's kitchen sink
one-size-fits-all approach to package dependencies.  In a container
world, it seems to me this is basically a killer app.

Best to all,
Russell
















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

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

Re: Mis-use of BUS_PASS_ORDER_MIDDLE

[John Baldwin]

On Tuesday, April 19, 2016 03:42:40 PM Howard Su wrote:
> On Tue, Apr 19, 2016 at 2:53 AM John Baldwin  wrote:
> 
> > On Monday, April 18, 2016 11:10:12 PM Howard Su wrote:
> > > I noticed several places there are code like this, especially in some arm
> > > low level drivers.
> > > EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devclass,
> > > 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE);
> > >
> > > ​I feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There are another
> > > macro EARLY_DRIVER_MODULE_ORDERED, which take an additional parameter
> > > "order". I believe BUS_PASS_ORDER_xxx is used for that parameter.
> >
> > No, this is actually correct.  The _ORDERED variants actually accept a
> > SI_ORDER_* value to determine how drivers contained in a single .ko file
> > are registered (in particular if you have several drivers in a .ko file
> > you typically want the "top-most" driver to attach last so that all the
> > other drivers are ready once the actual device is attached).
> >
> Why not use _ORDERED here to achieve same thing?  _ORDERED(,
> SI_ORDER_LAST, BUS_PASS_BUS)?
> 
> I am thinking to add some macro like BUS_DRIVER_MODULE, INT_DRIVER_MODULE,
> TIMER_DRIVER_MODULE, so that the driver can declare itself in such way. If
> we can avoid usage of BUS_PASS_ORDER_XXX, the macro is much cleaner.
> 
> I am plan to do is: in autoconf phase, first load timer, int and some bus,
> etc low level drivers first, then set cold=0, then load other driver to
> work around the problem that driver needs special handling on cold which is
> not necessary. of course, this may depends on your change of ap_startup.
> thoughts?

I would like to get to that, but the path on x86 is a bit messier.  Ideally
the order looks something like this:

- enumerate the tree (BUS_PASS_BUS)
- reserve fixed-resources (things like acpi_sysres) (BUS_PASS_RESOURCE)
- reserve existing resources that could be moved or disabled if
  their is a conflict (think PCI BARs programmed by firmware and/or
  doing an initial pass of BARs)
- interrupt controllers (may need resources) (BUS_PASS_INTR)
- timers (probably need resources, need interrupts) (BUS_PASS_TIMER)

Then all the rest.

However, it ends up a bit messier on x86 at least.  I have a WIP to at
least start doing BUS_PASS_BUS for x86, but I found that I really need
some ACPI bits to probe before the ACPI 'pcib' driver, so I've ended
up with a kind of 'BUS_PASS_PREBUS' for acpi0, and even then it turns out
that in some cases we need more granularity than just 'BUS_PASS_xxx'.

SI_ORDER_* with ORDERED will not help as all the drivers are registered
at SI_SUB_DRIVERS during boot (which is when the SI_ORDER_* applies),
but the device tree is enumerated and attached at SI_SUB_CONFIGURE.

And yes, the AP startup stuff is a precursor for this.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Nathan Whitehorn]

On 04/19/16 10:55, Roger Marquis wrote:

Please, consider ops and admins, who must support old installations,
often made by other, not-reachable, people, and stuff like this,


Ops and admins such as myself are exactly the ones who will benefit most
from base packages.  Being able run to: 1) 'pkg audit' and see that base
ssl has a vulnerability, 2) 'pkg install -f' to update 3) only those
specific parts of base that need to be updated is far simpler (KIS) and
faster than what we go through now.  More than a few formerly bsd shops
have migrated to linux simply to avoid regular iterations of cd
/usr/src; svn up; make cleanworld; make buildworld installworld ...

The use cases for granular base packages are more numerous than even
these obvious ones.  The downside OTOH, seems to consist of not much
more than the size of the package list.  If I missed other issues please
do clarify.  Will base packages be improved, sure, but they're already
more useful and bugfree than pkgng when it was mandated.

In any case, if I'm not mistaken base packages are entirely optional.

Roger Marquis



Thanks, Roger. That seems perfectly reasonable. I'm not sure that goal 
is really met by having 800 packages, though, or at least I see no 
particular gain relative to a handful (where things like OpenSSL or 
sendmail would be discrete things). (Almost) every single individual 
library in the base system is right now its own single-file package, 
which is what I am objecting to. The upside of that seems pretty dubious 
and the downside is that it is much easier to accidentally put the 
system into an inconsistent state. Is there a reason you want to have 
such very fine discretization?

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

Re: [CFT] packaging the base system with pkg(8)

[Roger Marquis]

Please, consider ops and admins, who must support old installations,
often made by other, not-reachable, people, and stuff like this,


Ops and admins such as myself are exactly the ones who will benefit most
from base packages.  Being able run to: 1) 'pkg audit' and see that base
ssl has a vulnerability, 2) 'pkg install -f' to update 3) only those
specific parts of base that need to be updated is far simpler (KIS) and
faster than what we go through now.  More than a few formerly bsd shops
have migrated to linux simply to avoid regular iterations of cd
/usr/src; svn up; make cleanworld; make buildworld installworld ...

The use cases for granular base packages are more numerous than even
these obvious ones.  The downside OTOH, seems to consist of not much
more than the size of the package list.  If I missed other issues please
do clarify.  Will base packages be improved, sure, but they're already
more useful and bugfree than pkgng when it was mandated.

In any case, if I'm not mistaken base packages are entirely optional.

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

Re: [CFT] packaging the base system with pkg(8)

[Lev Serebryakov]

On 19.04.2016 19:36, Alfred Perlstein wrote:

> Why is this even happening in email?  If folks want "the right solution"
> then why aren't they submitting patches or pull requests to the pkg repo
> (or where ever this is stored?).  This seems counter-intuitive, but
> really actually should be how it works. 
  Ops should send patches with non-trivial code? Please, keep it in
mind: here are thousands of SYSTEM ADMINISTRATORS / OPS (not fancy and
trendy DevOps), who will use (and praise or suffer) new packaged system.
Many of them understand, what is good and what is bad for them, but they
CAN NOT and SHOULD NOT code in C and "submit patches".

 Now your, effectively, say "we are interested only in opinions of
developers, not end-users". It is wtong-wrong-wrong.

 It is what Slawa try to tell: not developers will support thousands of
servers which will have 755 packages only for base system, but admins
and ops, and they have OTHER priorities over developers. And, of course,
most of them could not send high-quality patches to such complex pieces
of software as pkg or FreeBSD build system.

-- 
// Lev Serebryakov



signature.asc
Description: OpenPGP digital signature

Re: [CFT] packaging the base system with pkg(8)

[Lev Serebryakov]

On 19.04.2016 19:28, Nathan Whitehorn wrote:

> 3. Have ~10 meta packages that just depend on sets of the 755 packages
> and hide the internal details. This gives the user experience of (1)
> with the implementation of (2), and is marginally more complex than either.
  How does it help Slawa with his broken system when "pkg upgrade"
replace only half of "base" packages?

 Meta-packages as they are now: "no files, only dependencies" doesn't
help here at all.

  Really, if I want "base but no sendmail" I want easy way to see it
after 5 years after installation, and 755 packages, covered or not by
meta-packages, will need me to read all list of 754 packages to see,
that there is no sendmail, for example. It is trivial example, but it is
completely valid. And there are many other such corner cases, which is
common for administrators and ops, but not for developers.

 Please, consider ops and admins, who must support old installations,
often made by other, not-reachable, people, and stuff like this,

-- 
// Lev Serebryakov



signature.asc
Description: OpenPGP digital signature

Re: [CFT] packaging the base system with pkg(8)

[Alfred Perlstein]

I don't think we need 100% consensus to proceed on anything and if I've 
learned anything from 20 years in this community is that forcing that 
issue does the community a huge disservice as well as turn off the code 
submitters.   See my thread on the missed opportunities in threads, or 
if you want I can paint the picture of what caused SMP to lag half a 
decade behind Linux as well.


I would say that if someone submitted a patch for /dev/givemeroot, sure 
that would be righteously shot down but to force the whole, entire, 
"right" solution the first time around is remarkably blocking and unfair 
to the community and submitters as well.


Why is this even happening in email?  If folks want "the right solution" 
then why aren't they submitting patches or pull requests to the pkg repo 
(or where ever this is stored?).  This seems counter-intuitive, but 
really actually should be how it works. Specifically: if you like where 
an idea is going, then don't block the code, submit improvements on top 
of it.  Stone soup it if you will.


-Alfred

On 4/19/16 9:28 AM, Nathan Whitehorn wrote:
Well, this discussion has gone pretty far off of the rails. I am of 
course happy to make a patch that cuts this down to 10 packages, but 
that's not something that should be committed without agreement -- 
which we obviously don't have. It would have been good to have had 
meaningful discussion of this before.


There are basically three workable options:
1. Have fewer packages. This is easy to implement and preserves the 
integrity of the base system (as well as unified versioning so that a 
system at some particular patch level will have the same global 
state). I have not seen any meaningful downside suggested to this so 
far except for marginally higher load on update servers.
2. Have 755 packages. This makes it harder to version the system and 
makes the user interface significantly worse (my opinion, but shared 
by others). This is the easiest to implement since it is already 
implemented.
3. Have ~10 meta packages that just depend on sets of the 755 packages 
and hide the internal details. This gives the user experience of (1) 
with the implementation of (2), and is marginally more complex than 
either.


Other things (the overlapping packages idea, for instance) are way too 
complex and will just lead to breakage. Can anyone provide an argument 
against (1) or, alternatively, for (2)? (2) seems to add a lot of 
complexity for no clear gain and I remain pretty confused about why it 
was chosen.

-Nathan

On 04/18/16 20:17, Alfred Perlstein wrote:
Maybe what the "too many packages" folks need to do is write some 
code to hide that it's so many packages.


:)

I think the rule of two feet should be applied here.

What we have is people that have worked quite hard to bring us 
something that we can easily work with, and on the other hand some 
folks that want something they consider even better. Personally I 
can't see how having the system less granular is better, since having 
it MORE granular is actually harder work.


Can someone on the "too many packages" campaign here explain to me 
how having too fine a granularity stops you from making macro 
packages containing packages?


Because honestly I can't see how having granularity hurts at all when 
if someone wanted to make it less granular all they would have to do 
is make some meta-packages.


-Alfred

On 4/18/16 7:23 PM, Lyndon Nerenberg wrote:

On 2016-04-18 7:01 PM, Roger Marquis wrote:

Can you explain what would be accomplished by testing all or even a
fraction of the possible permutations of base package 
combinations?  We

don't do that for ports.


The ports tree isn't a mandatory part of the system. And by 
definition it could not be tested that way, since it offers so many 
alternative implementations of specific functionality.



Other operating systems don't do that for
their base packages.


I'm pretty sure Solaris had some fairly hard-core regression tests 
to ensure basic system functionality wouldn't be compromised by 
'oddball' selections of packages offered up at install time.


> Honestly, some of us are wondering what exactly is
> behind some of these concerns regarding base packages.

The concern is from all of us UNIX dinosaurs who predate the 
fine-grained packaging environment, which just worked, and who now 
rip our (little remaining) hair out due to unsolvable package 
dependency loops in the Linux machines we are forced to administer 
in order to pay rent.  For me, as a sysadmin, I derive a negative 
benefit from this optimization.


I guess what I'm really asking is: where is the peer reviewed 
research that shows this actually improves things for the not-1% of 
FreeBSD users?


--lyndon

P.S.  Don't turn this into a pissing match.  I really want to know 
how this is of net benefit to everyone.  But I don't want 
hyperbole.  I have looked at a lot of, e.g., USENIX and ACM, 
bibliographies and papers for justification for this, and I 

Re: [CFT] packaging the base system with pkg(8)

[Nathan Whitehorn]

Well, this discussion has gone pretty far off of the rails. I am of 
course happy to make a patch that cuts this down to 10 packages, but 
that's not something that should be committed without agreement -- which 
we obviously don't have. It would have been good to have had meaningful 
discussion of this before.


There are basically three workable options:
1. Have fewer packages. This is easy to implement and preserves the 
integrity of the base system (as well as unified versioning so that a 
system at some particular patch level will have the same global state). 
I have not seen any meaningful downside suggested to this so far except 
for marginally higher load on update servers.
2. Have 755 packages. This makes it harder to version the system and 
makes the user interface significantly worse (my opinion, but shared by 
others). This is the easiest to implement since it is already implemented.
3. Have ~10 meta packages that just depend on sets of the 755 packages 
and hide the internal details. This gives the user experience of (1) 
with the implementation of (2), and is marginally more complex than either.


Other things (the overlapping packages idea, for instance) are way too 
complex and will just lead to breakage. Can anyone provide an argument 
against (1) or, alternatively, for (2)? (2) seems to add a lot of 
complexity for no clear gain and I remain pretty confused about why it 
was chosen.

-Nathan

On 04/18/16 20:17, Alfred Perlstein wrote:
Maybe what the "too many packages" folks need to do is write some code 
to hide that it's so many packages.


:)

I think the rule of two feet should be applied here.

What we have is people that have worked quite hard to bring us 
something that we can easily work with, and on the other hand some 
folks that want something they consider even better.  Personally I 
can't see how having the system less granular is better, since having 
it MORE granular is actually harder work.


Can someone on the "too many packages" campaign here explain to me how 
having too fine a granularity stops you from making macro packages 
containing packages?


Because honestly I can't see how having granularity hurts at all when 
if someone wanted to make it less granular all they would have to do 
is make some meta-packages.


-Alfred

On 4/18/16 7:23 PM, Lyndon Nerenberg wrote:

On 2016-04-18 7:01 PM, Roger Marquis wrote:

Can you explain what would be accomplished by testing all or even a
fraction of the possible permutations of base package combinations?  We
don't do that for ports.


The ports tree isn't a mandatory part of the system. And by 
definition it could not be tested that way, since it offers so many 
alternative implementations of specific functionality.



Other operating systems don't do that for
their base packages.


I'm pretty sure Solaris had some fairly hard-core regression tests to 
ensure basic system functionality wouldn't be compromised by 
'oddball' selections of packages offered up at install time.


> Honestly, some of us are wondering what exactly is
> behind some of these concerns regarding base packages.

The concern is from all of us UNIX dinosaurs who predate the 
fine-grained packaging environment, which just worked, and who now 
rip our (little remaining) hair out due to unsolvable package 
dependency loops in the Linux machines we are forced to administer in 
order to pay rent.  For me, as a sysadmin, I derive a negative 
benefit from this optimization.


I guess what I'm really asking is: where is the peer reviewed 
research that shows this actually improves things for the not-1% of 
FreeBSD users?


--lyndon

P.S.  Don't turn this into a pissing match.  I really want to know 
how this is of net benefit to everyone.  But I don't want hyperbole.  
I have looked at a lot of, e.g., USENIX and ACM, bibliographies and 
papers for justification for this, and I can't find it.  It would 
really help (me, at least) if someone could take a moment to point me 
at demonstrable evidence of the benefits of this model.

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




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




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

Re: [CFT] packaging the base system with pkg(8)

[Lev Serebryakov]

On 19.04.2016 17:33, Alfred Perlstein wrote:

> I am also confident that we will very easily sort out how to make
> "micropackages" or some such mechanism within at most 3 months after the
> code lands.  The reason why is because I already see some excellent
> proposals for such mechanisms in this thread.
 I could see only two proposals: meta-packages (which is not a solution,
but kludge, IMHO) from numerous people and proposal from Slawa about
"overlapped" and "file-removal" packages, which is not discussed at all
(https://lists.freebsd.org/pipermail/freebsd-current/2016-April/060688.html).

 I really like Slawa approach, but it requires much more sophisticated
pkg, including additional metadata, etc.

-- 
// Lev Serebryakov



signature.asc
Description: OpenPGP digital signature

Re: [CFT] packaging the base system with pkg(8)

[Slawa Olhovchenkov]

On Tue, Apr 19, 2016 at 08:18:48AM -0700, Alfred Perlstein wrote:

> 1) Graciously and rapidly accept steps forward and then contribute to 
> them.  Anything else leaves you stagnant and worse for wear.
> 2) Simple over complex.
> 3) If something someone else did is working for someone, then copy it 
> and move on, don't waste a huge amount of your customer's time trying to 
> make something better until you are sure that just copying it will not 
> suffice.

What is simple -- split base to 10 packages or split base to 800
packages? I think first.
What need for succesufult moved forward after this?
I think ability of spliting and mergering packages at upgrade.
(clang-base => clang-base-c + clang-base-c++, for example.
or clang-base-c + clang-base-c++ => clang-base).

What need for security updates?
I think ability to have file with common name and different content
with multiple installed packages:

base-11.0 contains /usr/sbin/ntpd
 base-11.0-CVE-1234 direct depends to base-11.0 and contains overlaped 
/usr/sbin/ntpd

As result: few packages, compact security updates, ability to
repackage base.

Optionaly, ability to have packages with "dummy" content, for example
 no-base-ntp-11.0 have record (w/o actual content) about
  /usr/sbin/ntpd with size -791552 (negative size) and checksum of
 actual file, for removing some components.

For this feature give ability to have "skins" packages, installed over
main package.


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

Re: [CFT] packaging the base system with pkg(8)

[Lev Serebryakov]

On 18.04.2016 22:14, Glen Barber wrote:

>>> I understand, that maybe it is too late, but ARE YOU KIDDING?! 755
>>> packages?! WHY?! What are reasons and goals to split base in such
>>> enormous number of packages?
>>
>> Just a guess, having done the same thing myself:  it means that updates can 
>> be
>> more targeted.
>>
> This is exactly the reason, which has been answered numerous times.
 Does somebody noticed, that it looks broken now:

https://lists.freebsd.org/pipermail/freebsd-current/2016-April/060687.html

https://lists.freebsd.org/pipermail/freebsd-current/2016-April/060690.html

 And it is exactly concern: it hard to notice such breakage, as there is
hundreds of packages.

-- 
// Lev Serebryakov



signature.asc
Description: OpenPGP digital signature

Re: Mis-use of BUS_PASS_ORDER_MIDDLE

[Howard Su]

On Tue, Apr 19, 2016 at 2:53 AM John Baldwin  wrote:

> On Monday, April 18, 2016 11:10:12 PM Howard Su wrote:
> > I noticed several places there are code like this, especially in some arm
> > low level drivers.
> > EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devclass,
> > 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE);
> >
> > ​I feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There are another
> > macro EARLY_DRIVER_MODULE_ORDERED, which take an additional parameter
> > "order". I believe BUS_PASS_ORDER_xxx is used for that parameter.
>
> No, this is actually correct.  The _ORDERED variants actually accept a
> SI_ORDER_* value to determine how drivers contained in a single .ko file
> are registered (in particular if you have several drivers in a .ko file
> you typically want the "top-most" driver to attach last so that all the
> other drivers are ready once the actual device is attached).
>
Why not use _ORDERED here to achieve same thing?  _ORDERED(,
SI_ORDER_LAST, BUS_PASS_BUS)?

I am thinking to add some macro like BUS_DRIVER_MODULE, INT_DRIVER_MODULE,
TIMER_DRIVER_MODULE, so that the driver can declare itself in such way. If
we can avoid usage of BUS_PASS_ORDER_XXX, the macro is much cleaner.

I am plan to do is: in autoconf phase, first load timer, int and some bus,
etc low level drivers first, then set cold=0, then load other driver to
work around the problem that driver needs special handling on cold which is
not necessary. of course, this may depends on your change of ap_startup.
thoughts?


> --
> John Baldwin
>
-- 
-Howard
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Alfred Perlstein]

On 4/19/16 7:47 AM, dan_partelly wrote:



Look, take a look at history and the Linux kernel threads story and its
impact on FreeBSD.  If you'd like I can talk about it.


Please, yes, I would love to hear about it.
Sure, so back in late 90s, ~1999 sometime after Solaris released kernel 
threads Linux did as well.


It was pretty laughable, it was basically a hacked up version of fork 
that shared address space, files and a few other things and was horribly 
unstable and you couldn't use most of libc with it as there were many 
single-threaded deps in it.


It was so "laughably bad" that if you logged into a Linux system with 
threads and ran "top", it would look very strange as each thread had its 
own pid.  So if you were running something like mysql it would look like 
you were forkbombed.


Now the point of all of this however was to get threads, and also to get 
threads that did well with disk IO.


FreeBSD at the time had threads, but they were "green threads" or 
"userland threads" which means they were super good for network IO, but 
nearly useless for disk IO.


This made Linux a much better platform for mysql, as mysql performed an 
order of magnitude better on Linux.  In fact not only was FreeBSD 
slower, but in my experience it was buggier because the green threads 
implementation, while very cool, was complex and had its own share of bugs.


Some years passed and many people migrated to Linux to get the high 
performance mysql that was available on the platform.


Now during those years, as more and more people migrated away, FreeBSD 
had many, many, many, oh gosh, so many discussions on what to do about 
threads.  So many opinions were had by so many people during which more 
people moved to Linux as a web platform...  Not only were there 
opinions, but also implementations suggested, but those implementations 
were shot down in the search for the "one true threading system".  Of 
course there were some loud folks that even insisted that threads were 
bad (and probably a phase) and we shouldn't even support them).


Luckily during that time (~2002) someone made this crazy "Linuxthreads" 
port which made """Linuxthreads"""  available on FreeBSD, it had many of 
the same problems, but at least mysql was fast.  Spoiler: The funny part 
about calling it "Linuxthreads" was that "Linuxthreads" wound up being 
the defacto way to do threads across *UNIX* because it was just simple 
and worked, should have just called it "realthreads" in my opinion.  
Luckily with the Linuxthreads port the die hards in the FreeBSD 
community who needed to run mysql for performance (or other software 
requiring real threads) could stay using FreeBSD while the community 
sorted out what exactly was to be done.


Places like Yahoo moved off of FreeBSD because they "just wanted 
threads" and if you tell someone to get "good performance with threads, 
then use Linuxthreads" (and of course make a grumpy face because "it's 
Linux") then they reason, "geez, why I am not just using Linux anyhow?" 
which they then migrate to.


So some years later (~2005) we went with a far more complex solution 
than needed called libkse.  Libkse offered N:M threads, which didn't 
work very well for years due to complexity (hats off to those that 
*tried* to get it working in FreeBSD's political climate) to which 
finally Sun abandoned its N:M threads because they themselves could 
never get it right, and finally FreeBSD switched to 1:1 threads 
following Solaris.  That was probably in 2007 timeline.


Now rewind to ~2001, about 2 years after the introduction of the sloppy, 
weird and strange kernel threads in Linux, and they had a pretty solid 
implementation.  It wouldn't be until nearly 2009 when FreeBSD had a 
truly solid threads library and even now it suffers due to added 
complexity because we did things "smarter" than Linux.


Moral of the story?   My takeaways from this story (and there are many 
similar ones in our recent history) are:


1) Graciously and rapidly accept steps forward and then contribute to 
them.  Anything else leaves you stagnant and worse for wear.

2) Simple over complex.
3) If something someone else did is working for someone, then copy it 
and move on, don't waste a huge amount of your customer's time trying to 
make something better until you are sure that just copying it will not 
suffice.


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

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

> 
> Look, take a look at history and the Linux kernel threads story and its 
> impact on FreeBSD.  If you'd like I can talk about it.
> 

Please, yes, I would love to hear about it.

> -Alfred
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

issue with /etc/rc.d/mountd script

[Kurt Lidl]

Greetings all.

I saw something the other day on a machine running 10/stable
(but the same code exists in -current), when it was rebooting.

The machine acts as a NFS fileserver (to support diskless booting
of a few test machines).  It only has ZFS filesystems, and only
has filesystems that are exported via ZFS properties.

So, it has /etc/zfs/exports, but no /etc/exports.

When mountd is started up, it emits a error, because the
required_files is set to /etc/exports.

I think the correct thing is to either remove the required_files
setting, or build it from /etc/exports and/or /etc/zfs/exports
and only fail if neither of those files exists.

(Yes, I could just create an empty /etc/exports file, but that's
kinda lame.)

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

Re: [CFT] packaging the base system with pkg(8)

[Alfred Perlstein]

On 4/19/16 7:39 AM, dan_partelly wrote:

What should not happen is that this incremental step forward be blocked
by those unwilling to hash out the next steps.

-Alfred



While incremental steps forward are great, how do you avoid situations
like VNET, where a "good enough" enough implementation, usable in some
scenarios lingered for years in kernel, but to this day it suffers from
leaks and bugs. Once you go down the path of enabling it in this state,
chances are that it will stay that way for more than half a decade.





We happened to use VNET at our last company with great success.  Had it 
not existed we would have been much further away from our goals. Maybe 
you picked a bad example? :)


Look, take a look at history and the Linux kernel threads story and its 
impact on FreeBSD.  If you'd like I can talk about it.


-Alfred

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

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

> 
> What should not happen is that this incremental step forward be blocked 
> by those unwilling to hash out the next steps.
> 
> -Alfred
> 
> 

While incremental steps forward are great, how do you avoid situations
like VNET, where a "good enough" enough implementation, usable in some 
scenarios lingered for years in kernel, but to this day it suffers from
leaks and bugs. Once you go down the path of enabling it in this state, 
chances are that it will stay that way for more than half a decade. 





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

Re: [CFT] packaging the base system with pkg(8)

[Alfred Perlstein]

It is very important to understand that a packaged base is extremely 
useful for those building any sort of distro or appliance distro.


So although the concept of "user serviceable" is important, it's not 
just that.  Such a change makes it easy for a distro or appliance making 
to cherry pick updates to the system without having to pull the entire 
system forward.


One of the huge pains about using FreeBSD at my last work was that the 
base system as a whole was a bit challenging to pry apart so that an 
incremental update could happen.  Let's say I needed a patch to openssl, 
well that was HARD even for me.  My choices were to update the whole 
system (which broke things), pull in patches and apply them (hard and 
scary), figure out a way to pull it from ports instead... super hard as 
"base" built before ports in "nanobsd".


Quite frankly I didn't have the time for it.  As someone who laid the 
foundation for an FreeBSD appliance, I wholeheartedly welcome this, it 
will be HUGE for appliance builders.


I am also confident that we will very easily sort out how to make 
"micropackages" or some such mechanism within at most 3 months after the 
code lands.  The reason why is because I already see some excellent 
proposals for such mechanisms in this thread.


-Alfred

On 4/19/16 12:54 AM, David Chisnall wrote:

On 19 Apr 2016, at 08:44, Julian Elischer  wrote:

All this can be done by meta-packages which depend on larger package groups.

Currently Metapackage is a way to make 10 packages look like 11 packages.  The 
framework needs to understand to hide the 10 internal packages if they are part 
of a metapackage.

I agree, and patches to do this are very welcome.  Currently, pkg is short of 
contributors.

I see basically three use cases for a packaged base:

1) People wanting a FreeBSD install to use as a server or workstation.  These 
people will install the FreeBSD 11 metapackage and not care that it is a few 
hundred MBs.  It would be nice if the pkg tool could present this as a single 
package in list views, but that’s a UI issue with pkg, not an issue with the 
number of packages in the base system.

2) People wanting to install embedded systems.  Anyone who has tried to run 
FreeBSD on a system with a small amount of flash storage will have encountered 
the pain of having to use some kind of ad-hoc update.  Being able to manage 
updates to these systems with the same packaging tool as you manage big systems 
is a big improvement.

3) People wanting to install service jails (sorry, containerised applications). 
 These want the smallest possible attack surface and so want the smallest 
amount of the base system that they can have.  Here, small packages are an 
advantage.  It will take a little while for ports to learn enough about the 
granularity of the base system for this to really be useful, but it would be 
great to be able to install nginx, for example, in a jail and have only the 
handful of libraries that it needs.

The big advantage of going with small packages initially, however, is that it 
will allow us to get some data on what the correct groupings are.  If we have 
large packages, then it’s very hard to tell which subsets of the packages 
people want.  That’s exactly the situation that we’re in now: we know some 
people don’t want docs or games, but that’s about all that we know.  It’s easy 
to move to a model where we have *fewer* packages in the future, but it’s 
harder to split them.  That also applies to dependencies.  If I know that a 
port depends on the shell, then it’s easy to update it from depending on a sh 
package to depending on a core system utilities package automatically, but it’s 
very hard to do an automatic update in the other direction.

David



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

Re: [CFT] packaging the base system with pkg(8)

[Slawa Olhovchenkov]

On Tue, Apr 19, 2016 at 07:27:52AM -0700, Alfred Perlstein wrote:

> Again, the point is that those objecting should put aside the time to 
> implement what you (and I) are suggesting:
> 
> > I could live with:
> >
> > base-utils11.1
> >  - ktrace  uninstalled
> >  - tcpdump uninstalled
> >  + dd  11.1.1   (CVE-123412 fix)
> >
> >
> >
> > but not
> > {700 packages )
> > dd  11.1.1 dd with CVE fix
> > {29 more packages}
> > [tcpdump line is not present but you don't notice that]
> > {10 more packages}
> > [ktrace line would be here but you don't notice that either]
> > {15 more packages}
> 
> What should not happen is that this incremental step forward be blocked 
> by those unwilling to hash out the next steps.

Teoretical.
In practical this is happen with me.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Alfred Perlstein]

Again, the point is that those objecting should put aside the time to 
implement what you (and I) are suggesting:



I could live with:

base-utils11.1
 - ktrace  uninstalled
 - tcpdump uninstalled
 + dd  11.1.1   (CVE-123412 fix)



but not
{700 packages )
dd  11.1.1 dd with CVE fix
{29 more packages}
[tcpdump line is not present but you don't notice that]
{10 more packages}
[ktrace line would be here but you don't notice that either]
{15 more packages}


What should not happen is that this incremental step forward be blocked 
by those unwilling to hash out the next steps.


-Alfred


On 4/19/16 12:44 AM, Julian Elischer wrote:

On 19/04/2016 5:29 AM, Alfred Perlstein wrote:
Guys please stop arguing about the number of packages.  The high 
granularity is VERY useful!



it's going to make us a laughing stock
"look FreeBSD just split into 1.43 million packages" (effectively the 
same number.. it's bigger than 10)



Managing large groups of small packages is much easier than just 
having large packages.
err, Alfred, what planet do you live on? when they get out of sync it 
becomes a nightmare.
If you also had a packaging system that was smart enough to manage a 
hierarchy of packages then "maybe"..




All this can be done by meta-packages which depend on larger package 
groups.
Currently Metapackage is a way to make 10 packages look like 11 
packages.  The framework needs to understand to hide the 10 internal 
packages if they are part of a metapackage.


Later pkg can be augmented to "remove packages not explicitly 
installed" which would remove leaf packages.


Example: you installed "base-debug" which pulls in let's say 50 small 
packages, later you want all of those removed, you can do something 
like:  "pkg delete --leafs base-debug" which should delete 
"base-debug" and any dangling packages it pulled in not required by 
other pkgs.


Huge thanks to the team that implemented this!


I'm sure the work was large and will be useful in the future but we 
are not ready to have the system installed like this.
no-one wants to see 750 packages show up when you do an enquiry on a 
newly installed system.

I could live with:

base-utils11.1
 - ktrace  uninstalled
 - tcpdump uninstalled
 + dd  11.1.1   (CVE-123412 fix)



but not
{700 packages )
dd  11.1.1 dd with CVE fix
{29 more packages}
[tcpdump line is not present but you don't notice that]
{10 more packages}
[ktrace line would be here but you don't notice that either]
{15 more packages}


In other words, I have no objection to all the utilities coming in the 
form of little packages.
but I have a major objection if that fact is at all obvious to the end 
user,
and certainly if we need to wade through 750 packages to see what's 
going on.




thanks.
-Alfred

On 4/18/16 1:07 PM, Lev Serebryakov wrote:

On 18.04.2016 22:40, Glen Barber wrote:


This granularity allows easy removal of things that may not be wanted
(such as *-debug*, *-profile*, etc.) on systems with little 
storage.  On

one of my testing systems, I removed the tests packages and all debug
and profiling, and the number of base system packages is 383.

  IMHO, granularity like "all base debug", "all base profile" is enough
for this. Really, I hardly could imagine why I will need only 1 
debug or

profile package, say, for csh. On resource-constrained systems NanoBSD
is much better anyway (for example, my typical NanoBSD installation is
37MB base system, 12MB /boot and 10 packages), and on developer system
where you need profiled libraries it is Ok to install all of them and
don't think about 100 packages for them.

  Idea of "Roles" from old FreeBSD installers looks much better. Again,
here are some "contrib" software which have one-to-one replacements in
ports, like sendmail, ssh/sshd, ntpd, but split all other
FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static libraries.
Yes, lib32 on 64 bit system.

   It seems that it is ideological ("holy war") discussion more than
technical one...



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






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

Re: [CFT] packaging the base system with pkg(8)

[Slawa Olhovchenkov]

On Tue, Apr 19, 2016 at 12:27:51PM +0200, Lars Engels wrote:

> On Tue, Apr 19, 2016 at 12:18:00PM +0300, dan_partelly wrote:
> > 
> > be as terse as possible. You guys seen the "Add remove programs"
> >  in Windows control panel ? Thats sane. Even now the default output  
> > of pkg borders insane, when you have many packages installed. 99% of my
> > time
> > I dont really care about lib-rtyum546.78.9. I care only less than 1% of my
> > time when something 
> > goes wrong. 
> 
> Don't use "pkg info" then. Use "pkg leaf":
> 
> % pkg info | wc -l
>  249
> % pkg leaf | wc -l
>   25
> 
> "leaf" is an alias for:
> pkg 'query -e "%a == 0" "%n-%v"'

slw@pkg-test:~ % pkg leaf | wc -l
   1
slw@pkg-test:~ % pkg leaf 
pkg-1.7.2
slw@pkg-test:~ % pkg info | wc -l
 756

> And to everyone complaining about the number of packages: How many of
> you have actually used the packaged base?


Wrong question: I am already complain about Xorg spliting.

Some servers managed by me have 53 packages, included 29 as p5-libwww.

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

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

I dont know if you missed the point of my message on purpose or not.

I never pretended that you can't extract that information. I maintain that
having sane defaults would empower me to almost never care about aliases,
scripts
pipes, filter , regular expressions and what not. It is great that all
this power
is at my fingertips, in case something goes awfully wrong , not so great
when Im forced
to use it. 

And I really don't see how this helps anyway, since number of leafs will 
increase anyway with package base. 

Let me reiterate, perhaps clearer this time:

It is my opinion that sane defaults beat ANY script, obscure command line
arguments, 
alias, pipe, filter, helper program. 



> 
> Don't use "pkg info" then. Use "pkg leaf":
> 



 
> And to everyone complaining about the number of packages: How many of
> you have actually used the packaged base?

This question is irrelevant. 

1.First of all, many people consider packaging base a great
accomplishment, 
yet maybe not ready for prime-time, given the current way pkg handles this

information. I personally love the idea, with the caveats above. 

2. The issue is present with all meta-packages in general. The base
packaging
only exacerbate an existing issue with the sheer number of packages it
presents. 


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

Re: [CFT] packaging the base system with pkg(8)

[Lars Engels]

On Tue, Apr 19, 2016 at 12:18:00PM +0300, dan_partelly wrote:
> 
> be as terse as possible. You guys seen the "Add remove programs"
>  in Windows control panel ? Thats sane. Even now the default output  
> of pkg borders insane, when you have many packages installed. 99% of my
> time
> I dont really care about lib-rtyum546.78.9. I care only less than 1% of my
> time when something 
> goes wrong. 

Don't use "pkg info" then. Use "pkg leaf":

% pkg info | wc -l
 249
% pkg leaf | wc -l
  25

"leaf" is an alias for:
pkg 'query -e "%a == 0" "%n-%v"'


And to everyone complaining about the number of packages: How many of
you have actually used the packaged base?


pgpBUdMf8hTH6.pgp
Description: PGP signature

FreeBSD_HEAD_i386 - Build #2901 - Fixed

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #2901 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2901/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2901/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2901/console

Change summaries:

298257 by delphij:
Fix build breakage introduced by r298253.

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

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

For what is worth, I agree with Julian Elischer. I do not 
want to see hundreds of packages over tenths of screen pages. 

Computers are supposed to make our life simpler. Human time is
very expensive. CPU time, almost free. And this include that I really 
shouldn't have to think for usual work of any grep, sed , regexpes, 
pkg --leafs whatever. The default high level output of a tool like pkg
should 
be as terse as possible. You guys seen the "Add remove programs"
 in Windows control panel ? Thats sane. Even now the default output  
of pkg borders insane, when you have many packages installed. 99% of my
time
I dont really care about lib-rtyum546.78.9. I care only less than 1% of my
time when something 
goes wrong. 

The program | filter pipeline of Unix is very powerful. Whats more
powerful is 
SANE DEFAULTS to make filters completely unnecessary. The open source Unix
world has a lot
to learn from Cupertino and Redmond. Keep things simple please. DO not
pollute my screens
with unnecessary information. When Ill want that info, Ill ask for it with
a command line flag,
then maybe filter it if necessary. 


On Tue, 19 Apr 2016 15:44:41 +0800, Julian Elischer 
wrote:
> On 19/04/2016 5:29 AM, Alfred Perlstein wrote:
>> Guys please stop arguing about the number of packages.  The high 
>> granularity is VERY useful!
>>
> it's going to make us a laughing stock
> "look FreeBSD just split into 1.43 million packages" (effectively the 
> same number.. it's bigger than 10)
> 
> 
>> Managing large groups of small packages is much easier than just 
>> having large packages.
> err, Alfred, what planet do you live on? when they get out of sync it 
> becomes a nightmare.
> If you also had a packaging system that was smart enough to manage a 
> hierarchy of packages then "maybe"..
> 
>>
>> All this can be done by meta-packages which depend on larger package 
>> groups.
> Currently Metapackage is a way to make 10 packages look like 11 
> packages.  The framework needs to understand to hide the 10 internal 
> packages if they are part of a metapackage.
>>
>> Later pkg can be augmented to "remove packages not explicitly 
>> installed" which would remove leaf packages.
>>
>> Example: you installed "base-debug" which pulls in let's say 50 
>> small packages, later you want all of those removed, you can do 
>> something like:  "pkg delete --leafs base-debug" which should delete 
>> "base-debug" and any dangling packages it pulled in not required by 
>> other pkgs.
>>
>> Huge thanks to the team that implemented this!
> 
> I'm sure the work was large and will be useful in the future but we 
> are not ready to have the system installed like this.
> no-one wants to see 750 packages show up when you do an enquiry on a 
> newly installed system.
> I could live with:
> 
> base-utils11.1
>   - ktrace  uninstalled
>   - tcpdump uninstalled
>   + dd  11.1.1   (CVE-123412 fix)
> 
> 
> 
> but not
> {700 packages )
> dd  11.1.1 dd with CVE fix
> {29 more packages}
> [tcpdump line is not present but you don't notice that]
> {10 more packages}
> [ktrace line would be here but you don't notice that either]
> {15 more packages}
> 
> 
> In other words, I have no objection to all the utilities coming in the
> form of little packages.
> but I have a major objection if that fact is at all obvious to the end
> user,
> and certainly if we need to wade through 750 packages to see what's
going
> on.
> 
>>
>> thanks.
>> -Alfred
>>
>> On 4/18/16 1:07 PM, Lev Serebryakov wrote:
>>> On 18.04.2016 22:40, Glen Barber wrote:
>>>
 This granularity allows easy removal of things that may not be wanted
 (such as *-debug*, *-profile*, etc.) on systems with little 
 storage.  On
 one of my testing systems, I removed the tests packages and all debug
 and profiling, and the number of base system packages is 383.
>>>   IMHO, granularity like "all base debug", "all base profile" is 
>>> enough
>>> for this. Really, I hardly could imagine why I will need only 1 
>>> debug or
>>> profile package, say, for csh. On resource-constrained systems NanoBSD
>>> is much better anyway (for example, my typical NanoBSD installation is
>>> 37MB base system, 12MB /boot and 10 packages), and on developer system
>>> where you need profiled libraries it is Ok to install all of them and
>>> don't think about 100 packages for them.
>>>
>>>   Idea of "Roles" from old FreeBSD installers looks much better. 
>>> Again,
>>> here are some "contrib" software which have one-to-one replacements in
>>> ports, like sendmail, ssh/sshd, ntpd, but split all other
>>> FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static 
>>> libraries.
>>> Yes, lib32 on 64 bit system.
>>>
>>>It seems that it is ideological ("holy war") discussion more than
>>> technical one...
>>>
>>
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, 

Re: [CFT] packaging the base system with pkg(8)

[dan_partelly]

> 
> And nowhere did it say "buildworld/buildkernel would no longer work."
> 
> Glen


It may very well work, but you consider a listing of hundred of packages
on  a 
fresh system a sane default ? 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Slawa Olhovchenkov]

On Tue, Apr 19, 2016 at 08:41:29AM +, Glen Barber wrote:

> On Tue, Apr 19, 2016 at 11:39:11AM +0300, Slawa Olhovchenkov wrote:
> > On Tue, Apr 19, 2016 at 07:31:17AM +, Glen Barber wrote:
> > 
> > > On Tue, Apr 19, 2016 at 03:24:30PM +0800, Julian Elischer wrote:
> > > > We've managed to keep this disease out of BSD since I started to do it 
> > > > in
> > > > 1990. First we laughed/fumed at Sun's Solaris when they unbundled the
> > > > compiler. then we fumed at xorg when hey took a useful package and made 
> > > > 190
> > > > odd packages out of it. Please don't force this on us!
> > > > 
> > > 
> > > What isn't clear about the *numerous* statements that no one is being
> > > *forced* to use packaged base?
> > 
> > Because nowhere present roadmap about co-existing packaged base and
> > traditionsl install.
> > Because nowhere present roadmap of packaged base future.
> > Because package base is show-stoper for 11.0 relese -- this is read as
> > "11.0 switch to package base".
> > 
> 
> And nowhere did it say "buildworld/buildkernel would no longer work."

buildworld/builkernel is requrement for `make packages`.
I am expect of removing installworld/installkernel.
Yes, I am don read about this. But in IT I am need to read between the
lines.
Also, installkernel broken in 10.x for multiple kernels and not planed
to fix. Why I need to expect different to this?


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

Re: qsort() documentation

[Aleksander Alekseev]

> Why Wikipedia, specifically?  There are a lot of places that describe 
> quicksort.  How about just
> 
>Note: This implementation of qsort() is designed to avoid the
>worst-case complexity of N**2 that is often seen with standard
>versions.

I would say that this statement is just false. Worst-case complexity is
still N**2. How about something like:

"""
This implementation of qsort() has worst case complexity of N**2.
However measures were taken that make it very unlikely that for some
random input N**2 swaps will be made. It's still possible to generate
such an input on purpose though. See code below for more details.
"""

-- 
Best regards,
Aleksander Alekseev
http://eax.me/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Glen Barber]

On Tue, Apr 19, 2016 at 11:39:11AM +0300, Slawa Olhovchenkov wrote:
> On Tue, Apr 19, 2016 at 07:31:17AM +, Glen Barber wrote:
> 
> > On Tue, Apr 19, 2016 at 03:24:30PM +0800, Julian Elischer wrote:
> > > We've managed to keep this disease out of BSD since I started to do it in
> > > 1990. First we laughed/fumed at Sun's Solaris when they unbundled the
> > > compiler. then we fumed at xorg when hey took a useful package and made 
> > > 190
> > > odd packages out of it. Please don't force this on us!
> > > 
> > 
> > What isn't clear about the *numerous* statements that no one is being
> > *forced* to use packaged base?
> 
> Because nowhere present roadmap about co-existing packaged base and
> traditionsl install.
> Because nowhere present roadmap of packaged base future.
> Because package base is show-stoper for 11.0 relese -- this is read as
> "11.0 switch to package base".
> 

And nowhere did it say "buildworld/buildkernel would no longer work."

Glen



signature.asc
Description: PGP signature

Re: [CFT] packaging the base system with pkg(8)

[Slawa Olhovchenkov]

On Tue, Apr 19, 2016 at 07:31:17AM +, Glen Barber wrote:

> On Tue, Apr 19, 2016 at 03:24:30PM +0800, Julian Elischer wrote:
> > We've managed to keep this disease out of BSD since I started to do it in
> > 1990. First we laughed/fumed at Sun's Solaris when they unbundled the
> > compiler. then we fumed at xorg when hey took a useful package and made 190
> > odd packages out of it. Please don't force this on us!
> > 
> 
> What isn't clear about the *numerous* statements that no one is being
> *forced* to use packaged base?

Because nowhere present roadmap about co-existing packaged base and
traditionsl install.
Because nowhere present roadmap of packaged base future.
Because package base is show-stoper for 11.0 relese -- this is read as
"11.0 switch to package base".
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Slawa Olhovchenkov]

On Tue, Apr 19, 2016 at 08:54:48AM +0100, David Chisnall wrote:

> 2) People wanting to install embedded systems.  Anyone who has tried
> to run FreeBSD on a system with a small amount of flash storage will
> have encountered the pain of having to use some kind of ad-hoc
> update.  Being able to manage updates to these systems with the same
> packaging tool as you manage big systems is a big improvement.

Not true. For very small system pkg overhead too high and comparable
with size of base. NanoBSD anyway don't updated and build by pkg, only
by slice swap.

> 3) People wanting to install service jails (sorry, containerised
> applications).  These want the smallest possible attack surface and
> so want the smallest amount of the base system that they can have.
> Here, small packages are an advantage.  It will take a little while
> for ports to learn enough about the granularity of the base system
> for this to really be useful, but it would be great to be able to
> install nginx, for example, in a jail and have only the handful of
> libraries that it needs.

Too hard to work. nginx+ngx_lua need additional libraries, ngx_lua
don't show additional dependeses, ports infrastructure don't tests
this dependeses

> 
> The big advantage of going with small packages initially, however,
> is that it will allow us to get some data on what the correct
> groupings are.  If we have large packages, then it’s very hard to
> tell which subsets of the packages people want.  That’s exactly the
> situation that we’re in now: we know some people don’t want docs or
> games, but that’s about all that we know.  It’s easy to move to a
> model where we have *fewer* packages in the future, but it’s harder
> to split them.  That also applies to dependencies.  If I know that a
> port depends on the shell, then it’s easy to update it from
> depending on a sh package to depending on a core system utilities
> package automatically, but it’s very hard to do an automatic update
> in the other direction.

This is too teoretical. In pratical pepole don't want to waste for
select from huge list of strange packaes. Also, systems may live after
install and managed by different person. This person don't be grateful
for docs and manuals absense.

Writing docs and HOWTOS will be harder too: for every line you must be
write "install package foo", "install package bar"...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD_i386 - Build #2900 - Failure

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #2900 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2900/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2900/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2900/console

Change summaries:

298256 by araujo:
Use nitems() from sys/param.h.

MFC after:  2 weeks.

298255 by araujo:
Use nitems() from sys/param.h.

MFC after:  2 weeks.

298254 by eadler:
Rename units.lib -> definitions.units
- this matches GNU units 2.12
add ISO country codes from units 2.12

298253 by eadler:
Rename units.lib -> definitions.units
- this matches GNU units 2.12
add ISO country codes from units 2.12

298252 by adrian:
Add VHT power envelope parsing to ifconfig.



The end of the build log:

[...truncated 124934 lines...]
--- tset.full ---
cc -O2 -pipe -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror 
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings 
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline 
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign 
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments  -o 
tset.full map.o misc.o set.o term.o tset.o wrterm.o   -lncursesw
--- tset.1.gz ---
gzip -cn /usr/src/usr.bin/tset/tset.1 > tset.1.gz
--- tset.debug ---
objcopy --only-keep-debug tset.full tset.debug
--- t-
objcopy --strip-debug --add-gnu-debuglink=tset.debug  tset.full tset
--- all_subdir_usr.bin/tsort ---
===> usr.bin/tsort (all)
--- .depend ---
echo tsort.full: /usr/obj/usr/src/tmp/usr/lib/libc.a  >> .depend
--- tsort.o ---
cc  -O2 -pipe   -g -MD -MP -MF.depend.tsort.o -MTtsort.o -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
 -Qunused-arguments  -c /usr/src/usr.bin/tsort/tsort.c -o tsort.o
--- all_subdir_lib ---
--- m_hook.po ---
cc  -pg  -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. 
-I/usr/obj/usr/src/lib/ncurses/menuw/../ncursesw 
-I/usr/src/lib/ncurses/menuw/../ncursesw 
-I/usr/src/lib/ncurses/menuw/../ncurses 
-I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/include 
-I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG 
-DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu   
-MD -MP -MF.depend.m_hook.po -MTm_hook.po -std=gnu99 -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized 
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef  -Qunused-arguments  -c 
/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_hook.c -o m_hook.po
--- all_subdir_usr.bin ---
--- tsort.full ---
cc -O2 -pipe -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror 
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings 
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline 
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign 
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments  -o 
tsort.full tsort.o  
--- all_subdir_lib ---
--- m_item_cur.po ---
cc  -pg  -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. 
-I/usr/obj/usr/src/lib/ncurses/menuw/../ncursesw 
-I/usr/src/lib/ncurses/menuw/../ncursesw 
-I/usr/src/lib/ncurses/menuw/../ncurses 
-I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/include 
-I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG 
-DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu   
-MD -MP -MF.depend.m_item_cur.po -MTm_item_cur.po -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef  -Qunused-arguments  -c 

Re: [CFT] packaging the base system with pkg(8)

[David Chisnall]

On 19 Apr 2016, at 08:44, Julian Elischer  wrote:
> 
>> All this can be done by meta-packages which depend on larger package groups.
> Currently Metapackage is a way to make 10 packages look like 11 packages.  
> The framework needs to understand to hide the 10 internal packages if they 
> are part of a metapackage.

I agree, and patches to do this are very welcome.  Currently, pkg is short of 
contributors.

I see basically three use cases for a packaged base:

1) People wanting a FreeBSD install to use as a server or workstation.  These 
people will install the FreeBSD 11 metapackage and not care that it is a few 
hundred MBs.  It would be nice if the pkg tool could present this as a single 
package in list views, but that’s a UI issue with pkg, not an issue with the 
number of packages in the base system.

2) People wanting to install embedded systems.  Anyone who has tried to run 
FreeBSD on a system with a small amount of flash storage will have encountered 
the pain of having to use some kind of ad-hoc update.  Being able to manage 
updates to these systems with the same packaging tool as you manage big systems 
is a big improvement.

3) People wanting to install service jails (sorry, containerised applications). 
 These want the smallest possible attack surface and so want the smallest 
amount of the base system that they can have.  Here, small packages are an 
advantage.  It will take a little while for ports to learn enough about the 
granularity of the base system for this to really be useful, but it would be 
great to be able to install nginx, for example, in a jail and have only the 
handful of libraries that it needs.

The big advantage of going with small packages initially, however, is that it 
will allow us to get some data on what the correct groupings are.  If we have 
large packages, then it’s very hard to tell which subsets of the packages 
people want.  That’s exactly the situation that we’re in now: we know some 
people don’t want docs or games, but that’s about all that we know.  It’s easy 
to move to a model where we have *fewer* packages in the future, but it’s 
harder to split them.  That also applies to dependencies.  If I know that a 
port depends on the shell, then it’s easy to update it from depending on a sh 
package to depending on a core system utilities package automatically, but it’s 
very hard to do an automatic update in the other direction.

David

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

Re: [CFT] packaging the base system with pkg(8)

[Julian Elischer]

On 19/04/2016 5:29 AM, Alfred Perlstein wrote:
Guys please stop arguing about the number of packages.  The high 
granularity is VERY useful!



it's going to make us a laughing stock
"look FreeBSD just split into 1.43 million packages" (effectively the 
same number.. it's bigger than 10)



Managing large groups of small packages is much easier than just 
having large packages.
err, Alfred, what planet do you live on? when they get out of sync it 
becomes a nightmare.
If you also had a packaging system that was smart enough to manage a 
hierarchy of packages then "maybe"..




All this can be done by meta-packages which depend on larger package 
groups.
Currently Metapackage is a way to make 10 packages look like 11 
packages.  The framework needs to understand to hide the 10 internal 
packages if they are part of a metapackage.


Later pkg can be augmented to "remove packages not explicitly 
installed" which would remove leaf packages.


Example: you installed "base-debug" which pulls in let's say 50 
small packages, later you want all of those removed, you can do 
something like:  "pkg delete --leafs base-debug" which should delete 
"base-debug" and any dangling packages it pulled in not required by 
other pkgs.


Huge thanks to the team that implemented this!


I'm sure the work was large and will be useful in the future but we 
are not ready to have the system installed like this.
no-one wants to see 750 packages show up when you do an enquiry on a 
newly installed system.

I could live with:

base-utils11.1
 - ktrace  uninstalled
 - tcpdump uninstalled
 + dd  11.1.1   (CVE-123412 fix)



but not
{700 packages )
dd  11.1.1 dd with CVE fix
{29 more packages}
[tcpdump line is not present but you don't notice that]
{10 more packages}
[ktrace line would be here but you don't notice that either]
{15 more packages}


In other words, I have no objection to all the utilities coming in the form of 
little packages.
but I have a major objection if that fact is at all obvious to the end user,
and certainly if we need to wade through 750 packages to see what's going on.



thanks.
-Alfred

On 4/18/16 1:07 PM, Lev Serebryakov wrote:

On 18.04.2016 22:40, Glen Barber wrote:


This granularity allows easy removal of things that may not be wanted
(such as *-debug*, *-profile*, etc.) on systems with little 
storage.  On

one of my testing systems, I removed the tests packages and all debug
and profiling, and the number of base system packages is 383.
  IMHO, granularity like "all base debug", "all base profile" is 
enough
for this. Really, I hardly could imagine why I will need only 1 
debug or

profile package, say, for csh. On resource-constrained systems NanoBSD
is much better anyway (for example, my typical NanoBSD installation is
37MB base system, 12MB /boot and 10 packages), and on developer system
where you need profiled libraries it is Ok to install all of them and
don't think about 100 packages for them.

  Idea of "Roles" from old FreeBSD installers looks much better. 
Again,

here are some "contrib" software which have one-to-one replacements in
ports, like sendmail, ssh/sshd, ntpd, but split all other
FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static 
libraries.

Yes, lib32 on 64 bit system.

   It seems that it is ideological ("holy war") discussion more than
technical one...



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




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

Re: [CFT] packaging the base system with pkg(8)

[Miroslav Lachman]

Lyndon Nerenberg wrote on 04/19/2016 05:24:

On 2016-04-18 8:17 PM, Alfred Perlstein wrote:

Can someone on the "too many packages" campaign here explain to me how
having too fine a granularity stops you from making macro packages
containing packages?

Because honestly I can't see how having granularity hurts at all when if
someone wanted to make it less granular all they would have to do is
make some meta-packages.


Meta-packages doesn't hide anything (in list of packages and problems 
with dependencies)



It's the *I have to put it back together* part that's annoying.  I
didn't break something that has worked, forever.  It shouldn't be
incumbent on me to un-break someone else's work.


+1

And you made another good point in previous e-mail about reviewed 
research. I would really like to see some docs about this topic. I have 
a feeling that some work on FreeBSD is against average users / admins 
and is good only for vedors of specialized or embedded devices.


As many before - I am not against packaging base. It is good, but 10 - 
20 packages will be enough. 800+ is too far from my feeling of "this is 
good feature".
This seems like a nightmare to me. This was one of the reasons I don't 
like other OS distribuitions and I stayed with FreeBSD for more than 15 
years.


Miroslav Lachman
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Slawa Olhovchenkov]

On Mon, Apr 18, 2016 at 08:17:12PM -0700, Alfred Perlstein wrote:

> Maybe what the "too many packages" folks need to do is write some code 
> to hide that it's so many packages.
> 
> :)
> 
> I think the rule of two feet should be applied here.
> 
> What we have is people that have worked quite hard to bring us something 
> that we can easily work with, and on the other hand some folks that want 
> something they consider even better.  Personally I can't see how having 
> the system less granular is better, since having it MORE granular is 
> actually harder work.
> 
> Can someone on the "too many packages" campaign here explain to me how 
> having too fine a granularity stops you from making macro packages 
> containing packages?
> 
> Because honestly I can't see how having granularity hurts at all when if 
> someone wanted to make it less granular all they would have to do is 
> make some meta-packages.

Because this is imposible (or very hard) to implement.
After last update (realy update) I have partyaly updated system --
some packages updated, some -- not (I am expect all packages must be
updated). Imposible to combine 800 packages to less meta-package and
distinct improper partial update from proper.

And how I am can paste this list of packages?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Glen Barber]

On Tue, Apr 19, 2016 at 03:24:30PM +0800, Julian Elischer wrote:
> We've managed to keep this disease out of BSD since I started to do it in
> 1990. First we laughed/fumed at Sun's Solaris when they unbundled the
> compiler. then we fumed at xorg when hey took a useful package and made 190
> odd packages out of it. Please don't force this on us!
> 

What isn't clear about the *numerous* statements that no one is being
*forced* to use packaged base?

I will not reply to further emails on this thread until it's clear to me
that everyone has read the previous emails.

Glen




signature.asc
Description: PGP signature

Re: [CFT] packaging the base system with pkg(8)

[Julian Elischer]

On 19/04/2016 3:14 AM, Glen Barber wrote:

On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote:

On Apr 18, 2016, at 11:52 AM, Lev Serebryakov  wrote:

I understand, that maybe it is too late, but ARE YOU KIDDING?! 755
packages?! WHY?! What are reasons and goals to split base in such
enormous number of packages?

Just a guess, having done the same thing myself:  it means that updates can be
more targeted.


This is exactly the reason, which has been answered numerous times.
But I would have thought that to the logical mind, obviously the simle 
statement "755 packages" is the wrong answer..

more than 10 should be obviously wrong.
The only POSSIBLE thing that would make this an OK thing would be to 
follow that statement with "But to the external user it's really 4 
packages unless you elect to split one of them."


It would require that all 755 do *NOT show up* in the (standard) list 
of installed packages.
Maybe they could show up in some other special list if you asked for 
fine grained information.


We've managed to keep this disease out of BSD since I started to do it 
in 1990. First we laughed/fumed at Sun's Solaris when they unbundled 
the compiler. then we fumed at xorg when hey took a useful package and 
made 190 odd packages out of it. Please don't force this on us!



Glen



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

Re: [CFT] packaging the base system with pkg(8)

[Erik Cederstrand]

> Den 19. apr. 2016 kl. 03.24 skrev Lyndon Nerenberg :
> 
> There aren't enough seconds in the universe to test all the viable 
> combinations for one single release.

We don't even do that with the WITH_FOO/WITHOUT_FOO options now, so why should 
that be a criteria? You can use any combination of those build options today, 
sure, but if something breaks you're on your own (you're always on your own, 
for that matter, since this is open source).

Seriously, there arguments put forth here against packaged base are pretty 
embarrassing. If you don't like packaged base, don't use it. Build and install 
from SVN instead. If you're using freebsd-update today, you essentially have 
14.000 packages and a far less powerful CLI, so why is packaged base not a step 
in the right direction?

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