Gentoo Logo
Gentoo Spaceship

Installation:
Gentoo Handbook
Installation Docs

Documentation:
Home
Listing
About Gentoo
Philosophy
Social Contract

Resources:
Bug Tracker
Developer List
Discussion Forums
Gentoo BitTorrents
Gentoo Linux Enhancement Proposals
IRC Channels
Mailing Lists
Mirrors
Name and Logo Guidelines
Online Package Database
Security Announcements
Staffing Needs
Supporting Vendors
View our CVS

Graphics:
Logos and themes
Icons
ScreenShots

Miscellaneous Resources:
Gentoo Linux Store
Gentoo-hosted projects
IBM dW/Intel article archive




List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Zac Medico <zmedico@g.o>
Subject: Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
Date: Sun, 28 Sep 2008 10:42:39 -0700
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marius Mauch wrote:
> On Sat, 27 Sep 2008 17:21:18 -0700
> Zac Medico <zmedico@g.o> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi everyone,
>>
>> Please consider a PROPERTIES=set value that allows an ebuild to
>> indicate that it should behave like a package set when selected on
>> the command line. This is behavior is somewhat difficult to describe
>> in words but the following example should be sufficient to convey
>> the general idea. Consider a case where all of the kde-base/*-meta
>> packages exhibit the "set" property, and these packages and their
>> dependencies are currently installed. In such a case, the default
>> behavior for a command such as `emerge kde-base/kde-meta` should be
>> to reinstall the the selected kde-base/kde-meta ebuild and the set
>> of packages which includes it's direct dependencies and it's
>> recursive "set" dependencies. So, assuming that all USE flags are
>> enabled for the selected kde-base/kde-meta ebuild, it would
>> reinstall the direct dependencies of kdeartwork-meta, kdebase-meta,
>> kdeedu-meta, kdegames-meta, kdegraphics-meta, kdemultimedia-meta,
>> kdenetwork-meta, kdetoys-meta, kdeutils-meta, and
>> kdeaccessibility-meta ebuilds. Similarly, the default behavior for a
>> command such as `emerge --unmerge kde-base/kde-meta` would be to
>> uninstall the same set of packages.
> 
> I'm not convinced that this is a good idea if some packages suddenly
> behave _vastly_ different than others (from a users POV) without any
> clear indication (a -meta somewhere in the name IMO doesn't count).
> 
> Maybe we can just create a PackageSet class that wraps a package though
> to get the same behavior while keeping the two behaviors separated by
> syntax.

Some some sort of mapping of packages into sets space does seem
better than changing the behavior of these packages other cases.
However, PROPERTIES=set will still be useful for governing
recursion, since recursion into dependencies is probably not desired
for non-meta packages in the same sense that it might be desired for
meta-packages.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjfwg4ACgkQ/ejvha5XGaMkYACdF/uvOatcWaw1DsQkY/nBZ6RW
N4YAn2VFsZztPLzHO6V6T9eQER4b2tO9
=z2qG
-----END PGP SIGNATURE-----


Replies:
Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
-- Ciaran McCreesh
References:
[RFC] PROPERTIES=set for meta-packages that should behave like package sets
-- Zac Medico
Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
-- Marius Mauch
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
Next by thread:
Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
Previous by date:
Re: Preventing $ARCH flags in USE
Next by date:
Usage of econf with an additional || die


Updated Jun 17, 2009

Donate to support our development efforts.

Gentoo Centric Hosting: vr.org

VR Hosted

Tek Alchemy

Tek Alchemy

SevenL.net

SevenL.net

php|architect

php|architect

Copyright 2001-2007 Gentoo Foundation, Inc. Questions, Comments? Email www@gentoo.org.