[gentoo-dev] New eclasses for XEmacs lisp

[Hans de Graaff]

I'm about to commit two new eclasses to support the compilation,
configuration, and installation of XEmacs lisp classes. In a desperate
attempt not to re-invent the wheel the interface and structure of the
classes has been shamelessly copied from the Emacs lisp classes. 

Currently the implementation is not complete yet, and I intend to fill
in more of the blanks as I actually need them for specific packages,
again following the emacs lisp eclasses where appropriate. 

The eclasses have been in the Emacs overlay for some time now in support
of the forthcoming app-xemacs/gentoo-syntax package:

http://overlays.gentoo.org/proj/emacs/browser/emacs-overlay/eclass/xemacs-elisp.eclass
http://overlays.gentoo.org/proj/emacs/browser/emacs-overlay/eclass/xemacs-elisp-common.eclass

Bring on the comments, improvements, and most importantly: approval to
put this in the tree.

Kind regards,

Hans


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] gentoo-commits list lives!

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alec Warner wrote:
> On 9/7/07, Doug Goldstein <[EMAIL PROTECTED]> wrote:
>> Mike Frysinger wrote:
>>> On Friday 07 September 2007, Robin H. Johnson wrote:
 On Fri, Sep 07, 2007 at 02:44:21PM -0400, Mike Frysinger wrote:
>> X-VCS-Repository: gentoo-x86
>> X-VCS-Files: udev-115-r2.ebuild
>> X-VCS-Directories: sys-fs/udev
>> X-VCS-Committer: zzam
>> X-VCS-Committer-Name: Matthias Schwarzott,,,
> too bad we cant get herd/maintainer from metadata.xml :(
 Give me a service or something that can take a $CAT/$PN -> that data,
 and I can include it in the headers for you.
>>> maybe someone knows of an easier way ...
>>>
>>> $ xsltproc gentoo-metadata-herds.xsl /path/to/metadata.xml
>>> base-system someherds
>>> $ xsltproc gentoo-metadata-maintainers.xsl /path/to/metadata.xml
>>> [EMAIL PROTECTED] [EMAIL PROTECTED]
>>> -mike
>>>
>> Sure... be fancy with all your xsl and xml crap. LONG LIVE THE BRUTE
>> FORCE PARSE WITH SED!
> 
> People who parse xml with sed make me cry.
> 
> grep = also bad.

People who use XML and XSLT make me cry. Lisp macros ftw.

- --
Marijn Schouten (hkBst), Gentoo Lisp project
, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG4mwtp/VmCx0OL2wRAhnkAKDFKUlncZ1tl4xAIGQRbkJVuerbqACgxl7s
Xd47QuiXTmoY0snit4Vo63w=
=xNpc
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] New eclasses for XEmacs lisp

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hans de Graaff wrote:
> I'm about to commit two new eclasses to support the compilation,
> The eclasses have been in the Emacs overlay for some time now in support
> of the forthcoming app-xemacs/gentoo-syntax package:
> 
> http://overlays.gentoo.org/proj/emacs/browser/emacs-overlay/eclass/xemacs-elisp.eclass

I think it would be good to add a string argument to the call to die on line 22.

> http://overlays.gentoo.org/proj/emacs/browser/emacs-overlay/eclass/xemacs-elisp-common.eclass

You use $* and $@ here which are the same when unquoted. They should probably
be quoted and that means that all instances would become the four characters 
"$@".

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project
, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG4nP2p/VmCx0OL2wRAuSDAJ4zq1I35NKJDWc6VBkb48NODfsoGgCfTkpI
ZpQqOsjF5BjItbN+Ymuh1vU=
=KF2I
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: New eclasses for XEmacs lisp

[Steve Long]

Marijn Schouten (hkBst) wrote:
>>
http://overlays.gentoo.org/proj/emacs/browser/emacs-overlay/eclass/xemacs-elisp-common.eclass
> 
> You use $* and $@ here which are the same when unquoted. They should
> probably be quoted and that means that all instances would become the four
> characters "$@".
> 
Yeah, that's definitely how to pass thru parameters in function calls.

 The difference between $@ and $*: without double quotes, none at
all: both equal $1 $2  With double quotes, "$@" is "$1" "$2" ...,
while "$*" is "$1c$2c..." (where c is the first character of $IFS). You
almost always want "$@".

So using "$*" maps to one string parameter. If you're calling a shell
function you might not notice the difference (until you use a parameter
with a space) using plain $* since the shell splits parameters to commands
on characters in IFS. The point is, to deal with spaces in strings you need
to use "$@".

