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

[Gleb Kurtsou]

On (19/04/2016 13:36), 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

It's close to the way I see the packaging issue..

Our use case may not be the most common one -- we sell software in 2U
form factor (hardware included) :) Once in a while one has to roll
updates for the base system as well as our firmware. Packages has never
been much of a help but rather another obstacle to deal with for me
personally and I bet for our support as well. The thing I care about
most is to have the same base system for all customers who have
installed updates. It's really hard to troubleshoot assuming that some
package updates might have failed for a customer. Distributing images
comes very handy in this situation.

Although packages are useful in development:
- Being able to install complete development environment into the base
  system (debug symbols, compilers).
- Installing updates on *dev* machines. Which I'd rather avoid for
  release builds. By having packages for both release and dev one would
  need to have release and dev package repositories.  Much like
  stable/unstable repositories in many linux distros. Revision control
  systems tend to be much better at this at much lower cost.  Being able
  to do 'make happyworld whatever' out of the box on dev machine as well
  as installing packages built by CI is huge improvement comparing to
  packaging as it's often done in linux.
- Keeping any package metadata up to date in dev is painful (version
  bump in most cases).

How do we intend to do base system package versioning? Is it going to be
the same version for all packages or do we intend to bump versions in
individual Makefiles? Sorry if it has been discussed already, I must
have missed it.

IMHO >700 hardly makes any sense. I see no point in having individual
package for each binary under /bin and .so. I'd rather tweak a couple
Makefiles to remove stuff I don't need. WITH_* options in src.conf could
be a great list of packages to start with. Having -doc and -include in
separate packages would be appreciated as well.
___
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 Wed, Apr 20, 2016 at 08:16:36AM -0500, Andrew Berg wrote:

> Also, how much response do you expect in ~17 hours? Developers need time to 
> sleep, do their day jobs, and formulate a detailed response to a detailed 
> email.

OK, week later -- no any ("interesting", "not interesting", "know
issuses", "planed to fix", "expected behavior") response.
___
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: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))

[Warner Losh]

On Sun, Apr 24, 2016 at 12:14 PM, Daniel Eischen 
wrote:

> On Sun, 24 Apr 2016, Warner Losh wrote:
>
> On Sun, Apr 24, 2016 at 6:34 AM, Daniel Eischen 
>> wrote:
>>
>> On Sat, 23 Apr 2016, Warner Losh wrote:
>>>
>>> On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen 
>>>
 wrote:

 [CC trimmed]

>
> On Fri, 22 Apr 2016, Warner Losh wrote:
>
>
> I personally will be refraining from engaging further. I plan on seeing
>> what gaps there are by adding support to NanoBSD for packages. I'll be
>> busy
>> with that. In talking to Glen and others, we've already identified a
>> few
>> easy gaps to fill. Once they've done that, I'll get going on NanoBSD
>> with
>> the goal to be able to use it to build a bootable system of any
>> architecture from packages with no root privs. I expect to find
>> issues,
>> but
>> I don't expect to find any issue that's intractable. I expect after
>> the
>> issues are resolved, the end product will be better for everybody.
>>
>>
>> Thank you for working on NanoBSD.  Do you think it would be possible
> to add support for optionally building dump(8) images instead of dd?
>
>

 What do you  mean by that, exactly? It would be relatively easy to add
 a step that runs dump on the _.disk.image file and squirrel that away.
 Last orders the code currently calls it, I believe. Is it something as
 simple
 as this, or is there some more complexity that I'm failing to understand
 or grasp?


>>> Perhaps I'm missing something, but when last_orders() is called,
>>> isn't the disk already unmounted and 'mdconfig -d -u' already
>>> run?
>>>
>>
>>
>> dump 0f - _.disk.image > ~/foo.dump
>>
>> worked for me just now. Is there some reason that it wouldn't work for
>> you in last orders if you tossed a NANO_DISKIMGDIR in front of it
>> and last orders would work for you. You could even pipe it into some
>> compression program...
>>
>
> Huh, I didn't know you could do that on the image file.
> I feel dumb, now ;-)


Don't feel too dumb. If I specify foo.dump as the filename, dump kinda loses
its mind when it gets to the end of file. Not sure why.

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)

[Glen Barber]

On Mon, Apr 25, 2016 at 10:40:24AM +0800, Alastair Hogge wrote:
> Will /usr/src/release/release.sh eventually support building base packages
> as an option?

Yes.

Glen



signature.asc
Description: PGP signature

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

[Alastair Hogge]

Dear FreeBSD community,

Thanks so much for this awesome effort.

Will /usr/src/release/release.sh eventually support building base packages
as an option? If possible, is it something that we could see soon?

Ta,
Alastair
 --
Why isn't there a special name for the tops of your feet?
-- Lily Tomlin
___
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: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))

[Daniel Eischen]

On Sun, 24 Apr 2016, Warner Losh wrote:


On Sun, Apr 24, 2016 at 6:34 AM, Daniel Eischen 
wrote:


On Sat, 23 Apr 2016, Warner Losh wrote:

On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen 

wrote:

[CC trimmed]


On Fri, 22 Apr 2016, Warner Losh wrote:



I personally will be refraining from engaging further. I plan on seeing
what gaps there are by adding support to NanoBSD for packages. I'll be
busy
with that. In talking to Glen and others, we've already identified a few
easy gaps to fill. Once they've done that, I'll get going on NanoBSD
with
the goal to be able to use it to build a bootable system of any
architecture from packages with no root privs. I expect to find issues,
but
I don't expect to find any issue that's intractable. I expect after the
issues are resolved, the end product will be better for everybody.



Thank you for working on NanoBSD.  Do you think it would be possible
to add support for optionally building dump(8) images instead of dd?




What do you  mean by that, exactly? It would be relatively easy to add
a step that runs dump on the _.disk.image file and squirrel that away.
Last orders the code currently calls it, I believe. Is it something as
simple
as this, or is there some more complexity that I'm failing to understand
or grasp?



Perhaps I'm missing something, but when last_orders() is called,
isn't the disk already unmounted and 'mdconfig -d -u' already
run?



dump 0f - _.disk.image > ~/foo.dump

worked for me just now. Is there some reason that it wouldn't work for
you in last orders if you tossed a NANO_DISKIMGDIR in front of it
and last orders would work for you. You could even pipe it into some
compression program...


Huh, I didn't know you could do that on the image file.
I feel dumb, now ;-)

--
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: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))

[Warner Losh]

On Sun, Apr 24, 2016 at 6:34 AM, Daniel Eischen 
wrote:

> On Sat, 23 Apr 2016, Warner Losh wrote:
>
> On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen 
>> wrote:
>>
>> [CC trimmed]
>>>
>>> On Fri, 22 Apr 2016, Warner Losh wrote:
>>>
>>>
 I personally will be refraining from engaging further. I plan on seeing
 what gaps there are by adding support to NanoBSD for packages. I'll be
 busy
 with that. In talking to Glen and others, we've already identified a few
 easy gaps to fill. Once they've done that, I'll get going on NanoBSD
 with
 the goal to be able to use it to build a bootable system of any
 architecture from packages with no root privs. I expect to find issues,
 but
 I don't expect to find any issue that's intractable. I expect after the
 issues are resolved, the end product will be better for everybody.


>>> Thank you for working on NanoBSD.  Do you think it would be possible
>>> to add support for optionally building dump(8) images instead of dd?
>>>
>>
>>
>> What do you  mean by that, exactly? It would be relatively easy to add
>> a step that runs dump on the _.disk.image file and squirrel that away.
>> Last orders the code currently calls it, I believe. Is it something as
>> simple
>> as this, or is there some more complexity that I'm failing to understand
>> or grasp?
>>
>
> Perhaps I'm missing something, but when last_orders() is called,
> isn't the disk already unmounted and 'mdconfig -d -u' already
> run?


dump 0f - _.disk.image > ~/foo.dump

worked for me just now. Is there some reason that it wouldn't work for
you in last orders if you tossed a NANO_DISKIMGDIR in front of it
and last orders would work for you. You could even pipe it into some
compression program...

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: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))

[NGie Cooper]

> On Apr 24, 2016, at 05:34, Daniel Eischen  wrote:
> 
>> On Sat, 23 Apr 2016, Warner Losh wrote:
>> 
>> On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen 
>> wrote:
>> 
>>> [CC trimmed]
>>> 
 On Fri, 22 Apr 2016, Warner Losh wrote:
 
 
 I personally will be refraining from engaging further. I plan on seeing
 what gaps there are by adding support to NanoBSD for packages. I'll be
 busy
 with that. In talking to Glen and others, we've already identified a few
 easy gaps to fill. Once they've done that, I'll get going on NanoBSD with
 the goal to be able to use it to build a bootable system of any
 architecture from packages with no root privs. I expect to find issues,
 but
 I don't expect to find any issue that's intractable. I expect after the
 issues are resolved, the end product will be better for everybody.
>>> 
>>> Thank you for working on NanoBSD.  Do you think it would be possible
>>> to add support for optionally building dump(8) images instead of dd?
>> 
>> 
>> What do you  mean by that, exactly? It would be relatively easy to add
>> a step that runs dump on the _.disk.image file and squirrel that away.
>> Last orders the code currently calls it, I believe. Is it something as
>> simple
>> as this, or is there some more complexity that I'm failing to understand
>> or grasp?
> 
> Perhaps I'm missing something, but when last_orders() is called,
> isn't the disk already unmounted and 'mdconfig -d -u' already
> run?

Yup.

> -- 
> 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"
___
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: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))

[Daniel Eischen]

On Sat, 23 Apr 2016, Warner Losh wrote:


On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen 
wrote:


[CC trimmed]

On Fri, 22 Apr 2016, Warner Losh wrote:



I personally will be refraining from engaging further. I plan on seeing
what gaps there are by adding support to NanoBSD for packages. I'll be
busy
with that. In talking to Glen and others, we've already identified a few
easy gaps to fill. Once they've done that, I'll get going on NanoBSD with
the goal to be able to use it to build a bootable system of any
architecture from packages with no root privs. I expect to find issues,
but
I don't expect to find any issue that's intractable. I expect after the
issues are resolved, the end product will be better for everybody.



