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

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

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

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


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