#bash is your friend (although some of the ops are way too grumpy ;)


-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: Desktop research project, dead?

[Steve Long]

Davide Italiano wrote:

> Are/were there some people involved in that project?
> It could be useful and pretty to (re)activate this project, considering
> that also gentoo-guis project is active (the two projects are actually
> related). I've some ideas about, I'll write it after you'll tell me (if
> you want) why the project's dead and if we(or you) can indeed (re)activate
> it.
>
How does this relate to the #gentoo-desktop IRC channel?
 
> and finally, are there people that want to work in that project in future?
> 
Well I am definitely interested in better integration (especially after gvim
and then mousepad took over my KDE editor settings.. mimetypes yeah, but
leave my desktop settings alone, please ;) I can help with code (although I
have an aversion to C++, I can debug it if i /have/ to.)


-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: gentoo-commits list lives!

[Steve Long]

Roy Marples wrote:

> On Fri, 2007-09-07 at 17:25 -0700, Alec Warner wrote:
>> People who parse xml with sed make me cry.
>> 
>> grep = also bad.
> 
> Where do you stand on awk | head | cut | tail | xargs chains?
> 
Just awk will do all that, Roy ;)

It's a shame xmlGawk got punted, it was the best project of its ilk imnsho.
That other project[1] was deader than a dodo, vapier ;P XMLstarlet is the
other one we're looking at now: http://xmlstar.sourceforge.net/

[1] http://bugs.gentoo.org/show_bug.cgi?id=175579


-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Re: New eclasses for XEmacs lisp

[Christian Faulhammer]

Hans de Graaff <[EMAIL PROTECTED]>:

> Bring on the comments, improvements, and most importantly: approval to
> put this in the tree.

 Thumbs up from me.  All other flaws I were able to find have already
been spotted.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

http://www.faulhammer.org/>


signature.asc
Description: PGP signature

[gentoo-dev] Re: gentoo-commits list lives!

[Christian Faulhammer]

"Robin H. Johnson" <[EMAIL PROTECTED]>:

> After much toiling, Infra has finally got the commits list active.

 Kudos to you all!

What we now need is the installation of some kind of peer review.  For
example add to the recruitment guide a recommendation to watch the
recruitee one mentored on the commits mailing list.
 All other commits should be reviewed.  Arch work is normally
done in a team and all teams watch each other, so that works quite
good, as keywords are done wrong far too often.
 Any ideas about an efficient way to establish such a process? 

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

http://www.faulhammer.org/>


signature.asc
Description: PGP signature

Re: [gentoo-dev] New eclasses for XEmacs lisp

[Petteri Räty]

Hans de Graaff kirjoitti:
> I'm about to commit two new eclasses to support the compilation,
> configuration, and installation of XEmacs lisp classes. In a desperate
> attempt not to re-invent the wheel the interface and structure of the
> classes has been shamelessly copied from the Emacs lisp classes. 
> 

Would it be possible to have one set of eclasses that handles both
XEmacs and Emacs?

> 
> The eclasses have been in the Emacs overlay for some time now in support
> of the forthcoming app-xemacs/gentoo-syntax package:
> 
> http://overlays.gentoo.org/proj/emacs/browser/emacs-overlay/eclass/xemacs-elisp.eclass
> http://overlays.gentoo.org/proj/emacs/browser/emacs-overlay/eclass/xemacs-elisp-common.eclass

xemacs-elisp-install () { insinto etc should be wrapper in a subshell so
that it can't change the env of the caller.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New eclasses for XEmacs lisp

[Hans de Graaff]

On Sat, 2007-09-08 at 17:33 +0300, Petteri Räty wrote:

> Would it be possible to have one set of eclasses that handles both
> XEmacs and Emacs?

Possible, yes, but I don't think it is practical. Even though the
general steps to compile and install elisp are the same for GNU Emacs
and XEmacs, there are also a lot of finicky little implementation
details that are different. There would not be a lot of joined code, I
think. 

> xemacs-elisp-install () { insinto etc should be wrapper in a subshell so
> that it can't change the env of the caller.

While looking for some examples I found that not many eclasses currently
do this, so perhaps this is good advice for others as well? Petteri's
own java-utils-2.eclass does support this, obviously, and so will the
xemacs eclass.

Kind regards,

Hans


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: gentoo-commits list lives!

[Mike Frysinger]

On Saturday 08 September 2007, Steve Long wrote:
> Roy Marples wrote:
> > On Fri, 2007-09-07 at 17:25 -0700, Alec Warner wrote:
> >> People who parse xml with sed make me cry.
> >>
> >> grep = also bad.
> >
> > Where do you stand on awk | head | cut | tail | xargs chains?
>
> Just awk will do all that, Roy ;)
>
> It's a shame xmlGawk got punted, it was the best project of its ilk imnsho.
> That other project[1] was deader than a dodo, vapier ;P

that "other project" was started by the xmlGawk author as the replacement of 
xmlGawk ... i know because we talked about it via e-mail :P

i'm not going to make a core package dependent on an external patchset again 
let alone one that requires linking against cruft in /usr ... it was a pima
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] New eclasses for XEmacs lisp