Thank you for working on NanoBSD.  Do you think it would be possible
to add support for optionally building dump(8) images instead of dd?



What do you  mean by that, exactly? It would be relatively easy to add
a step that runs dump on the _.disk.image file and squirrel that away.
Last orders the code currently calls it, I believe. Is it something as
simple
as this, or is there some more complexity that I'm failing to understand
or grasp?


Perhaps I'm missing something, but when last_orders() is called,
isn't the disk already unmounted and 'mdconfig -d -u' already
run?

--
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)

[dan_partelly]

This was all it was asked. Thanks.

> Im saying that feedback has been heard and understood and providing more
> now while things are in flux to try to address those issues is not
likely
> to be fruitful.
> Warner
> 
> Links:
> --
> [1] mailto:dan_parte...@rdsor.ro
___
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: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))

[Warner Losh]

On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen 
wrote:

> [CC trimmed]
>
> On Fri, 22 Apr 2016, Warner Losh wrote:
>
>>
>> I personally will be refraining from engaging further. I plan on seeing
>> what gaps there are by adding support to NanoBSD for packages. I'll be
>> busy
>> with that. In talking to Glen and others, we've already identified a few
>> easy gaps to fill. Once they've done that, I'll get going on NanoBSD with
>> the goal to be able to use it to build a bootable system of any
>> architecture from packages with no root privs. I expect to find issues,
>> but
>> I don't expect to find any issue that's intractable. I expect after the
>> issues are resolved, the end product will be better for everybody.
>>
>
> Thank you for working on NanoBSD.  Do you think it would be possible
> to add support for optionally building dump(8) images instead of dd?


What do you  mean by that, exactly? It would be relatively easy to add
a step that runs dump on the _.disk.image file and squirrel that away.
Last orders the code currently calls it, I believe. Is it something as
simple
as this, or is there some more complexity that I'm failing to understand
or grasp?

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)

[Warner Losh]

On Sat, Apr 23, 2016 at 12:27 AM, Dan Partelly 
wrote:

> You says that everything will be OK. I want to  believe you. But giving
> the track record  VIMAGE has, and how many gugs go on and on with years  Im
> not so sure that you guys wont do the same with this subsystem,  and leave
> it with rough edges for half a decade.  Because we all know that everything
> will be OK in the end. Timeframe is also important.


I can't help you with your trust issues.

I'm saying that feedback has been heard and understood and providing more
now while things are in flux to try to address those issues is not likely
to be fruitful.

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)

[Roger Marquis]

To clarify this proposal a bit better, there are only two flags I think
should be added to pkg to accommodate the usability issues introduced by
base packages and to do so without breaking existing scripts and
aliases:

 -b) only display base packages

 -B) display both base and third party packages

 neither -b nor -B) do not display base packages

The implementation could be as simple as a regex or as extensive as
adding a new field to the database.

That aside there's still the issues of versioning and dependencies.

Haven't seen many versioning recommendations but given existing
implementations (Solaris') have been carefully researched and tested
they should be safe and painless to reuse in pkgng.

Dependency checking and tracking will likely to be the most
time-consuming delta but, IMO and ldd aside, this can be left until
11.1.  For 11.0 it should be sufficient to issue a warning to the effect
"'pkg remove [anything in base]' is not currently supported and may
break parts of the system", at least for those packages which are not
already known by their equavilent 'OPTIONS_UNSET' and 'WITHOUT' build
params.

IMO,
Roger



Personally I think the behavior of pkg should remain as it now to avoid
breaking existing scripts and aliases i.e., base packages would not be
shown without specifying a new flag, say '-b'.  This base flag could
similarly display only base packages and also recognize the leaf
concept.  Presumably there should also be a flag to display both third
party and base packages, especially with the audit flag, but that could
be implemented at a future date without significantly reducing the
utility of base packages in 11-RELEASE.

___
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"

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

[Daniel Eischen]

[CC trimmed]

On Fri, 22 Apr 2016, Warner Losh wrote:


I personally will be refraining from engaging further. I plan on seeing
what gaps there are by adding support to NanoBSD for packages. I'll be busy
with that. In talking to Glen and others, we've already identified a few
easy gaps to fill. Once they've done that, I'll get going on NanoBSD with
the goal to be able to use it to build a bootable system of any
architecture from packages with no root privs. I expect to find issues, but
I don't expect to find any issue that's intractable. I expect after the
issues are resolved, the end product will be better for everybody.


Thank you for working on NanoBSD.  Do you think it would be possible
to add support for optionally building dump(8) images instead of dd?

--
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)

[Baho Utot]

Sorry for hijacking this thread but where can one find the code for 
11-CURRENT that handles the packaging of base?


I would like to have a look at it so I can form my opinion on packaging 
base.


I  moved to FreeBSD from LinuxFromScratch, ( I packaged that with the 
RPM package manager and it is on Github).

___
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]

>> 
> 
> *THAT* is the tone I was complaining about. This is not at all respectful.
> 



Respect is a two way street. If you want respect, offer yours.  We make our 
point  very  poorly, I get you, but it is the result of  what you and others 
from the projectdo. Meaning, 0 communication. I dont know if that  means 0 
communications skills,or you do not communicate on purpose. You as a member  of 
the core team, should be one of the first to address this problem. 

After all you the core invested time in code of conducts and other things of  
questionable value, but at the same time you always avoid to clearly 
communicate  with your user base.

> 've met personally with Glen, in person. I had a wonderful chat with him.

Maybe you did. We did not. Serious mechanism issues regarding pkg went  
unanswered on the other list. Look on pkg list, very rational, polite, and to  
the subject, 100% rational message about pkg base which is not responded. So, 
you complain about tone, and how helpful  would  be for ppl to change it. Let 
me give you a suggestion: start with altering your own behaviour. Offer  
respect, be communicative, less sensible on internet where it is very hard to 
convey “tone”. You'll see that it works wonders to indirectly alter the  
behaviour of the people you so eloquently compared to peasants daring to 
disturb the lord of the castle.



You says that everything will be OK. I want to  believe you. But giving the 
track record  VIMAGE has, and how many gugs go on and on with years  Im not so 
sure that you guys wont do the same with this subsystem,  and leave it with 
rough edges for half a decade.  Because we all know that everything will be OK 
in the end. Timeframe is also important.




> 
> 
>> And I really think THAT is the crux of the argument everyone is trying to
>> make.
>> 
>> To reiterate: packages are good.  In moderation.  As with all other
>> things.  But they have to solve the general case, and pkg - both the tool
>> and the methodology in its current and pending incarnations - does not.
>> 
>> I, and others, are trying to have a real conversation about this.  But the
>> blowback is incredible.  Let alone incredulous.
> 
> 
> That is understood. Being toxic about it isn't going to help. Being
> disrespectful is not going to help. Being hyperbolic isn't going to help.
> It isn't a real conversation until that stuff is gone. So far I've seen no
> evidence of it being gone.
> 
> I've met personally with Glen, in person. I had a wonderful chat with him.
> Based on talking to him, it was clear many of the complaints here were
> overblown. Are there rough edges? Yes. Are there things we don't know? Yes.
> Is it the end of the world? No. Over the coming weeks, things will get
> easier. The rough edges will be sanded off. After talking with him, I have
> complete confidence in him and others that are working on making this
> happen. I don't need it to be perfect today, because of this confidence.
> 
> I personally will be refraining from engaging further. I plan on seeing
> what gaps there are by adding support to NanoBSD for packages. I'll be busy
> with that. In talking to Glen and others, we've already identified a few
> easy gaps to fill. Once they've done that, I'll get going on NanoBSD with
> the goal to be able to use it to build a bootable system of any
> architecture from packages with no root privs. I expect to find issues, but
> I don't expect to find any issue that's intractable. I expect after the
> issues are resolved, the end product will be better for everybody.
> 
> 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"

___
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!

> This works fine (after a source rebuild of pkg), but for tools like 
> portupgrade (from ports), which use pkg under the hood to handle 
> dependency checks.  pkg against the ports tree vs. pkg against my 
> LOCALBASE=/usr/pkg were conflicting.  So I asked some questions about how 
> to resolve this.
>  The response was bizarre.  Wanting to use pkg with a 
> different directory seemed almost offensive to the people who answered. 

It was probably the result of estimating the amount of work
necessary to implement this.

> There was no thought of even considering the use case.  I ended up filing 
> a bugzilla report, but I see that got close with 'works as intended' a 
> couple of days ago.

As usual, if someone complains about some PR being handled
ungraceful, would you please, in the name of reason, name
the PR, so that others can check the details without
searching the open PR pool for it ?

> I can't see how pkg as a base package manager would allow me 
> to continue with my ports->/usr/pkg mapping.

If you analyse the code and fix the places where it needs to
be adapted, it would probably work.

> I really think the biggest problem people have at the moment is the 
> complete and utter lack of respect core and the pkg crew have for the end 
> users of the system.

Does it help if I explain to you that there is almost no-one there
that can listen to your complaints ? Literally ? There are
only a small handful of people that work on core or pkg crew, and
they work on so many things that they only skim the lists,
because of lack of time ? pkg-crew might be 1-2 folks that
try to cope with the flood of requests and try to triage
according to "can be solved in less time than...".

It has nothing to do with lack of respect.

> I'm pretty sure we all get WHY this work is being 
> done.  We don't all AGREE with why it's being done.  And that is the 
> conversation we are trying to have.  But every time we try to have it, we 
> get slammed down as a bunch of ungrateful whining non-coders.

Sending this email costs me 10mins or so. Committing 1-2 port updates
takes the same amount of time. So, what is my choice ?

> Lots of people wrote a lot of lines of code for Linux.  Is the argument 
> that we should just adopt that?  Because it's written, it must be good?

No, that's not the argument the other side is making. They
work as much as possible, but there are too few people to work
on it.

> You guys need to get over that and come back to the table to have a 
> rational discussion with the vast majority of people who actually USE this 
> OS.

Suggesting that their behaviour is not rational does not help 8-)

