FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 08-29-2008, 10:27 AM
Thomas Bchler
 
Default Cleaning up the base group

Now that our installer installs the whole base group by default, I'd
wish it would stick to the essential part. I suggest cleaning this up a bit:



Packages that IMO shouldn't be in base:
- dialog
Nothing depends on it, why do we even need it in core?
- hwdetect
Nothing uses it, we don't need that in core either
- ca-certificates, lzo2, openssl, wpa_supplicant
We need those in core, but really not in base
- dash
Nobody uses it by default, may IMO stay in core, but has no place in
base



- ppp, rp-pppoe (plus libpcap dep)
Only few people need those, leave them in core, but remove from base
- tcp_wrappers
No base package needs them as far I know, leave in core, remove from base

We should also remove all packages from base that only are in there as a
dependency of another package and for no other reason, as they will be
pulled in when needed anyway.


Packages that we should think about:
- mdadm
- pcmciautils
- cryptsetup, lvm2 (plus their deps libgcrypt, libgpg-error, device-mapper)
Those are base tools, but not everybody needs them. I'd like to keep
them in base, but maybe someone else may disagree.

- nano
Do we really need another editor in base? Let's leave it in core, remove
it from base.
 
Old 08-29-2008, 12:17 PM
RedShift
 
Default Cleaning up the base group

Thomas Bchler wrote:
Now that our installer installs the whole base group by default, I'd
wish it would stick to the essential part. I suggest cleaning this up a
bit:



Packages that IMO shouldn't be in base:
- dialog
Nothing depends on it, why do we even need it in core?
- hwdetect
Nothing uses it, we don't need that in core either
- ca-certificates, lzo2, openssl, wpa_supplicant
We need those in core, but really not in base
- dash
Nobody uses it by default, may IMO stay in core, but has no place in base

- ppp, rp-pppoe (plus libpcap dep)
Only few people need those, leave them in core, but remove from base
- tcp_wrappers
No base package needs them as far I know, leave in core, remove from base

We should also remove all packages from base that only are in there as a
dependency of another package and for no other reason, as they will be
pulled in when needed anyway.


Packages that we should think about:
- mdadm
- pcmciautils
- cryptsetup, lvm2 (plus their deps libgcrypt, libgpg-error, device-mapper)
Those are base tools, but not everybody needs them. I'd like to keep
them in base, but maybe someone else may disagree.

- nano
Do we really need another editor in base? Let's leave it in core, remove
it from base.





You should still make it possible to select which packages you want to install.

Glenn
 
Old 08-29-2008, 12:22 PM
Arvid Ephraim Picciani
 
Default Cleaning up the base group

On Friday 29 August 2008 14:17:06 RedShift wrote:

> > - ppp, rp-pppoe (plus libpcap dep)
> > Only few people need those, leave them in core, but remove from base

just remember to keep them on the minimal live cd
--
best regards
Arvid Ephraim Picciani
 
Old 08-29-2008, 12:29 PM
"Grigorios Bouzakis"
 
Default Cleaning up the base group

On Fri, Aug 29, 2008 at 3:22 PM, Arvid Ephraim Picciani
<aep@ibcsolutions.de> wrote:
> On Friday 29 August 2008 14:17:06 RedShift wrote:
>
>> > - ppp, rp-pppoe (plus libpcap dep)
>> > Only few people need those, leave them in core, but remove from base
>
> just remember to keep them on the minimal live cd

AFAIR theres only core & ftp isos nowadays. As long as selecting packages from
core is available as an option on both, i dont see a problem in keeping the base
group to an absolute minimum set of packages.
Maybe then not being able to select/deselect packages from base would make
more sense, even though its a very handy option prefered by most people.

As far as dialog, besides being used as a UI on the installer i dont
know why its
part of base.
 
Old 08-29-2008, 06:58 PM
"Roman Kyrylych"
 
Default Cleaning up the base group

2008/8/29 Thomas Bächler <thomas@archlinux.org>:
> Now that our installer installs the whole base group by default, I'd wish it
> would stick to the essential part. I suggest cleaning this up a bit:
>
>
> Packages that IMO shouldn't be in base:
. . .
agree.

>
> We should also remove all packages from base that only are in there as a
> dependency of another package and for no other reason, as they will be
> pulled in when needed anyway.
>
> Packages that we should think about:
> - mdadm
> - pcmciautils
> - cryptsetup, lvm2 (plus their deps libgcrypt, libgpg-error, device-mapper)
> Those are base tools, but not everybody needs them. I'd like to keep them in
> base, but maybe someone else may disagree.

Can be removed from base IMHO (and obviously left in core).

> - nano
> Do we really need another editor in base?
YES!
I'd rather like to see vim removed from base, than nano.

> Let's leave it in core, remove it from base.
-1024

--
Roman Kyrylych (*оман Кирилич)
 
Old 08-29-2008, 09:22 PM
"Aaron Griffin"
 
Default Cleaning up the base group