[Petteri Räty]

Hans de Graaff kirjoitti:
> On Sat, 2007-09-08 at 17:33 +0300, Petteri Räty wrote:
> 
>> Would it be possible to have one set of eclasses that handles both
>> XEmacs and Emacs?
> 
> Possible, yes, but I don't think it is practical. Even though the
> general steps to compile and install elisp are the same for GNU Emacs
> and XEmacs, there are also a lot of finicky little implementation
> details that are different. There would not be a lot of joined code, I
> think. 
> 
>> xemacs-elisp-install () { insinto etc should be wrapper in a subshell so
>> that it can't change the env of the caller.
> 
> While looking for some examples I found that not many eclasses currently
> do this, so perhaps this is good advice for others as well? Petteri's
> own java-utils-2.eclass does support this, obviously, and so will the
> xemacs eclass.
> 
> Kind regards,
> 
> Hans

Yeah you can usually get away with it.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: gentoo-commits list lives!

[Alec Warner]

On 9/8/07, Christian Faulhammer <[EMAIL PROTECTED]> wrote:
> "Robin H. Johnson" <[EMAIL PROTECTED]>:
>
> > After much toiling, Infra has finally got the commits list active.
>
>  Kudos to you all!
>
> What we now need is the installation of some kind of peer review.  For
> example add to the recruitment guide a recommendation to watch the
> recruitee one mentored on the commits mailing list.
>  All other commits should be reviewed.  Arch work is normally
> done in a team and all teams watch each other, so that works quite
> good, as keywords are done wrong far too often.
>  Any ideas about an efficient way to establish such a process?
>

Can we see how often the list gets used first?  Maybe things will
improve in the next bit of time and we don't need any extra formal
process.  I have no problem adding to the guide that mentors should
watch mentees commits (that is technically already required even
though many do not).  I'd rather have a bunch of people pointing out
problems on commits in an ad-hoc manner than have 'All Commits
Reviewed(TM)' ;)

-Alec
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: gentoo-commits list lives!

[Mike Frysinger]

On Saturday 08 September 2007, Alec Warner wrote:
> On 9/8/07, Christian Faulhammer <[EMAIL PROTECTED]> wrote:
> > "Robin H. Johnson" <[EMAIL PROTECTED]>:
> > > After much toiling, Infra has finally got the commits list active.
> >
> >  Kudos to you all!
> >
> > What we now need is the installation of some kind of peer review.  For
> > example add to the recruitment guide a recommendation to watch the
> > recruitee one mentored on the commits mailing list.
> >  All other commits should be reviewed.  Arch work is normally
> > done in a team and all teams watch each other, so that works quite
> > good, as keywords are done wrong far too often.
> >  Any ideas about an efficient way to establish such a process?
>
> Can we see how often the list gets used first?  Maybe things will
> improve in the next bit of time and we don't need any extra formal
> process.  I have no problem adding to the guide that mentors should
> watch mentees commits (that is technically already required even
> though many do not).  I'd rather have a bunch of people pointing out
> problems on commits in an ad-hoc manner than have 'All Commits
> Reviewed(TM)' ;)

buy Alex a beer
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: gentoo-commits list lives!

[Mike Frysinger]

On Saturday 08 September 2007, Mike Frysinger wrote:
> On Saturday 08 September 2007, Alec Warner wrote:
> > On 9/8/07, Christian Faulhammer <[EMAIL PROTECTED]> wrote:
> > > "Robin H. Johnson" <[EMAIL PROTECTED]>:
> > > > After much toiling, Infra has finally got the commits list active.
> > >
> > >  Kudos to you all!
> > >
> > > What we now need is the installation of some kind of peer review.  For
> > > example add to the recruitment guide a recommendation to watch the
> > > recruitee one mentored on the commits mailing list.
> > >  All other commits should be reviewed.  Arch work is normally
> > > done in a team and all teams watch each other, so that works quite
> > > good, as keywords are done wrong far too often.
> > >  Any ideas about an efficient way to establish such a process?
> >
> > Can we see how often the list gets used first?  Maybe things will
> > improve in the next bit of time and we don't need any extra formal
> > process.  I have no problem adding to the guide that mentors should
> > watch mentees commits (that is technically already required even
> > though many do not).  I'd rather have a bunch of people pointing out
> > problems on commits in an ad-hoc manner than have 'All Commits
> > Reviewed(TM)' ;)
>
> buy Alex a beer

and then buy Alec one :x
-mike


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] USE flag how are they supposed to work?