> All glory to Juniper and Citrix and everyone else who packages the OS 
> into their various 'appliances'.  I use both of the above at work, and 
> believe me, for the amount of money they take out of my pocket, they can 
> hire their own release engineers to deal with this internally without 
> inflicting this on everyone else.

Not even they can do that 8-) If I look at the issues citrix
has to solve, they probably are spread thin 8-} If I look
at the messages a juniper EX switch sends during an upgrade,
some of which look strange, their engineering dept. is probably
at some limit, too.

> To reiterate: packages are good.  In moderation.  As with all other 
> things.  But they have to solve the general case, and pkg - both the tool 
> and the methodology in its current and pending incarnations - does not.

>From what I learn, pkg in its current form solves *a lot* of problems,
and yes, not 100% of all problems. So let's work on the other
ones step by step.

> I, and others, are trying to have a real conversation about this.  But the 
> blowback is incredible.  Let alone incredulous.

Thanks for that attempt. We need to find resources (time, skill,
code) to have this conversation, and right now, all of that is
in very short supply.

-- 
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)

[Warner Losh]

On Fri, Apr 22, 2016 at 8:41 PM, Lyndon Nerenberg  wrote:

> You guys need to get over that and come back to the table to have a
> rational discussion with the vast majority of people who actually USE this
> OS.  All glory to Juniper and Citrix and everyone else who packages the OS
> into their various 'appliances'.  I use both of the above at work, and
> believe me, for the amount of money they take out of my pocket, they can
> hire their own release engineers to deal with this internally without
> inflicting this on everyone else.
>

*THAT* is the tone I was complaining about. This is not at all respectful.
How can we have a rational discussion with people talking about "all glory
to" this or that? I don't think it is possible. I get the point you are
trying to make, but it is being made so poorly that I have to point that
out. You don't get people to come to a table by being disrespectful and
demanding their presence. I sit at whatever table I choose to sit at. You
have to convince me to sit, not demand that I sit. I haven't responded well
to that since the 70's, and I'm ill inclined to start now. Yelling and
screaming isn't going to do it. Jumping up and down isn't going to do it.
Nobody wants to chat with the mob carrying pitch forks and torches. People
do want to talk to rational people having rational discussions perhaps with
a point of view that differs from their own. You can scream all you want,
but I doubt it will get the results you want.


> And I really think THAT is the crux of the argument everyone is trying to
> make.
>
> To reiterate: packages are good.  In moderation.  As with all other
> things.  But they have to solve the general case, and pkg - both the tool
> and the methodology in its current and pending incarnations - does not.
>
> I, and others, are trying to have a real conversation about this.  But the
> blowback is incredible.  Let alone incredulous.


That is understood. Being toxic about it isn't going to help. Being
disrespectful is not going to help. Being hyperbolic isn't going to help.
It isn't a real conversation until that stuff is gone. So far I've seen no
evidence of it being gone.

I've met personally with Glen, in person. I had a wonderful chat with him.
Based on talking to him, it was clear many of the complaints here were
overblown. Are there rough edges? Yes. Are there things we don't know? Yes.
Is it the end of the world? No. Over the coming weeks, things will get
easier. The rough edges will be sanded off. After talking with him, I have
complete confidence in him and others that are working on making this
happen. I don't need it to be perfect today, because of this confidence.

I personally will be refraining from engaging further. I plan on seeing
what gaps there are by adding support to NanoBSD for packages. I'll be busy
with that. In talking to Glen and others, we've already identified a few
easy gaps to fill. Once they've done that, I'll get going on NanoBSD with
the goal to be able to use it to build a bootable system of any
architecture from packages with no root privs. I expect to find issues, but
I don't expect to find any issue that's intractable. I expect after the
issues are resolved, the end product will be better for everybody.

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)

[Lyndon Nerenberg]

On Tue, 19 Apr 2016, Warner Losh 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 agree. Really, I do!  But this must work both ways, and I can say 
unequivocally that my earlier interactions with the 'pkg' people have been 
unpleasant.  Some time ago I asked about how pkg interacts with 
LOCALBASE!=/usr/local.  This because I like to build ports from 
/usr/ports, but install them under /usr/pkg so as to keep /usr/local free 
for truly local code.


This works fine (after a source rebuild of pkg), but for tools like 
portupgrade (from ports), which use pkg under the hood to handle 
dependency checks.  pkg against the ports tree vs. pkg against my 
LOCALBASE=/usr/pkg were conflicting.  So I asked some questions about how 
to resolve this.  The response was bizarre.  Wanting to use pkg with a 
different directory seemed almost offensive to the peoploe who answered. 
There was no thought of even considering the use case.  I ended up filing 
a bugzilla report, but I see that got close with 'works as intended' a 
couple of days ago.


I can't see how pkg as a base package manager would allow me 
to continue with my ports->/usr/pkg mapping.


I really think the biggest problem people have at the moment is the 
complete and utter lack of respect core and the pkg crew have for the end 
users of the system.  I'm pretty sure we all get WHY this work is being 
done.  We don't all AGREE with why it's being done.  And that is the 
conversation we are trying to have.  But every time we try to have it, we 
get slammed down as a bunch of ungrateful whining non-coders.


Lots of people wrote a lot of lines of code for Linux.  Is the argument 
that we should just adopt that?  Because it's written, it must be good?


You guys need to get over that and come back to the table to have a 
rational discussion with the vast majority of people who actually USE this 
OS.  All glory to Juniper and Citrix and everyone else who packages the OS 
into their various 'appliances'.  I use both of the above at work, and 
believe me, for the amount of money they take out of my pocket, they can 
hire their own release engineers to deal with this internally without 
inflicting this on everyone else.


And I really think THAT is the crux of the argument everyone is trying to 
make.


To reiterate: packages are good.  In moderation.  As with all other 
things.  But they have to solve the general case, and pkg - both the tool 
and the methodology in its current and pending incarnations - does not.


I, and others, are trying to have a real conversation about this.  But the 
blowback is incredible.  Let alone incredulous.


--lyndon

___
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)

[Lyndon Nerenberg]

On Tue, 19 Apr 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.


True enough.  But I am also wary of decending into what became of X, where 
a build of the xorg metapackage spends 80% of its time running configure, 
over and over and over again.  How long until a source build becomes a 
series of 'rpmbuild ...' equivalents?  Sadly, if this level of fine 
grained packaging infects the base, it *will* only be a matter of time ...


So no matter what the good intentions, this is going to impact everyone, 
like it or not.


--lyndon

___
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!

dan wrote:
> Another small issue, is in general the politics of the FreeBSD dev team
> regarding bug fixes. I personally would be glad to see more commitment from
> the dev team regarding bug fixes.

>From what I can see, there's not much politics, but serious work
overload, and not much room for more commitment.

-- 
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)

[Ernie Luzar]

As long as packaged base is not mandatory, it is fine by me.



+1  on that



___
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]

Julian Elischer wrote:

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.


I like this suggestion both as it applies to base and third party
packages and agree that the 'leaf' keyword, once documented, will
address the use case fairly well.


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.


Personally I think the behavior of pkg should remain as it now to avoid
breaking existing scripts and aliases i.e., base packages would not be
shown without specifying a new flag, say '-b'.  This base flag could
similarly display only base packages and also recognize the leaf
concept.  Presumably there should also be a flag to display both third
party and base packages, especially with the audit flag, but that could
be implemented at a future date without significantly reducing the
utility of base packages in 11-RELEASE.

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)

[dan_partelly]

It's lack of communication.

> *This* is the reason that *this* and similar topics become so heated;

> People who are part of a "community", such as FreeBSD. Want to feel
> they are part of the "big picture", and immediately feel resentment,

It is in fact much more than that. Surely there are  such psycho-social
effects as you describe, after all we humans are subject to hundred os
socio-psycological biases. But there is a much more practical and mundane
issue as well:
People who use this operating system in their operations have a great
stake in it. Such changes affect operations. I welcome change, but at the
same time I try to ensure that change goes smoothly. Investing in BSDs by
using them
in our operation is not a whim, or a decision made drunk under a bridge.
It costs us money, time , investment in educating other people to
administer those OSEs, continuous education  to keep up with change. More
than all this, it
costs us business reputation when we decide to build an infrastructure for
a client on BSDs, and something goes wrong. And I want to keep my customers
happy and so far the BSDs delivered this. 

> when they find they were left out of "big" decisions, like pkg(8).

IMO, Its not a problem to be left out of decisions. First, because they
are not our decisions to take, and second because I believe decisions are
better to be made by small group of persons.  What is a problem is the fact
that when you 
discuss those projects and voice your opinions, some label you "anti
progress", some " peasant storming a (lord's) castle (with or without a
pitchfork,cant remember :P) , others feel that you dont appreciate them and
their time, and then they retreat somewhere. You can invalidate the
decision made by said group by stoping using the product. Im sure none
would care in the unlikely even that I would  stop using FreeBSD, but I
think they cared when Yahoo stopped using it. Or if they did not, they 
should have cared :P



> People who are part of a "community", such as FreeBSD. Want to feel
> they are part of the "big picture", and immediately feel resentment,
> when they find they were left out of "big" decisions, like pkg(8).
> While the conversation may well have been heated. It would *not*
> have meet *quite* as much adamant, persistent resistance. Because
> it (pkg) would have been molded into something from the culmination
> of the "community'" input.
> 
> This is only from 50 years in the service industry, and the
> thousands of mailing lists I've been on, talking here.
> 
> --Chris
> 
>> 
>> -- 
>> 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"
___
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)

[Chris H]

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.
Ahem... *always*? ;-)
While I *do* have some opinions on the upcoming pkg-base, as well as the
pkg system, itself. I'm playing catch-up with my INBOX. So I will only
respond to your remark;
I don't ever recall having been asked whether a package system should
be implemented, and if so, how it should look. *Prior* to it's having
been implemented. Tho it may have come up in the IRC channels. It never
reached the mailing lists.
*This* is the reason that *this* and similar topics become so heated;
People who are part of a "community", such as FreeBSD. Want to feel
they are part of the "big picture", and immediately feel resentment,
when they find they were left out of "big" decisions, like pkg(8).
While the conversation may well have been heated. It would *not*
have meet *quite* as much adamant, persistent resistance. Because
it (pkg) would have been molded into something from the culmination
of the "community'" input.