On Fri, Aug 29, 2008 at 5:27 AM, Thomas Bchler <thomas@archlinux.org> wrote:
> - dialog
> Nothing depends on it, why do we even need it in core?

Don't we have tools in base which use dialog? The only ones I can
think of are the installer and netcfg.

> - hwdetect
> Nothing uses it, we don't need that in core either

Agreed. We don't even use hwdetect for anything anymore. Move to extra.

> - ca-certificates, lzo2, openssl, wpa_supplicant
> We need those in core, but really not in base

Agreed. Let's remove them from base.

> - dash
> Nobody uses it by default, may IMO stay in core, but has no place in base

I agree. In the future when we actually get things that use dash, we
can throw it back in base.

> - ppp, rp-pppoe (plus libpcap dep)
> Only few people need those, leave them in core, but remove from base

Like RedShift said, as long as we make sure they're on the ISO, we
should be good.

> - tcp_wrappers
> No base package needs them as far I know, leave in core, remove from base

Are you sure about this? Something feels a little wrong about that,
but it may just be a gut feeling.


> We should also remove all packages from base that only are in there as a
> dependency of another package and for no other reason, as they will be
> pulled in when needed anyway.

Hmmm, that's probably a good idea. It would definitely clean up
"pacman -Sg base". As long as we ensure they deps still stay in core.

> Packages that we should think about:
> - mdadm
> - pcmciautils
> - cryptsetup, lvm2 (plus their deps libgcrypt, libgpg-error, device-mapper)
> Those are base tools, but not everybody needs them. I'd like to keep them in
> base, but maybe someone else may disagree.

Hmm, I agree. Another "remove from base, keep on ISO" case

> - nano
> Do we really need another editor in base? Let's leave it in core, remove it
> from base.

Agreed, but just note that we still want it on the ISO (again, heh)
 
Old 08-29-2008, 09:42 PM
Pierre Schmitz
 
Default Cleaning up the base group

Am Freitag 29 August 2008 12:27:50 schrieb Thomas Bchler:
> - nano
> Do we really need another editor in base? Let's leave it in core, remove
> it from base.

This might end up in a flamwar, but if we have to remove one editor I would
vote vor vim and keep nano. vi is a lot more than a simple text editor and
installs about 24MB while nano is only about 1140KB. :-)

--

Pierre Schmitz


Clemens-August-Strae 76
53115 Bonn

Telefon 0228 9716608
Mobil 0160 95269831
Jabber pierre@jabber.archlinux.de
WWW http://www.archlinux.de
 
Old 08-30-2008, 01:02 AM
Alessio Bolognino
 
Default Cleaning up the base group

On Fri 2008-08-29 23:42, Pierre Schmitz wrote:
> Am Freitag 29 August 2008 12:27:50 schrieb Thomas Bchler:
> > - nano Do we really need another editor in base? Let's leave it in
> > core, remove it from base.
>
> This might end up in a flamwar, but if we have to remove one editor I
> would vote vor vim and keep nano. [... more nonsense ]

|||||||||
vvvvvvvvv
*************
======================> * THIS * <================================
======================> * IS * <================================
======================> * MADNESS! * <================================
*************
^^^^^^^^^
|||||||||

:%s/Pierre Schmitz/Wuss Infidel/g
:wq!

--
Alessio (molok) Bolognino
 
Old 08-30-2008, 03:11 AM
"Aaron Griffin"
 
Default Cleaning up the base group

On Fri, Aug 29, 2008 at 4:42 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
> Am Freitag 29 August 2008 12:27:50 schrieb Thomas Bchler:
>> - nano
>> Do we really need another editor in base? Let's leave it in core, remove
>> it from base.
>
> This might end up in a flamwar, but if we have to remove one editor I would
> vote vor vim and keep nano. vi is a lot more than a simple text editor and
> installs about 24MB while nano is only about 1140KB. :-)

LOL. Let's just keep them both please.
 
Old 08-30-2008, 01:57 PM
wide-eye
 
Default Cleaning up the base group

> Packages that we should think about:
> - mdadm
> - pcmciautils
> - cryptsetup, lvm2 (plus their deps libgcrypt, libgpg-error, device-mapper)
> Those are base tools, but not everybody needs them. I'd like to keep
> them in base, but maybe someone else may disagree.

I just want to point out a few ways i know these are used and a few
things that need to be checked and patched before removing them.

1. These are all in rc.sysinit. the mdadm and cryptsetup sections do
not test if the binaries exist before trying to run them, just if the
configs exist. this could create exciting panics or other fun behavior
if someone enables it in rc.conf without adding the packages. but a
fix is a simple -x test added to the beginning of those sections.

2. setup(installer) will need to know it should add packages if you
answer yes to the various raid/lvm/encrypted questions. in the worst
case this would break ftp installs.

Ensuring the ftp installer isn't broken by this is my main concern.
will someone test the existing installer to see if it breaks with
these changes?

Besides setup, these are mainly user errors. So at least it needs to
be documented in the install guide.

Jonathan
 

Thread Tools




All times are GMT. The time now is 07:06 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org