[arch-dev-public] base group

Dan McGee dpmcgee at gmail.com
Tue Aug 21 11:38:08 EDT 2007


On 8/21/07, Roman Kyrylych <roman.kyrylych at gmail.com> wrote:
> 2007/8/21, Dan McGee <dpmcgee at gmail.com>:
> > On 7/18/07, Roman Kyrylych <roman.kyrylych at gmail.com> wrote:
> > > 2007/7/11, Aaron Griffin <aaronmgriffin at gmail.com>:
> > > > On 7/11/07, Dan McGee <dpmcgee at gmail.com> wrote:
> > > > > On 7/11/07, Andreas Radke <a.radke at arcor.de> wrote:
> > > > > > Am Wed, 11 Jul 2007 19:11:37 +0300
> > > > > > schrieb "Roman Kyrylych" <roman.kyrylych at gmail.com>:
> > > > > >
> > > > > > > Hi!
> > > > > > >
> > > > > > > IIRC this was mentioned some time ago, but I don't remember why it was
> > > > > > > not implemented.
> > > > > > > Why don't we have the "base" package group?
> > > > > > > IMO it would be nice if user would be able to do pacman -S base to get
> > > > > > > all base packages installed (e.g. in chroot or when installing from
> > > > > > > another distro).
> > > > > > >
> > > > > >
> > > > > > the installer recommends to install every pkg of "base". but it's still
> > > > > > useful to no install everything if you know what you are doing
> > > > > > (deselecting not used filesystem tools, only one editor, no pcmcia and
> > > > > > more). a metapkg isn't needed as i cannot see any point where a user
> > > > > > later would install it again.
> > > > > >
> > > > > > Andy
> > > > >
> > > > > By far the easiest way to make a chroot would be to have one command, however:
> > > > > pacman --root <path> --dbpath <path> -S base
> > > > >
> > > > > That is where I see the advantage.
> > > >
> > > > And what Roman already said in the initial email:
> > > > "IMO it would be nice if user would be able to do pacman -S base to
> > > > get all base packages installed (e.g. in chroot or when installing
> > > > from another distro)."
> > >
> > >
> > > Sooooo.....
> > > Can someone with access to Current please create dummy base package or group?
> > > ;-)
> >
> > I'm currently making some local changes to implement base as a group.
> > I've thought of one small thing I may want to do, however, and wanted
> > to get a few opinions before I go ahead with it. This involves
> > packages in the base category being split into two groups instead of
> > just one 'base' group:
> > base: acl, attr, bash, libalpm, pacman, e2fsprogs (this is up for debate), etc.
> > base-extra: lilo, jfsutils, mdadm, xfsdump, xfsprogs, etc.
> >
> > Basically the idea is to seperate general utilities that you
> > absolutely must have from utilities and programs that are a good idea
> > to have, but not everyone may need. This way you have a bit more
> > flexibility in choosing what you want to install when using these
> > groups.
> >
> > Thoughts?
> >
>
> I think about base-dev for gcc, automake, autoconf, etc.
> In future it could be possible to use libgcc as a dependency of most
> packages that use gcc libraries, and make gcc and stuff optional on
> everyone's machine.
> (i.e. I don't want to have gcc and friends on my server where I
> install only binary packages, or when I want to have tiny Arch system
> in VirtualBox).
> But this should be in a new dedicated thread I guess.
>
>
> 2007/8/21, Jason Chu <jason at archlinux.org>:
> >
> > Isn't this the same sort of thing as base vs. core?  One is absolute
> > necessaries and the other is stuff that some people will want depending on
> > their circumstances?
>
> Yes, something like that.
>
> base packages should not be in depends (except for packages in base
> group itself).
> base-dev packages should not be in makedepends.
> base-extra packages - they are just grouped for easy inclusion on install CD.

Instead of worrying about painting the bikeshed here, I just went
ahead and gave every package in the base category a group=('base')
line for now. This is easy enough to change later.

I also thought we didn't do the whole -dev packages thing here at Arch.

Either way, sorry for flooding inboxes of those of you on the
arch-commits ML. Over 100 changes were needed.

-Dan




More information about the arch-dev-public mailing list