This is only from 50 years in the service industry, and the
thousands of mailing lists I've been on, talking here.

--Chris

> 
> -- 
> 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)

[dan_partelly]

> 
> Not taking a side on this discussion, yet… but the first thing that

I do not believe there are sides to take, because I am absolutely positive
everybody in this thread wants only whats better for FreeBSD, so there is
only one side. It is an aspect which in the heat of emotions some people
seem to forget.

>> The benefits might be worth it in the long run.

The benefits are great and they are immediately available upon release of
a packaged base. I am all for it . Yet there issue, such as the UI which
doesn't handle well big numbers of packages, mechanism issues and
convention issues which where raised in another thread and went unanswered
by devs so far. 

Personally my greatest fear is that what happen to VIMAGE wouldn't happen
with this great feature. Namely, that it goes in effect with a "good
enough" implementation (which may well be a great success for some uses)
and then we have to work with the "good enough" implementation for half a
decade before it is made bullet proof and orthogonal. Or that UI issues are
never solved, claiming that they are "largely cosmetic" anyway. I wouldn't
mind waiting 2 point releases for example
to become that way, but look, for VIMAGE takes what ... 6 years ? 

(Nota bene: I do not contest that VIMAGE is great. )

Pople raised valid concerns, devs imvolved in the project seen them, yet
those who spearhead the base pkg project did not found appropriate to make
a statement to quell ppl fears regarding their commitment to see to all the
issues in a pre-determined time frame. I.E a commitment to make it bullet
proof by 11.1 as example. Some felt threatened and unappreciated, which is
a problem. Both for them and for us, the user. Because the users of this OS
are not only the companies who employ the developers, there are thousand of
people scattered through the world, ppl who have a great stake invested in
this operating system, by the simple fact that they use it everywhere. 

Another small issue, is in general the politics of the FreeBSD dev team
regarding bug fixes. I personally would be glad to see more commitment from
the dev team regarding bug fixes. It is kinda disappointing to see known
bugs 
going on and on for years, "good enough" susbsytems having the same fate,
and so on. 

I beleive the team per-ansamble should make a more solid commitment to fix
outstanding issues, and try to outline a policy regarding bugs and
implementations which lack orthogonality or are only partially completed
(even if this partially means 95% ).

 

> occurred to me is that such way of packaging is traditional for the
Linux
> “distributions”. I could imagine people worrying at subconscious level
that
> FreeBSD is going the Linux way… and that if they wanted such a model,
they
> would be using Linux instead. Today, people have more choice in
packaging —
> but if FreeBSD goes the Linux way, someone else will fill the void — so
no
> worries in general.
> 
> I can see the support nightmare that a packaged base would bring, but as
> always — this is not enough to judge it. The benefits might be worth it
in
> the long run.
> 
> I was a long time user of BSD/OS and then switched to FreeBSD when that
OS
> was killed. In BSD/OS everything was monolithic. It was rock stable.
Very
> dependable and very easy to support. My first few years with FreeBSD
were
> spent to get used that the OS was not just one piece, but you could end
up
> with different installs.. A bit more support efforts. Not that I am
> complaining :)
> 
> As long as packaged base is not mandatory, it is fine by me.
> 
> Daniel
> ___
> 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)

[Daniel Kalchev]

> On 19.04.2016 г., at 5:01, Roger Marquis  wrote:
> 
> Honestly, some of us are wondering what exactly is
> behind some of these concerns regarding base packages.
> 

Not taking a side on this discussion, yet… but the first thing that occurred to 
me is that such way of packaging is traditional for the Linux “distributions”. 
I could imagine people worrying at subconscious level that FreeBSD is going the 
Linux way… and that if they wanted such a model, they would be using Linux 
instead. Today, people have more choice in packaging — but if FreeBSD goes the 
Linux way, someone else will fill the void — so no worries in general.

I can see the support nightmare that a packaged base would bring, but as always 
— this is not enough to judge it. The benefits might be worth it in the long 
run.

I was a long time user of BSD/OS and then switched to FreeBSD when that OS was 
killed. In BSD/OS everything was monolithic. It was rock stable. Very 
dependable and very easy to support. My first few years with FreeBSD were spent 
to get used that the OS was not just one piece, but you could end up with 
different installs.. A bit more support efforts. Not that I am complaining :)

As long as packaged base is not mandatory, it is fine by me.

Daniel
___
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]

This is one of the issue I perceive with using scripts/ intermediate
programs 
as a  glue, a problem which does not exist when the daemons are integrated

tighter. You basically give up all the power which arises from
inter-operating 
daemons give to the system. 

It is also the main problem FreeBSD's rc system presents. Because all is a

scaffolding of shell scripts, it basically gives you 0 of the power modern

service management offer. Most important are service life cycle
management,
restart policies, delegated administration  and fault reporting. The only
thing 
you gain is easy  debugability (no small boon)but it is easily outweighted
by all 
other advantages of a modern service manager. 

> 
> Well, even if we went this route, this wouldn't quite work, because
> the automountd daemon actually doesn't need those notifications.
> It's the "-media" map that does.  Other parts of autofs don't have
> any special code for media handling.

About shell scripts in general as a glue:

Yes, they are easily debuggable and customized. Yet I believe that all
that 
power should be hidden,and it should be unnecessary to tap into it for 95%
of 
administrative needs.   It is my perception that less and less people are 
interested in exploring the countless ranges of customization such
scaffolding 
of scripts offer. People are interested in sane defaults, easy to specify
policies and fault reporting. Life is too short to explore myriad of 
customizations, unless you really have to. And most of the time, you dont
need 
to.

Thats not to say shell scripts dont have their place. They do. I use them 
too, both on  unixes and tcl scripts for adding fast functionality in
csico 
devices. But as a glue between essential operating system subsystems, it
is
my oppinion that we are 10 years too late in replacing them.


___
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)

[Edward Tomasz Napierała]

On 0422T0908, David Chisnall wrote:
> On 21 Apr 2016, at 21:48, Dan Partelly  wrote:
> > 
> > Yes, you are right it misses the media change handler  in devd.conf. 
> > maybe it should bementioned somewhere in a man page if it is not
> > already there. Thanks for the pointer.
> > 
> > Anyway, if I would have written the system, what I would have done
> > is to consolidate both user mode daemons into one and make this
> > daemon a client of devd, fstyp a library, and handle all removable 
> > media inside transparent to the user, without requiring any modifications
> > to devd.conf, and without relaying on shell scripts. 
> > 
> > Is there any reason you did not took this approach ? This is not
> > criticism, I am genuinely interested.
> 
> One of the current shortcomings of devd is that it does not provide a good 
> mechanism for other running processes to request notification of events 
> dynamically.  Ideally, when the automounter daemon starts, it should connect 
> to devd via an IPC channel and request notification of the specific events 
> that it wants.  This is a known problem (which extends to more than just the 
> automounter) and there are some tentative plans to fix it, but they’re not 
> yet concrete and won’t be in 11.0, though hopefully will appear at some point 
> in the 11.x series.

Well, even if we went this route, this wouldn't quite work, because
the automountd daemon actually doesn't need those notifications.
It's the "-media" map that does.  Other parts of autofs don't have
any special code for media handling.

___
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)

[Edward Tomasz Napierała]

On 0421T2348, Dan Partelly wrote:
> Yes, you are right it misses the media change handler  in devd.conf. 
> maybe it should bementioned somewhere in a man page if it is not
> already there. Thanks for the pointer.

It's mentioned in a comment in auto_master file.  But yeah, mentioning
it in a manual page seems like a good idea.

> Anyway, if I would have written the system, what I would have done
> is to consolidate both user mode daemons into one and make this
> daemon a client of devd, fstyp a library, and handle all removable 
> media inside transparent to the user, without requiring any modifications
>  to devd.conf, and without relaying on shell scripts. 
> 
> Is there any reason you did not took this approach ? This is not
> criticism, I am genuinely interested.

Yes - I actually like shell scripts.  I like being able to provide
the glue in a way that's easy to debug and modify, without having
to rebuild anything, so that it can be tailored to specific needs
by the system administrator.

In this case the problem, I think, is not with the shell scripting.
It's just that it doesn't "enable itself" when needed, or isn't
just enabled by default.

> >  and simply
> > retrofit the changes back to autofs - but that hasn't happened (yet).
> 
> Please consider doing it.  A kevent on /media would allow other programs
> to see how volumes come and go, and I can imagine several situations 
> where this can be handy. And too many directories left there do become
> annoying. 

Well, you have devd notifications for this - and it gives you much more
flexibility.

> > On 21 Apr 2016, at 23:20, Edward Tomasz Napierała  wrote:
> > 
> > On 0421T1526, Dan Partelly wrote:
> >> The scenario is:
> >> 
> >> Let’s say I have autofs_enable , working with media map.
> >> 
> >> If I have a CD in CD drive , all is well and when the system is fully 
> >> booted up
> >> /media contains a directory through which I can access the content of the 
> >> CD-ROM. Now if you eject this CD , and insert a new one, nothing happens.
> >> /media does not contain a new access point for the new disk inserted in 
> >> the 
> >> device.  
> >> 
> >> What I would expect is when I change the media in Cd-rom , a new 
> >> access point for the volume in question should be reated in /media.
> >> 
> >> Perhaps this functionality is exposed differently by the automounter,
> >> but them I would not expect the CDrom to be accessible at all though the 
> >> media map. 
> > 
> > If by "access point" you mean the directory, then it will, unless the CD
> > doesn't have a label - in that case the device name will be used instead,
> > and since it's the same device, it will be the same name - usually "cd0".
> > 
> > However - I've just checked to make sure and it works the way it should.
> > What you're decribing seems like you're missing the part of devd.conf(5)
> > responsible for notifying autofs about media change.  Do you?
> > 
> >>> he problem here is that it's quite hard to fix, there's a risk
> >>> of breaking existing functionality, and the problem is largely cosmetic.
> >> 
> >> until you have more than 10 of them there, when it largely annoying.
> >> anyway, what is the reason it is very hard to fix and it would break 
> >> existing
> >> functionality. can you please shed some light ?  
> > 
> > Basically, the autofs doesn't support removing the nodes.  It wasn't
> > really required for the usual use case, and it simplified the code a lot.
> > Plan was to pick it up again with my next filesystem project, and simply
> > retrofit the changes back to autofs - but that hasn't happened (yet).
> > 
> > [..]
> 
___
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)