[Steen Eugen Poulsen]

I'm trying to write a Replicator for /etc/portage and that leads me to 
work with USE flags, trying to design the replication of them among 
similar systems, but I can't find the golden set of rules for how best 
to apply USE flags.


There seem to be a global/local USE flag system, but many so called 
global flags has duplicated description marking them as local flags, or 
they enable unneeded optional support.


Lets take one of the big ones python. This use flag enables optional 
python support in many packages, I don't see my system ever using the 
python support in most of these. Seems like it really should be a local 
pr. packet flag for most, a pythonapi flag perhaps.


There is also a few cases where package X requires package Y to be 
compiled with an USE flag, but no testing is being done in the ebuild 
for it and the compilation fails. Example gnome-system-tools requires 
libxml2 to be compiled with python support.


Then there is flags like alsa, it's marked as a global flag and then 
virtualbox also has it marked as a local flag. I personally think 
virtualbox is somewhat right in saying it's a local flag, but perhaps it 
would be better if the flag didn't have a double meaning.


As I see it, Gentoo's USE flag system is one of it's greatest strength, 
but at the moment seems like there is missing some overall design for 
how to implement USE flags, making it a lot harder to use USE flags, as 
there is no clear definition of global or local flags.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [gentoo-dev] USE flag how are they supposed to work?

[Alistair Bush]

Firstly...

>From http://devmanual.gentoo.org/general-concepts/use-flags/index.html

"Local and Global USE Flags

USE flags are categorised as either local or global. A global USE flag
must satisfy several criteria:

* It is used by many different packages.
* It has a general non-specific purpose.

The second point is important. If the effect of the thing USE flag upon
pkg-one is substantially different from the effect it has upon pkg-two,
then thing is not a suitable candidate for being made a global flag. In
particular, note that if client and server USE flags are ever
introduced, they can not be global USE flags for this reason.

Before introducing a new global USE flag, it must be discussed on the
gentoo-dev mailing list."


Steen Eugen Poulsen wrote:
> I'm trying to write a Replicator for /etc/portage and that leads me to
> work with USE flags, trying to design the replication of them among
> similar systems, but I can't find the golden set of rules for how best
> to apply USE flags.
> 
> There seem to be a global/local USE flag system, but many so called
> global flags has duplicated description marking them as local flags, or
> they enable unneeded optional support.

Unneeded by whom? As for the duplicate local USE flags,  They are most
probably redundant.

> 
> Lets take one of the big ones python. This use flag enables optional
> python support in many packages, I don't see my system ever using the
> python support in most of these. Seems like it really should be a local
> pr. packet flag for most, a pythonapi flag perhaps.

See above.  Also note that you are not enabling support for pythonapi,
you are enabling support for python.  Would you enable support for
linuxheaders when you are without a linux kernel.

> 
> There is also a few cases where package X requires package Y to be
> compiled with an USE flag, but no testing is being done in the ebuild
> for it and the compilation fails. Example gnome-system-tools requires
> libxml2 to be compiled with python support.

If that is the case, then I would suggest you search bugzilla and then
file a bug.

> 
> Then there is flags like alsa, it's marked as a global flag and then
> virtualbox also has it marked as a local flag. I personally think
> virtualbox is somewhat right in saying it's a local flag, but perhaps it
> would be better if the flag didn't have a double meaning.

See above.  I can only assume that virtualbox doesn't need to have a
local alsa use flag.

> 
> As I see it, Gentoo's USE flag system is one of it's greatest strength,
> but at the moment seems like there is missing some overall design for
> how to implement USE flags, making it a lot harder to use USE flags, as
> there is no clear definition of global or local flags.
> 
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] USE flag how are they supposed to work?

[Steen Eugen Poulsen]

Alistair Bush skrev:

* It is used by many different packages.


