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

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

> I could live with:
>
> base-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}

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

-Alfred


On 4/19/16 12:44 AM, Julian Elischer wrote:
> On 19/04/2016 5:29 AM, Alfred Perlstein wrote:
>> Guys please stop arguing about the number of packages.  The high 
>> granularity is VERY useful!
>>
> it's going to make us a laughing stock
> "look FreeBSD just split into 1.43 million packages" (effectively the 
> same number.. it's bigger than 10)
>
>
>> Managing large groups of small packages is much easier than just 
>> having large packages.
> err, Alfred, what planet do you live on? when they get out of sync it 
> becomes a nightmare.
> If you also had a packaging system that was smart enough to manage a 
> hierarchy of packages then "maybe"..
>
>>
>> All this can be done by meta-packages which depend on larger package 
>> groups.
> Currently Metapackage is a way to make 10 packages look like 11 
> packages.  The framework needs to understand to hide the 10 internal 
> packages if they are part of a metapackage.
>>
>> Later pkg can be augmented to "remove packages not explicitly 
>> installed" which would remove leaf packages.
>>
>> Example: you installed "base-debug" which pulls in let's say 50 small 
>> packages, later you want all of those removed, you can do something 
>> like:  "pkg delete --leafs base-debug" which should delete 
>> "base-debug" and any dangling packages it pulled in not required by 
>> other pkgs.
>>
>> Huge thanks to the team that implemented this!
>
> I'm sure the work was large and will be useful in the future but we 
> are not ready to have the system installed like this.
> no-one wants to see 750 packages show up when you do an enquiry on a 
> newly installed system.
> I could live with:
>
> base-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"
>>
>