[David Chisnall]

On 21 Apr 2016, at 21:48, Dan Partelly  wrote:
> 
> Yes, you are right it misses the media change handler  in devd.conf. 
> maybe it should bementioned somewhere in a man page if it is not
> already there. Thanks for the pointer.
> 
> Anyway, if I would have written the system, what I would have done
> is to consolidate both user mode daemons into one and make this
> daemon a client of devd, fstyp a library, and handle all removable 
> media inside transparent to the user, without requiring any modifications
> to devd.conf, and without relaying on shell scripts. 
> 
> Is there any reason you did not took this approach ? This is not
> criticism, I am genuinely interested.

One of the current shortcomings of devd is that it does not provide a good 
mechanism for other running processes to request notification of events 
dynamically.  Ideally, when the automounter daemon starts, it should connect to 
devd via an IPC channel and request notification of the specific events that it 
wants.  This is a known problem (which extends to more than just the 
automounter) and there are some tentative plans to fix it, but they’re not yet 
concrete and won’t be in 11.0, though hopefully will appear at some point in 
the 11.x series.

David



smime.p7s
Description: S/MIME cryptographic signature

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

[Dan Partelly]

Yes, you are right it misses the media change handler  in devd.conf. 
maybe it should bementioned somewhere in a man page if it is not
already there. Thanks for the pointer.

Anyway, if I would have written the system, what I would have done
is to consolidate both user mode daemons into one and make this
daemon a client of devd, fstyp a library, and handle all removable 
media inside transparent to the user, without requiring any modifications
 to devd.conf, and without relaying on shell scripts. 

Is there any reason you did not took this approach ? This is not
criticism, I am genuinely interested.

>  and simply
> retrofit the changes back to autofs - but that hasn't happened (yet).

Please consider doing it.  A kevent on /media would allow other programs
to see how volumes come and go, and I can imagine several situations 
where this can be handy. And too many directories left there do become
annoying. 

> On 21 Apr 2016, at 23:20, Edward Tomasz Napierała  wrote:
> 
> On 0421T1526, Dan Partelly wrote:
>> The scenario is:
>> 
>> Let’s say I have autofs_enable , working with media map.
>> 
>> If I have a CD in CD drive , all is well and when the system is fully booted 
>> up
>> /media contains a directory through which I can access the content of the 
>> CD-ROM. Now if you eject this CD , and insert a new one, nothing happens.
>> /media does not contain a new access point for the new disk inserted in the 
>> device.  
>> 
>> What I would expect is when I change the media in Cd-rom , a new 
>> access point for the volume in question should be reated in /media.
>> 
>> Perhaps this functionality is exposed differently by the automounter,
>> but them I would not expect the CDrom to be accessible at all though the 
>> media map. 
> 
> If by "access point" you mean the directory, then it will, unless the CD
> doesn't have a label - in that case the device name will be used instead,
> and since it's the same device, it will be the same name - usually "cd0".
> 
> However - I've just checked to make sure and it works the way it should.
> What you're decribing seems like you're missing the part of devd.conf(5)
> responsible for notifying autofs about media change.  Do you?
> 
>>> he problem here is that it's quite hard to fix, there's a risk
>>> of breaking existing functionality, and the problem is largely cosmetic.
>> 
>> until you have more than 10 of them there, when it largely annoying.
>> anyway, what is the reason it is very hard to fix and it would break existing
>> functionality. can you please shed some light ?  
> 
> Basically, the autofs doesn't support removing the nodes.  It wasn't
> really required for the usual use case, and it simplified the code a lot.
> Plan was to pick it up again with my next filesystem project, and simply
> retrofit the changes back to autofs - but that hasn't happened (yet).
> 
> [..]

___
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)

[Edward Tomasz Napierała]

On 0421T1526, Dan Partelly wrote:
> The scenario is:
> 
> Let’s say I have autofs_enable , working with media map.
> 
> If I have a CD in CD drive , all is well and when the system is fully booted 
> up
> /media contains a directory through which I can access the content of the 
> CD-ROM. Now if you eject this CD , and insert a new one, nothing happens.
> /media does not contain a new access point for the new disk inserted in the 
> device.  
> 
> What I would expect is when I change the media in Cd-rom , a new 
> access point for the volume in question should be reated in /media.
> 
> Perhaps this functionality is exposed differently by the automounter,
> but them I would not expect the CDrom to be accessible at all though the 
> media map. 

If by "access point" you mean the directory, then it will, unless the CD
doesn't have a label - in that case the device name will be used instead,
and since it's the same device, it will be the same name - usually "cd0".

However - I've just checked to make sure and it works the way it should.
What you're decribing seems like you're missing the part of devd.conf(5)
responsible for notifying autofs about media change.  Do you?

> > he problem here is that it's quite hard to fix, there's a risk
> > of breaking existing functionality, and the problem is largely cosmetic.
> 
> until you have more than 10 of them there, when it largely annoying.
> anyway, what is the reason it is very hard to fix and it would break existing
> functionality. can you please shed some light ?  

Basically, the autofs doesn't support removing the nodes.  It wasn't
really required for the usual use case, and it simplified the code a lot.
Plan was to pick it up again with my next filesystem project, and simply
retrofit the changes back to autofs - but that hasn't happened (yet).

[..]

___
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]

The scenario is:

Let’s say I have autofs_enable , working with media map.

If I have a CD in CD drive , all is well and when the system is fully booted up
/media contains a directory through which I can access the content of the 
CD-ROM. Now if you eject this CD , and insert a new one, nothing happens.
/media does not contain a new access point for the new disk inserted in the 
device.  

What I would expect is when I change the media in Cd-rom , a new 
access point for the volume in question should be reated in /media.

Perhaps this functionality is exposed differently by the automounter,
but them I would not expect the CDrom to be accessible at all though the 
media map. 
 

> he problem here is that it's quite hard to fix, there's a risk
> of breaking existing functionality, and the problem is largely cosmetic.

until you have more than 10 of them there, when it largely annoying.
anyway, what is the reason it is very hard to fix and it would break existing
functionality. can you please shed some light ?  



> Huh, never heard about that.  I'd expect the existing mechanism to handle
> that case just fine.  Could you submit a PR?

> On 21 Apr 2016, at 12:57, Edward Tomasz Napierała  wrote:
> 
> On 0420T1545, dan_partelly wrote:
> 
> [..]
> 
>> Another example is the autofs mounter. The prject was marked as complete
>> by FreeBSD foundation in 2014. Last I tried it to autmount removable
>> devices, it left directory after directory in the autofs managed directory.
>> This is known behavior.
> 
> Yup.  The problem here is that it's quite hard to fix, there's a risk
> of breaking existing functionality, and the problem is largely cosmetic.
> 
>> It also did not worked as it should ??? (show it
>> manage removable media correctly ) changing CD/DVD media disks. Presumably
>> In could have somehow manage it to work by making yet another scaffolding
>> of scripts as a questionable glue between devd and automounters.  That if
>> devd receives media change notifications. I dont know. If not I could patch
>> the kernel, yeah. But it is just much to simple to not bother at all and
>> use OSx. 
> 
> Huh, never heard about that.  I'd expect the existing mechanism to handle
> that case just fine.  Could you submit a PR?
> 
> [..]
> 
> ___
> 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)

[Edward Tomasz Napierała]

On 0420T1545, dan_partelly wrote:

[..]

> Another example is the autofs mounter. The prject was marked as complete
> by FreeBSD foundation in 2014. Last I tried it to autmount removable
> devices, it left directory after directory in the autofs managed directory.
> This is known behavior.

Yup.  The problem here is that it's quite hard to fix, there's a risk
of breaking existing functionality, and the problem is largely cosmetic.

> It also did not worked as it should ??? (show it
> manage removable media correctly ) changing CD/DVD media disks. Presumably
> In could have somehow manage it to work by making yet another scaffolding
> of scripts as a questionable glue between devd and automounters.  That if
> devd receives media change notifications. I dont know. If not I could patch
> the kernel, yeah. But it is just much to simple to not bother at all and
> use OSx. 

Huh, never heard about that.  I'd expect the existing mechanism to handle
that case just fine.  Could you submit a PR?

[..]

___
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 Wed, Apr 20, 2016 at 11:57:47AM -0400, Paul Mather wrote:

> On Apr 20, 2016, at 10:54 AM, Slawa Olhovchenkov  wrote:
> 
> >> A packaged base is just another way of describing the state of the
> >> system.  People on mailing lists will still be able to help people
> >> fix their problems, but they'll just use different information to
> >> pinpoint the precise components affected.
> > 
> > How identify this systems? By 800-line lists of package versions?
> 
> 
> In my experience, troubleshooting usually proceeds from the
> description of the symptoms.  So, if someone says, "I just updated
> and Sendmail has stopped sending e-mails," or "I just updated and I
> can no longer SSH into my system," then the logical question is to
> ask what versions of the packages they're running that pertain to
> those binaries.  In other words, you start at the symptom and work
> outwards from there.  In my experience, it's not necessary to have
> an exact inventory of a system to be able to solve a problem with
> it.

I see you point. Now try this, for some example, semi-hypothetical.
Some time ago we have troubles with sshd, fetchmail and other software
after r296462. pkg don't show any useful for versions of
sshd/fetchmail/etc because root cause will be breakin ABI in
libcrypto. For useful information pkg need to show version of quering
package and version of all depened packages. Is this allow now by
simple command?

Also, how to naming individual packages?
For port software we have released version, for STABLE -- rollover
release. Currently used naming is useless, using svn revision of
top-level dir usefull only for two-package case.

Using svn revision of individual dirs need addtional patches and
addtional rules:

