Date: Tue, 19 Apr 2016 07:27:52 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Julian Elischer <julian@freebsd.org>, lev@FreeBSD.org, Glen Barber <gjb@FreeBSD.org>, Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: Sean Fagan <sef@ixsystems.com>, freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <57164068.8080800@freebsd.org> In-Reply-To: <5715E1E9.8060507@freebsd.org> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to
>> "freebsd-current-unsubscribe@freebsd.org"
>>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57164068.8080800>