yes, this is the rubber rule. It pretty much allows any use flag to be 
promoted to global when it has XX packages with it, the confusion comes 
because the number of package using a flag is no indication whatever you 
should set the flag globally or pr. package.


Seem to me that the word global is used in the portage tree to mean one 
thing and then when we edit make.conf and /etc/portage we get another 
global/local meaning.



* It has a general non-specific purpose.


Shouldn't that be "It has a general specific purpose".


The second point is important. If the effect of the thing USE flag upon
pkg-one is substantially different from the effect it has upon pkg-two,
then thing is not a suitable candidate for being made a global flag. In
particular, note that if client and server USE flags are ever
introduced, they can not be global USE flags for this reason.


Again you seem to talk about specific purpose, but the quoted text say 
non-specific, excuse me for being confused.



I'm trying to write a Replicator for /etc/portage and that leads me to
work with USE flags, trying to design the replication of them among
similar systems, but I can't find the golden set of rules for how best
to apply USE flags.

There seem to be a global/local USE flag system, but many so called
global flags has duplicated description marking them as local flags, or
they enable unneeded optional support.


Unneeded by whom?


The package in order for it to work. You don't need Java, Python, Perl, 
Lua, whatever scripting support in most packages. For most of the ones 
I've seen, I have to go write a Java/Python/Perl/Lua program, before I 
actually need it.


> As for the duplicate local USE flags,  They are most

probably redundant.





See above.  Also note that you are not enabling support for pythonapi,
you are enabling support for python.  Would you enable support for
linuxheaders when you are without a linux kernel.


I don't understand what support for python is.


If that is the case, then I would suggest you search bugzilla and then
file a bug.


Off course, but thats hardly the point of mentioning here, it was for 
bringing general attention to a ebuild mistake, that happens again and 
again.



See above.  I can only assume that virtualbox doesn't need to have a
local alsa use flag.


alsa: Adds support for media-labs/alsa-lib (Advanced Linux Sound 
Architecture)


Local Flag: Enable support for ALSA instead of OSS 
(app-emulation/virtualbox)


In box's case it's an "alsa not oss" flag, the global flag tend to be 
"also alsa", though I wont put my head on the block claiming it's always 
that meaning it has.



As I see it, Gentoo's USE flag system is one of it's greatest strength,
but at the moment seems like there is missing some overall design for
how to implement USE flags, making it a lot harder to use USE flags, as
there is no clear definition of global or local flags.


The words is given different meaning depending on whatever I'm looking 
at the portage tree or working on configuring emerge. The portage trees 
global flag, is no indication whatever I should put the flag in USE="" 
in make.conf, in many cases a portage tree global flag is more an 
indication that I should use it locally pr. package.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [gentoo-dev] Re: gentoo-commits list lives!

[Donnie Berkholz]

On 17:52 Sat 08 Sep , Mike Frysinger wrote:
> On Saturday 08 September 2007, Mike Frysinger wrote:
> > buy Alex a beer
> 
> and then buy Alec one :x

Way to review!

Donnie
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] USE flag how are they supposed to work?

[Alistair Bush]

Ok, so I think I understand where you are coming from...

Firstly,  USE flags are not meant to have a specific purpose. Enabling
python support is non-specific as it doesn't describe how it is enabled
or what python support actually is.

Lets compare 2 packages to demonstrate...

subversion has a python use flag,  this flag will install a subversion
api for python.  so within python you an interact with subversion.

as another example.

vim also has a python use flag.  this flag enables the ability to
execute python commands from within vim.

_But_ it is important to note that nowhere does the python use flag
attempt to distinguish between the 2 types of support. This is where I
believe you are getting stuck.

The reason for having non-specific use flags is otherwise we would have
hundreds of duplicate local use flags whose descriptions differ only
slightly. We are not attempting to document all the functionality of
each package.  It is up to you to discover what packages you want to
have python support.

> 
> The words is given different meaning depending on whatever I'm looking
> at the portage tree or working on configuring emerge. The portage trees
> global flag, is no indication whatever I should put the flag in USE=""
> in make.conf, in many cases a portage tree global flag is more an
> indication that I should use it locally pr. package.
> 

well I would only agree with that if you correlate the global status of
a USE flag to the number of packages that use it and you are wanting to
only enable the bare minimum use flags for the pacakges that you require.

But anyway, in summary

If you want to find out what a packages USE flag does,  it is better to
read the upstream documentation.
-- 
[EMAIL PROTECTED] mailing list

[gentoo-dev] Managing users and groups