/usr/src/sys/modules/aio # svnlite info
Path: .
Working Copy Root Path: /usr/src
URL: svn://svn0.eu.freebsd.org/base/stable/10/sys/modules/aio
Relative URL: ^/stable/10/sys/modules/aio
Repository Root: svn://svn0.eu.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 295564
Node Kind: directory
Schedule: normal
Last Changed Author: jhb
Last Changed Rev: 185878
Last Changed Date: 2008-12-10 23:56:19 +0300 (Wed, 10 Dec 2008)

/usr/src/sys/modules/aio # less Makefile
# $FreeBSD: stable/10/sys/modules/aio/Makefile 185878 2008-12-10 20:56:19Z jhb $

.PATH: ${.CURDIR}/../../kern

KMOD=   aio
SRCS=   vfs_aio.c opt_vfs_aio.h vnode_if.h opt_compat.h

EXPORT_SYMS= aio_init_aioinfo aio_aqueue

.include 

i.e. actual revision is max(vfs_aio.c opt_vfs_aio.h vnode_if.h opt_compat.h) or 
even
max(deps(vfs_aio.c opt_vfs_aio.h vnode_if.h opt_compat.h))

Is this posible?

> A tool like pkg makes it easy to know which package is associated
> with a given file and also which packages that package depends upon
> and which are dependencies of it.  So, pkg makes it relatively
> painless to zoom in or out from a given symptom (i.e., binary or
> library that might have changed).  I don't believe this is possible
> in the current FreeBSD setup.  This is a huge gain in functionality.

You are lost may point. I am not against of pkg, I am just try more planing
before implementation. Changing in distribution scheme is very expensive.
___
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)

[Paul Mather]

___
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)

[Paul Mather]

On Apr 20, 2016, at 10:54 AM, Slawa Olhovchenkov  wrote:

>> A packaged base is just another way of describing the state of the
>> system.  People on mailing lists will still be able to help people
>> fix their problems, but they'll just use different information to
>> pinpoint the precise components affected.
> 
> How identify this systems? By 800-line lists of package versions?


In my experience, troubleshooting usually proceeds from the description of the 
symptoms.  So, if someone says, "I just updated and Sendmail has stopped 
sending e-mails," or "I just updated and I can no longer SSH into my system," 
then the logical question is to ask what versions of the packages they're 
running that pertain to those binaries.  In other words, you start at the 
symptom and work outwards from there.  In my experience, it's not necessary to 
have an exact inventory of a system to be able to solve a problem with it.

A tool like pkg makes it easy to know which package is associated with a given 
file and also which packages that package depends upon and which are 
dependencies of it.  So, pkg makes it relatively painless to zoom in or out 
from a given symptom (i.e., binary or library that might have changed).  I 
don't believe this is possible in the current FreeBSD setup.  This is a huge 
gain in functionality.

Cheers,

Paul.

___
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)

[David Chisnall]

On 20 Apr 2016, at 15:53, Paul Mather  wrote:
> 
> Arguably, a packaged base will make it easier to help people, because it 
> makes more explicit the dependencies of different parts of the system.  It's 
> been my experience that the interactions and impact of the various 
> /etc/src.conf settings are not entirely well known, at least to end-users.

In particular, with libxo output from pkg, we can get a machine-readable 
detailed dump of all of the base system packages installed and provide a single 
‘system dump’ command that includes this, relevant information from dmesg, and 
so on for bug triaging.

David



smime.p7s
Description: S/MIME cryptographic signature

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

[Slawa Olhovchenkov]

On Wed, Apr 20, 2016 at 10:43:08AM -0400, Paul Mather wrote:

> 
> > Message: 20
> > Date: Wed, 20 Apr 2016 12:48:06 +0300
> > From: Slawa Olhovchenkov <s...@zxy.spb.ru>
> > To: Dan Partelly <dan_parte...@rdsor.ro>
> > Cc: David Chisnall <thera...@freebsd.org>, Julian Elischer
> > <jul...@freebsd.org>, Nathan Whitehorn <nwhiteh...@freebsd.org>,
> > freebsd-current@freebsd.org
> > Subject: Re: [CFT] packaging the base system with pkg(8)
> > Message-ID: <20160420094806.gj6...@zxy.spb.ru>
> > Content-Type: text/plain; charset=utf-8
> > 
> > On Wed, Apr 20, 2016 at 12:00:36PM +0300, Dan Partelly wrote:
> > 
> >> IMO,  the number of packages per-se is not a problem as long as you
> >> can manage them without arcane commands, aliases, pipe - filters,
> >> or scripts. (they all have their place, but less , the better)  My
> >> point is that I don't really want to keep on my head a Unix hacker
> >> hat. I (and presumably many other humans ) like simple things,which
> >> allow me to type a short command (preferably the whole system should
> >> be simple enough to be explained in one-two pages in handbook) ,
> >> wait for completion, and get on with my life.
> > 
> > Yes and no.
> > While number of packages don't see outside internal -- this is
> > irrelevant.
> > After possibility of update individual package -- nuber of packages is
> > impotant.
> > Take fresh 11.0. Before 11.1 update only kernel. What you system have?
> > 11.0? 11.1-RC3? How you name it? How identify it for take support on
> > forum or mail list?
> > 
> > How name system, updated all w/o compiler? or only some services?
> > Currently we have simple naming:
> > 
> > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456.
> > This is shortly and clearly identify system to anyone.
> 
> Superficially, it does, but in reality it doesn't.  I can grab the
> source for 10.3-RELEASE and then add a lot of WITH_* and WITHOUT_*
> settings in /etc/src.conf and build a kernel and world and end up
> with a system that is missing a lot of functionality that is
> ordinarily present with an empty /etc/src.conf.  That missing
> functionality could be the reason for a problem I am having with my
> "10.3-RELEASE" system.

Identification of custom builds is another problem and now we do this
by contens of src.conf, make.conf options and kernel config file.
This is enough and I am don't see necessity for change.

> That is the reality of FreeBSD *now* and I still am able to get help on 
> FreeBSD mailing lists when I have problems.
> 
> The case of a moving target is truer of those who choose to run
> -STABLE or -CURRENT.  If I say I'm running 10.3-STABLE three months
> from now, what version of the code base am I actually running?
> Sure, now we have the SVN revision number to help pinpoint the
> version of the code being run (setting aside the effects of
> /etc/src.conf), but back in the days when FreeBSD was in CVS we
> didn't have that nicety and yet people were still able to get help
> with problems running -STABLE or -CURRENT on the mailing lists.

With CVS we use timestamp (as for csup).

> A packaged base is just another way of describing the state of the
> system.  People on mailing lists will still be able to help people
> fix their problems, but they'll just use different information to
> pinpoint the precise components affected.

How identify this systems? By 800-line lists of package versions?

> Arguably, a packaged base will make it easier to help people,
> because it makes more explicit the dependencies of different parts
> of the system.  It's been my experience that the interactions and
> impact of the various /etc/src.conf settings are not entirely well
> known, at least to end-users.

Some /etc/src.conf settings is compile-time options and can't be done
by packages. Kerberos, for example.
___
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)

[Paul Mather]

> Message: 20
> Date: Wed, 20 Apr 2016 12:48:06 +0300
> From: Slawa Olhovchenkov <s...@zxy.spb.ru>
> To: Dan Partelly <dan_parte...@rdsor.ro>
> Cc: David Chisnall <thera...@freebsd.org>, Julian Elischer
>   <jul...@freebsd.org>, Nathan Whitehorn <nwhiteh...@freebsd.org>,
>       freebsd-current@freebsd.org
> Subject: Re: [CFT] packaging the base system with pkg(8)
> Message-ID: <20160420094806.gj6...@zxy.spb.ru>
> Content-Type: text/plain; charset=utf-8
> 
> On Wed, Apr 20, 2016 at 12:00:36PM +0300, Dan Partelly wrote:
> 
>> IMO,  the number of packages per-se is not a problem as long as you
>> can manage them without arcane commands, aliases, pipe - filters,
>> or scripts. (they all have their place, but less , the better)  My
>> point is that I don't really want to keep on my head a Unix hacker
>> hat. I (and presumably many other humans ) like simple things,which
>> allow me to type a short command (preferably the whole system should
>> be simple enough to be explained in one-two pages in handbook) ,
>> wait for completion, and get on with my life.
> 
> Yes and no.
> While number of packages don't see outside internal -- this is
> irrelevant.
> After possibility of update individual package -- nuber of packages is
> impotant.
> Take fresh 11.0. Before 11.1 update only kernel. What you system have?
> 11.0? 11.1-RC3? How you name it? How identify it for take support on
> forum or mail list?
> 
> How name system, updated all w/o compiler? or only some services?
> Currently we have simple naming:
> 
> 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456.
> This is shortly and clearly identify system to anyone.

Superficially, it does, but in reality it doesn't.  I can grab the source for 
10.3-RELEASE and then add a lot of WITH_* and WITHOUT_* settings in 
/etc/src.conf and build a kernel and world and end up with a system that is 
missing a lot of functionality that is ordinarily present with an empty 
/etc/src.conf.  That missing functionality could be the reason for a problem I 
am having with my "10.3-RELEASE" system.

That is the reality of FreeBSD *now* and I still am able to get help on FreeBSD 
mailing lists when I have problems.

The case of a moving target is truer of those who choose to run -STABLE or 
-CURRENT.  If I say I'm running 10.3-STABLE three months from now, what version 
of the code base am I actually running?  Sure, now we have the SVN revision 
number to help pinpoint the version of the code being run (setting aside the 
effects of /etc/src.conf), but back in the days when FreeBSD was in CVS we 
didn't have that nicety and yet people were still able to get help with 
problems running -STABLE or -CURRENT on the mailing lists.

A packaged base is just another way of describing the state of the system.  
People on mailing lists will still be able to help people fix their problems, 
but they'll just use different information to pinpoint the precise components 
affected.

Arguably, a packaged base will make it easier to help people, because it makes 
more explicit the dependencies of different parts of the system.  It's been my 
experience that the interactions and impact of the various /etc/src.conf 
settings are not entirely well known, at least to end-users.

Cheers,

Paul.
___
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)

[Andrew Berg]

On 2016.04.20 07:58, Lev Serebryakov wrote:

   It is very worrying to see such reports without any reaction from
