On Wed, Apr 24, 2013 at 02:03:56PM -0400, Justin Edward Muniz wrote:
> >
> > I think the interface to pkgng and freebsd-update are still
> > interesting; at least more worthwhile than the kernel configuration
> > one.
> >
> > I think the pkgng one has the edge, since packages are updated far
> > mo
>
> During some tests with cut down kernels one can easily make unbuildable
> kernel, for example include option A, while omit hiddenly required B.
> If there could be framework at least with deps tracking/checking, what
> could be good for begin.
> Both for configuring, and code clean up.
> If thi
>
> It _is_ easy. But having a nice graphical tool which draws a pretty table
> of
> GENERIC and NOTES together with useful information about the possible
> options
> and devices would be a handy thing to have IMHO.
> Let's make FreeBSD userfriendly :-)
I agree completely, hopefully we can make
>
> I think the interface to pkgng and freebsd-update are still
> interesting; at least more worthwhile than the kernel configuration
> one.
>
> I think the pkgng one has the edge, since packages are updated far
> more often than base, and it's easier to track base.
>
> Now you are at a stage where
>
> I agree. Also, the kind of people who compile their kernels probably
> feel more comfortable in console mode :)
>
> The frontend for pkgng and freebsd-update might have a bigger user base.
>
Hello Fernando, thank you for pointing me towards kports earlier. I
appreciate your help.
It is star
On 24 April 2013 18:30, Justin Edward Muniz wrote:
>> Our kernel is actually very easy to configure, so I'm not convinced that
>> it's needed; you may be thinking of Linux's menuconfig, but I think that is
>> because of the complexity.
>>
>> Chris
>
>
>
> While configuring the kernel may be trivia
>
> Our kernel is actually very easy to configure, so I'm not convinced that
> it's needed; you may be thinking of Linux's menuconfig, but I think that is
> because of the complexity.
>
> Chris
>
While configuring the kernel may be trivial to someone who understands the
process and their systems
On Wed, Apr 24, 2013 at 5:43 AM, Lars Engels wrote:
> Am 24.04.2013 13:44, schrieb Chris Rees:
>
> Our kernel is actually very easy to configure, so I'm not convinced that
>> it's needed; you may be thinking of Linux's menuconfig, but I think that
>> is
>> because of the complexity.
>>
>
>
> It _
During some tests with cut down kernels one can easily make unbuildable
kernel, for example include option A, while omit hiddenly required B.
If there could be framework at least with deps tracking/checking, what
could be good for begin.
Both for configuring, and code clean up.
If this will come up
Am 24.04.2013 13:44, schrieb Chris Rees:
On 24 Apr 2013 05:36, "Justin Edward Muniz"
wrote:
Justin I say stick to FreeBSD-update . My reason is, as Pkgng
becomes
more popular , a front end for ports will be less useful as binary
packages
become more popular . Kports is a monster program
El 24/04/2013 13:45, "Chris Rees" escribió:
>
> On 24 Apr 2013 05:36, "Justin Edward Muniz"
wrote:
> >
> > >
> > > Justin I say stick to FreeBSD-update . My reason is, as Pkgng becomes
> > > more popular , a front end for ports will be less useful as binary
> packages
> > > become more popular .
On 24 Apr 2013 05:36, "Justin Edward Muniz" wrote:
>
> >
> > Justin I say stick to FreeBSD-update . My reason is, as Pkgng becomes
> > more popular , a front end for ports will be less useful as binary
packages
> > become more popular . Kports is a monster program , you should set a
> > reasonabl
>
> Justin I say stick to FreeBSD-update . My reason is, as Pkgng becomes
> more popular , a front end for ports will be less useful as binary packages
> become more popular . Kports is a monster program , you should set a
> reasonable goal ,and target dates; which may be hard with a cleanup proje
13 matches
Mail list logo