[Daniel Pielmeier]

Hi,

I have recently checked the contents of /etc/{group,passwd,shadow} and
found that there are users and groups which are not needed anymore
because the packages which need them have also been removed. I have
deleted some of them which are unnecessary with userdel and groupdel.

I have experienced that some ebuilds use enewuser and enewgroup to
create users and groups which are needed. Some print a elog notice in
pkg_postinst to inform the user to create them manually.

I think it would be a good idea to either leave it to the user (inform
them via pkg_postinst) to create the groups and users or better create
the needed groups and users in pkg_preinst and remove them at uninstall
in pkg_postrm (edeluser end edelgroup may have to be implemented to
achieve this). In this case the configuration files did not get
cluttered with unneeded entries. To be sure that no group or user is
removed which is still needed some kind of configuration file could be
used to prevent the deletion of shared groups/users. With contents like
group/user X needed by ebuild Y.

While writing this i have found GLEP-27. What is the current status
concerning this?

Regards,

Daniel


-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] USE flag how are they supposed to work?

[Vlastimil Babka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steen Eugen Poulsen wrote:
> Alistair Bush skrev:
>> * It is used by many different packages.
> 
> yes, this is the rubber rule. It pretty much allows any use flag to be
> promoted to global when it has XX packages with it, the confusion comes
> because the number of package using a flag is no indication whatever you
> should set the flag globally or pr. package.

Right, the only indication is if you want the functionality of the flag
globally or per package :)

> Seem to me that the word global is used in the portage tree to mean one
> thing and then when we edit make.conf and /etc/portage we get another
> global/local meaning.

That's right. Global/local use flag descriptions have no relation to
global/local setting via make.conf/package.use. As a non-dev you might
just ignore the first classification.

>>> I'm trying to write a Replicator for /etc/portage and that leads me to
>>> work with USE flags, trying to design the replication of them among
>>> similar systems, but I can't find the golden set of rules for how best
>>> to apply USE flags.
>>>
>>> There seem to be a global/local USE flag system, but many so called
>>> global flags has duplicated description marking them as local flags, or
>>> they enable unneeded optional support.
>>
>> Unneeded by whom?
> 
> The package in order for it to work. You don't need Java, Python, Perl,
> Lua, whatever scripting support in most packages. For most of the ones
> I've seen, I have to go write a Java/Python/Perl/Lua program, before I
> actually need it.

Well then don't enable those flags globally (that they are "global"
doesn't mean you have to), enable them only for packages which have
depending packages requiring them. Which you currently find out only by
errors (graceful die messages, except bugs like the one you mentioned :)
until there are finally use deps.

> The words is given different meaning depending on whatever I'm looking
> at the portage tree or working on configuring emerge. The portage trees
> global flag, is no indication whatever I should put the flag in USE=""
> in make.conf, in many cases a portage tree global flag is more an
> indication that I should use it locally pr. package.

Right, as mentioned above, there is no relation, although the
"global/local" notion may suggest it. One might even ask why we have
separate use.desc and use.local.desc then. Good question :) IMHO it's
mostly administrative thing so people don't add many new global flags
without consultation, but still can quickly add local flags just for
their package.

- --
Vlastimil Babka (Caster)
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG42AktbrAj05h3oQRAkfjAJ4zdWFWzLAswbDTq/hvszouoI1gYgCfV/j4
w0aFRUzi5RbOJMAs9M7O3no=
=7Y8j
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Managing users and groups

[Mike Frysinger]

On Saturday 08 September 2007, Daniel Pielmeier wrote:
> While writing this i have found GLEP-27. What is the current status
> concerning this?

presumably you'd search bugzilla and come across 53269
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Managing users and groups

[Daniel Pielmeier]

Mike Frysinger schrieb:
> On Saturday 08 September 2007, Daniel Pielmeier wrote:
>> While writing this i have found GLEP-27. What is the current status
>> concerning this?
> 
> presumably you'd search bugzilla and come across 53269
> -mike

I have searched bugzilla, but not for the specific glep. This does not
look like a big issue as there is no progress in this bug at all (sorry
i can not help out there, i am just a user not a programmer as i have
mentioned before).

Why not using something similar to Comment 16 in Bug 8634

USERDEPEND="someuser"
GROUPDEPEND="somegroup"

A group/user is created when no other ebuild has the dependency and is
removed when the last ebuild has been removed which needs it?

Okay the approach in the glep look much cleaner, but this is maybe more
easier to implement!
-- 
[EMAIL PROTECTED] mailing list