developers in one month before release. If there is one year till
release, it is nothing. But in one month we will have code slush, and
after that — release, which should be supported for several years!

  Also, suggested (and totally ignored in discussion) mechanisms with
overlay packages is not UI, it is underlying mechanism which could be
very useful.

   Again, I have nothing against good package management for base. But
what I see now is scary, if you take one-month-before-release in account!

You mention code slush, but keep saying one month before release. Code slush 
means *new features* are *discouraged*, not "freeze everything and let it sit 
for months without addressing any issues". Release is not planned until 
*September*, and if it is not ready in September, then the release will be 
delayed. In fact, releases are very frequently delayed since the dates are 
always estimates and never deadlines. Yes, we are getting somewhat close to 
release, but there is still time. Also, packaged base work was supposed to be 
complete enough for wide testing much earlier, but development was stalled for 
a while.


Also, how much response do you expect in ~17 hours? Developers need time to 
sleep, do their day jobs, and formulate a detailed response to a detailed email.


There are certainly issues, but this is not something that is going to be 
rushed into a release in a month to meet a hard deadline as you imply.

___
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 20.04.2016 11:12, David Chisnall wrote:

> all of the complaints in this thread have been about the UI, not about the 
> underlying mechanism.  
  Nope. And there are (small) thread in other mailing list with very big
concerns about underlying mechanisms, which doesn't have any attention:

https://lists.freebsd.org/pipermail/freebsd-pkgbase/2016-April/000183.html

  It is very worrying to see such reports without any reaction from
developers in one month before release. If there is one year till
release, it is nothing. But in one month we will have code slush, and
after that — release, which should be supported for several years!

 Also, suggested (and totally ignored in discussion) mechanisms with
overlay packages is not UI, it is underlying mechanism which could be
very useful.

  Again, I have nothing against good package management for base. But
what I see now is scary, if you take one-month-before-release in account!

-- 
// Lev Serebryakov



signature.asc
Description: OpenPGP digital signature

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

[dan_partelly]

> If these informations were more public I think there will be less 
> annoyed posts in mailinglist and more constructive critics / ideas / 
> patches.
> 

And there other issues arising from the lack of communication:

How exactly bugs / incomplete features are treated in FreeBSD ?  Many
times the public gets the impression that save for the show-stopper bugs,
or bugs which affect the employers of FreeBSD developers, 
they don't get too much priority. If any. 

I talked before about VIMAGE and the bugs surrounding it. Some of those
bugs  are  there for years. Yes VIMAGE was good enough, and as was told
before in this thread a success. I am not contesting that. Yet not even
today all those bugs and memory leaks are fixed.  Patches for some  bugs
floated around, some where collected some not, only god knows. I heard that
now for FreeBSD 11 the FreeBSD foundation forked some money to get it
done. I hope they will.

Another example is the autofs mounter. The prject was marked as complete
by FreeBSD foundation in 2014. Last I tried it to autmount removable
devices, it left directory after directory in the autofs managed directory.
This is known behavior. It also did not worked as it should ??? (show it
manage removable media correctly ) changing CD/DVD media disks. Presumably
In could have somehow manage it to work by making yet another scaffolding
of scripts as a questionable glue between devd and automounters.  That if
devd receives media change notifications. I dont know. If not I could patch
the kernel, yeah. But it is just much to simple to not bother at all and
use OSx. 

DRM drivers ? Done, but more or less in the same state by years. At least
not important in server space. 

outlining those issues should not make anyone feel criticized. Things are
what they are, maybe its better to think what are the root causes of issues
like those outlined before. Does the project lacks manpower ? If it does
maybe the developers should do something to attract and nurse more and more
potential people.  Are those issues you dont want to work on or you dont
have an agenda to  make them bug free and work orthogonal? No problem, make
a statement and
say .. we wont ever do this , or it will take 6 years ... or whatever.

It is not helpful to complain that people do not appreciate your hard
work, becuae ppl do. Also not helpful to complain about tones which should
be toned down by 2 orders of magnitude, peasants and castles.   
 It is also not helpful to complain that people oppose progress when you
are pointed some issues.It couldn't be further removed from truth, at least
in my case. But I think most ppl on this list want progress. At least this
is my impression.  Too much of Unix is badly stuck in the past.
___
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 Wed, Apr 20, 2016 at 11:43:00AM +0100, Matthew Seaman wrote:

> On 04/20/16 10:48, Slawa Olhovchenkov wrote:
> 
> > While number of packages don't see outside internal -- this is
> > irrelevant.
> > After possibility of update individual package -- nuber of packages is
> > impotant.
> > Take fresh 11.0. Before 11.1 update only kernel. What you system have?
> > 11.0? 11.1-RC3? How you name it? How identify it for take support on
> > forum or mail list?
> > 
> > How name system, updated all w/o compiler? or only some services?
> > Currently we have simple naming:
> > 
> > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456.
> > This is shortly and clearly identify system to anyone.
> > 
> > How do this with many packages?
> 
> Hmmm Good point.
> 
> At release time, a set of packages will be generated.  These will all
> have the version number of the release eg. 11.0.  That's simple and
> unambiguous.
> 
> Subsequently adding patches will add a patch level to the version, so
> 11.0-p1, 11.0-p2 exactly as now.  Only patches that affect the kernel
> will cause the output of uname(1) to show the new patch level, but
> updates to user land should be reflected in the output of
> freebsd-version(1).  That's exactly the same as now, and assuming you,
> as an end user, install the default set of FreeBSD packages and apply
> all the patches as they come out, then there should be no problem.
> 
> This implies that /every/ patchset will include an update to the package
> containing freebsd-version.
> 
> What packaging base does do is allow you to be selective in the patches
> you apply.  So, for instance if patch -p1 was not relevant to you, you
> might not install it.  So you could end up with a system where you
> hadn't installed patches -p1 -- -p9 but you did install patch -p10.  The
> freebsd-version(1) output would presumably show the system as 11.0-p10
> -- but that's certainly not the same as a system with all of those
> patches -p1 to -p9 applied.  Or you could just install the updated
> freebsd-version(1) package and have your system blatantly lie about its
> patching status.

This is about RELENG, what about STABLE and CURRENT?

> So, yes, this does change the meaning of the version number string.
> It's morally equivalent to tracking the releng/11.0 branch in SVN but
> compiling your system with various WITH_FOO or WITHOUT_BAR flags, and
> possible local modifications to the code base to back out certain
> commits.  It's still 11.0-SOMETHING but it's not clear exactly what that
> something should  be.  Hopefully people that do such things will be
> sufficiently technically sophisticated to be able to characterize their
> problems based on the versions of any relevant FreeBSD packages.
> 
> On the release of 11.1 there would be a complete new set of system
> packages generated, and the upgrade process would install the new
> versions of those packages all round, even if the content of an
> individual package was identical to the one in 11.0.  There's probably a
> handy optimization where we compare the before and after checksums for
> package files and don't overwrite on disk what is identical between
> package versions, but do update all of the bookkeeping in the pkgdb.

New numbering scheme is very hard problem...
___
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]

Matthew Seaman wrote on 04/20/2016 12:43:


On the release of 11.1 there would be a complete new set of system
packages generated, and the upgrade process would install the new
versions of those packages all round, even if the content of an
individual package was identical to the one in 11.0.  There's probably a
handy optimization where we compare the before and after checksums for
package files and don't overwrite on disk what is identical between
package versions, but do update all of the bookkeeping in the pkgdb.


This will be a really nice feature which can save a lot of bandwidth and 
storage for backups after upgrade. (but I don't know how many files are 
usually unchanged between upgrades)


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)

[Miroslav Lachman]

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.


I really like FreeBSD, I am using it for more than 15 years on daily 
basis. FreeBSD had good and bad times (releases / changes) but one thing 
stays always the same - still bad communication about new features, work 
in progress etc.
I think it is not too hard to publish papers about new base packages. 
Proposals, current state, ToDo to better inform users about upcoming 
changes. I think these informations already exist in some private form 
between developers.
If these informations were more public I think there will be less 
annoyed posts in mailinglist and more constructive critics / ideas / 
patches.


I did a guick search and found only one closely related page about 
packaged base:

https://wiki.freebsd.org/FreeBSD-ng last edited 2014-03-11

Even this old page has "Known problems" mentioning the situation what we 
have now in this thread (fed-up people on both sides). So I think this 
was expected and people involved in this project could have do 
communication better.


I had some concerns about it and some of them were explained and 
canceled after reading more than 100 posts in this thread. (some 
concerns remain). I believe if it was written in FreeBSD Wiki, there 
were not be so much dissapointed posts.


I don't want to offend anybody on this list or FreeBSD team. I just 
think that things like this can and should be communicated better next 
time. Sysadmins and sysdevelopers have different point of view to a lot 
of things and it is better to talk about it before things are done and 
cannot be undone.


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)

[Matthew Seaman]

On 04/20/16 10:48, Slawa Olhovchenkov wrote:

> While number of packages don't see outside internal -- this is
> irrelevant.
> After possibility of update individual package -- nuber of packages is
> impotant.
> Take fresh 11.0. Before 11.1 update only kernel. What you system have?
> 11.0? 11.1-RC3? How you name it? How identify it for take support on
> forum or mail list?
> 
> How name system, updated all w/o compiler? or only some services?
> Currently we have simple naming:
> 
> 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456.
> This is shortly and clearly identify system to anyone.
> 
> How do this with many packages?

Hmmm Good point.

At release time, a set of packages will be generated.  These will all
have the version number of the release eg. 11.0.  That's simple and
unambiguous.

Subsequently adding patches will add a patch level to the version, so
11.0-p1, 11.0-p2 exactly as now.  Only patches that affect the kernel
will cause the output of uname(1) to show the new patch level, but
updates to user land should be reflected in the output of
freebsd-version(1).  That's exactly the same as now, and assuming you,
as an end user, install the default set of FreeBSD packages and apply
all the patches as they come out, then there should be no problem.

This implies that /every/ patchset will include an update to the package
containing freebsd-version.

What packaging base does do is allow you to be selective in the patches
you apply.  So, for instance if patch -p1 was not relevant to you, you
might not install it.  So you could end up with a system where you
hadn't installed patches -p1 -- -p9 but you did install patch -p10.  The
freebsd-version(1) output would presumably show the system as 11.0-p10
-- but that's certainly not the same as a system with all of those
patches -p1 to -p9 applied.  Or you could just install the updated
freebsd-version(1) package and have your system blatantly lie about its
patching status.

So, yes, this does change the meaning of the version number string.
It's morally equivalent to tracking the releng/11.0 branch in SVN but
compiling your system with various WITH_FOO or WITHOUT_BAR flags, and
possible local modifications to the code base to back out certain
commits.  It's still 11.0-SOMETHING but it's not clear exactly what that
something should  be.  Hopefully people that do such things will be
sufficiently technically sophisticated to be able to characterize their
problems based on the versions of any relevant FreeBSD packages.

On the release of 11.1 there would be a complete new set of system
packages generated, and the upgrade process would install the new
versions of those packages all round, even if the content of an
individual package was identical to the one in 11.0.  There's probably a
handy optimization where we compare the before and after checksums for
package files and don't overwrite on disk what is identical between
package versions, but do update all of the bookkeeping in the pkgdb.

Cheers,

Matthew








signature.asc
Description: OpenPGP digital signature

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

[Slawa Olhovchenkov]

On Wed, Apr 20, 2016 at 12:00:36PM +0300, Dan Partelly wrote:

> IMO,  the number of packages per-se is not a problem as long as you
> can manage them without arcane commands, aliases, pipe - filters,
> or scripts. (they all have their place, but less , the better)  My
> point is that I don't really want to keep on my head a Unix hacker
> hat. I (and presumably many other humans ) like simple things,which
> allow me to type a short command (preferably the whole system should
> be simple enough to be explained in one-two pages in handbook) ,
> wait for completion, and get on with my life.

Yes and no.
While number of packages don't see outside internal -- this is
irrelevant.
After possibility of update individual package -- nuber of packages is
impotant.
Take fresh 11.0. Before 11.1 update only kernel. What you system have?
11.0? 11.1-RC3? How you name it? How identify it for take support on
forum or mail list?

How name system, updated all w/o compiler? or only some services?
Currently we have simple naming:

10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456.
This is shortly and clearly identify system to anyone.

How do this with many packages?
I am describe in -pkgbase expirence of updating system.
How I am can naming this (my) system?

Solaris don't ship new version often and don't have rollover updates.

I think, first step may be split to only two package (kernel and
world) and resolve many other issuses: distinc base packages from port
packages, beadm compatibility, /etc and config updates (/etc/rc.d is
not config but currently allowed to editing, this is distinct from
plain ports configs) and others. After expirence with this next step
will be more clear.

> When I said people should pay more attention to Redmond and Cupertino, this 
> is what I meant. UIs are important. Easy service management, fault reporting  
> and so on should be automated. We shouldn't waste our time doing what the 
> computer should do in the first place.  Most people want to get  the job 
> done, so they can proceed with what is important for them. I am  very sorry 
> if this is so offensive to some people that they feel attacked, but 
> unfortunately there   aint  much I can do to alleviate this. 
> 
> > 
> > 1) The number of packages that the base system has.
> > 2) The user interface by which the packages are presented.
> > 
> > I believe (and, please, correct me if I’m wrong), that all of the 
> > complaints in this thread have been about the UI, not about the underlying 
> > mechanism.  That’s not to say that they’re unimportant (quite the reverse), 
> > but that they can be solved concurrently with the task of preparing the 
> > base system for distribution in packaged form.
> > 
> 
> ___
> 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)

[Dan Partelly]

IMO,  the number of packages per-se is not a problem as long as you can manage 
them without arcane commands, aliases, pipe - filters,  or scripts. (they all 
have their place, but less , the better)  My point is that I don't really want 
to keep on my head a Unix hacker hat. I (and presumably many other humans ) 
like simple things,which allow me to type a short command (preferably the whole 
system should be simple enough to be explained in one-two pages in handbook) ,  
wait for completion, and get on with my life. 

When I said people should pay more attention to Redmond and Cupertino, this is 
what I meant. UIs are important. Easy service management, fault reporting  and 
so on should be automated. We shouldn't waste our time doing what the computer 
should do in the first place.  Most people want to get  the job done, so they 
can proceed with what is important for them. I am  very sorry if this is so 
offensive to some people that they feel attacked, but unfortunately there   
aint  much I can do to alleviate this. 

> 
> 1) The number of packages that the base system has.
> 2) The user interface by which the packages are presented.
> 
> I believe (and, please, correct me if I’m wrong), that all of the complaints 
> in this thread have been about the UI, not about the underlying mechanism.  
> That’s not to say that they’re unimportant (quite the reverse), but that they 
> can be solved concurrently with the task of preparing the base system for 
> distribution in packaged form.
> 

___
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)

[David Chisnall]

On 20 Apr 2016, at 06:06, 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.

I think that it’s very important, for the purpose of a constructive discussion, 
to separate the two concerns:

1) The number of packages that the base system has.
2) The user interface by which the packages are presented.

I believe (and, please, correct me if I’m wrong), that all of the complaints in 
this thread have been about the UI, not about the underlying mechanism.  That’s 
not to say that they’re unimportant (quite the reverse), but that they can be 
solved concurrently with the task of preparing the base system for distribution 
in packaged form.

Having fine-grained packages makes a lot of things possible that are difficult 
otherwise, but we do need to fix the UI.


> 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.

Part of the problem is that we don’t actually have metapackages.  A metapackage 
is a package that *contains* other packages.  What we actually have is empty 
packages that *depend on* other packages.  The package tool has no way of 
distinguishing a package that you install for the sole purpose of installing 
its dependencies from one that you install because you want it (though having 
no files inside it might serve as an heuristic that would work).

> 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.

Doing this properly also requires the notion of optional default and 
non-default subpackages.  I should be prevented from uninstalling (at least, 
without a lot of -f) non-optional subpackages.  For example, on a small system 
where I’m not using zfs, I might uninstall the libzfs subpackage from 
freebsd-libs, but if I try to uninstall the libc package then the system should 
shout at me.

> 
> 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.

Thank you for this suggestion.  I think that this is the sort of UI that makes 
a lot of sense (though having subpackage support would also be useful for 
ports).  It’s also the kind of thing that I think we could persuade the 
Foundation to fund if there is not enough volunteer time to implement it.

David



smime.p7s
Description: S/MIME cryptographic signature

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

[K. Macy]

On Mon, Apr 18, 2016 at 12:14 PM, 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.

I don't know what the "ideal" number of packages is. 755 does seem
large. However, I see it being like KSE. In hindsight KSE was overly
complicated and M:N threading wasn't the way to go. However, Julian's
work brought native threading to FreeBSD. Something it sorely needed.

Similarly, the packaging of base FreeBSD is something  that has been
desperately needed for a long time but the work to get there was
simply overwhelming. Initially there will very likely be painful
problems, but I'm comfortable that all those involved will course
correct and converge on something that most people will be content
with.

I'm sure there are those with well articulated criteria for a
different decomposition of base, with specifics on how and why. Those
select individuals can contribute meaningfully to this discussion.
Everyone else should just applaud their hard work and get back to
work. There are plenty of bugs that could have been fixed in the time
it would have taken to digest this whole thread.

-M
___
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 Seaman]

On 20/04/2016 06:12, Daniel Eischen wrote:
> [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.]

'pkg list' is one of the aliases defined in the default pkg.conf -- if
you want to rename it to 'pkg files' that's trivially easy.  If there's
any sort of consensus that 'pkg files' would be preferable in general
then I'm sure that the sample pkg.conf can be fixed in git.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

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

[Julian Elischer]

On 20/04/2016 2:25 PM, Daniel Eischen wrote:

On Wed, 20 Apr 2016, Allan Jude wrote:


On 2016-04-20 01:12, Daniel Eischen wrote:


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)


pkg prime-list does show the explicitly installed packages,
not sure how one would know to use 'prime-list' since it
doesn't appear in any of the man pages (looking at FreeBSD
10-stable right now).  And it doesn't show version information,
nor other option arguments that I can tell.  pkg help prime-list
says it's just an alias for "query -e '%a = 0' '%n'".  Seems
like "query -e '%a = 0' '%n\t%v\t%o'" is a little nicer,
though I'm not sure how to get all the columns to line up
nicely.

equally missing from help is 'pkg leaf'

These show that information needed is available.. it just needs to be 
presented right.





___
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 Wed, Apr 20, 2016 at 04:22:31AM +, Glen Barber wrote:

> 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, you do hard work and we much appreciated to you.
But some don't have fluent english, for examle, I, and I can't create
political sentense on english, restrict to pithy and informative
sentense.

Also, I am to long work with many comercial vendors and have some
deformation, for example, when introductin new feature and don't
provide direct promise of save old competition functionality -- in
near, very near future this functionality will be removed. Please, do
direct promise and describe you vision. We only see you commit and
nothing more, this is too smal and we worry.

Yes, now 11 is -current. But after mont -- this is STABLE and nothing
to change w/o POLA violation! Price of flaw now very high (for project
in first case).

Yes, FreeBSD need new model for update and upgrade. But this tool
implemented once have long impact and need have compatible more then
base system.

I am want cool FreeBSD and try to help this, by my expirens in system
maintenance (not only FreeBSD). My expirense talk: change is very
expensive. May be need do not put 11 to stable. Or may be schedule to
some month. Or except this suvsystem from POLA. I am don't know. What
you vision? What main distribution will be used in 11-RELEASE?
What status will be have base packaging in 11?
___
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, Allan Jude wrote:


On 2016-04-20 01:12, Daniel Eischen wrote:


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)


pkg prime-list does show the explicitly installed packages,
not sure how one would know to use 'prime-list' since it
doesn't appear in any of the man pages (looking at FreeBSD
10-stable right now).  And it doesn't show version information,
nor other option arguments that I can tell.  pkg help prime-list
says it's just an alias for "query -e '%a = 0' '%n'".  Seems
like "query -e '%a = 0' '%n\t%v\t%o'" is a little nicer,
though I'm not sure how to get all the columns to line up
nicely.

--
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)

[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"

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"

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: [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: [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: [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