Re: [gentoo-dev] Handling Launchpad SRC_URI

2009-01-25 Thread Marius Mauch
On Sat, 24 Jan 2009 23:38:32 -0800
Josh Saddler nightmo...@gentoo.org wrote:

 Right now, there's no canonical (heh) way of handling SRC_URI for
 projects that have their files at launchpad.net. We need a standard
 way of handling Launchpad SRC_URIs, similar to what we do with
 mirror://sourceforge/ SRC_URIs.
 
 1. Some packages use the launchpadlibrarian.net download redirect,
 which results in a non-helpful server-generated number:
 
 (gnome-catalog)
 SRC_URI=http://launchpadlibrarian.net/11326737/${PN}_${PV}.orig.tar.gz
 
 2. Some hack up interesting MY_P stuff:
 
 (gnome-do-plugins)
 MY_PN=do-plugins
 PVC=$(get_version_component_range 1-2)
 PVC2=$(get_version_component_range 1-3)
 SRC_URI=https://launchpad.net/${MY_PN}/${PVC}/${PVC2}/+download/${P}.tar.gz;
 
 (avant-window-navigator-extras)
 MY_P=awn-extras-applets-${PV}
 SRC_URI=https://launchpad.net/awn-extras/${PV%.*}/${PV}/+download/${MY_P}.tar.gz;
 
 The AWN-extras ebuild is the closest to the right way of doing it, I
 think.
 
 So can we agree on a standard way of treating Launchpad SRC_URIs and
 get the handler support into Portage?

The best way would be to convince upstream to offer a simpler URL
scheme. Adding a special handler in the PM would be the worst option
(also there is no such thing atm, mirror://sourceforge/ doesn't do
anything special). The easiest option would probably be a little helper
function in eutils to generate the correct URL, if you *really* need to
simplify things (in your examples, the only sligthly odd thing are the
version parts in the URL, the MY_P stuff would be needed anyway from
what I can see).

Marius



Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs

2009-01-17 Thread Marius Mauch
On Sat, 17 Jan 2009 14:09:49 +0100
Thomas Sachau to...@gentoo.org wrote:

 Hi,
 
 as specified in the PMS spec [1] and stated in #gentoo-portage,
 RDEPEND will be set to DEPEND, if it is not defined in the ebuild
 itself. But devmanual [2] and developer handbook [3] both state, you
 have do explicitly set RDEPEND because it may be removed in the
 future. Since package manager have to follow the PMS spec, i would
 suggest to change those docs [2][3] and let them follow the PMS spec.
 
 Any problems, suggestions or anything else about this?

It's strongly recommended to set both explicitly as the behavior could
change in future EAPI versions, and to ensure that you actually think
about which deps are build deps and which are runtime deps.
Also there is nothing wrong with policies being stricter than the
underlying spec.

Marius



Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs

2009-01-17 Thread Marius Mauch
On Sat, 17 Jan 2009 16:41:25 +0100
Thomas Sachau to...@gentoo.org wrote:

 Marius Mauch schrieb:
  It's strongly recommended to set both explicitly as the behavior
  could change in future EAPI versions, and to ensure that you
  actually think about which deps are build deps and which are
  runtime deps. Also there is nothing wrong with policies being
  stricter than the underlying spec.
 
 If i want to use some future EAPI (give me some reasons, why this
 should be changed there by default), i should think about it.

If nothing else, dropping the implicit assignment would remove one
special case to handle in the PM (and I hope that everyone agrees that
special cases should generally be avoided). In the past there have also
been some issues due to the interaction between the implicit setting of
RDEPEND and eclasses (long fixed, but shows that there is a bit more
involved than might obvious).

 But most ebuilds will stay with the default. I do think about
 runtime deps and build deps. 

If you do that's good, but that doesn't mean everyone else does.
Consider looking at an ebuild for a package you're not familiar with
that doesn't set RDEPEND. Could mean that the author was just too lazy
to add a RDEPEND=$DEPEND statement and that all deps are needed for
build and runtime, or that he completely forgot to think about runtime
deps. There is no way to know (without asking him) if the implicit
RDEPEND is actually intended or not.

 In my eyes, this is similar to src_unpack and src_compile. They
 have defaults, noone specifies the defaults, even if they are changed
 in some EAPI.

Sure, but the key difference is that the defaults for those are fixed.
You would have a point if the default src_compile would vary based on
what other phase functions the ebuild defines, but that's not the case.

Marius



Re: [gentoo-dev] reorganization of /var/lib gentoo-related files

2008-12-31 Thread Marius Mauch
On Wed, 31 Dec 2008 10:55:39 +0100
Fabio Rossi ross...@inwind.it wrote:

 On Wednesday 31 December 2008, Marius Mauch wrote:
 
  Any reason for that? Aesthetics aren't a very compelling argument
  IMO, and the FHS also seems to favor the current layout (in my
  interpretation at least, as we're not really talking about
  inter-related applications in technical terms).
 
 I agree with you, there is no technical relation, i.e. those
 applications are stand-alone, but I also think that the link is
 their role, they are all used for administrative purposes *inside* a
 Gentoo distribution (inside might be the right keyword to justify a
 little deviation from the FHS).

The same could be said about /var/lib/init.d, /var/lib/dhcp,
/var/lib/iptables or several other packages that aren't hosted by
Gentoo. In the other direction, if the packages are eventually used on
other distributions/systems, should they then use another path?

Mind that this only addresses the FHS part of my mail, you haven't
really answered my question: What's the benefit of changing things?
Change for the sake of change is rarely a good idea (unless you work in
PR/marketing ;)

 In the opposite direction, in according to your opinion, I don't see
 a reason to have /var/lib/gentoo/news instead of something
 like /var/lib/gentoo-news.

Right. But retroactively changing GLEP 42 and all affected packages is
a bit much just to avoid a generic gentoo directory.

Marius



Re: [gentoo-dev] reorganization of /var/lib gentoo-related files

2008-12-31 Thread Marius Mauch
On Wed, 31 Dec 2008 12:00:35 +0100
Fabio Rossi ross...@inwind.it wrote:

 On Wednesday 31 December 2008, Marius Mauch wrote:
 
  The same could be said about /var/lib/init.d, /var/lib/dhcp,
  /var/lib/iptables or several other packages that aren't hosted by
  Gentoo. In the other direction, if the packages are eventually used
  on other distributions/systems, should they then use another path?
 
 The path could be configured of course but, again, I see a few
 chances of having this tools outside gentoo, the proposal is based
 also on this idea.
 
  Mind that this only addresses the FHS part of my mail, you haven't
  really answered my question: What's the benefit of changing things?
  Change for the sake of change is rarely a good idea (unless you
  work in PR/marketing ;)
 
 The main benefit is a cleaner filesystem, I don't know your opinion
 but I hate to see sparse files around the tree and waste time in
 discovering their source :-) Moreover IMHO it gives me the impression
 of a better design.

Ok, so in other word aesthetics.
 
   In the opposite direction, in according to your opinion, I don't
   see a reason to have /var/lib/gentoo/news instead of something
   like /var/lib/gentoo-news.
 
  Right. But retroactively changing GLEP 42 and all affected packages
  is a bit much just to avoid a generic gentoo directory.
 
 So we can exploit this condition to collect all gentoo related files
 inside this dir ;-)

Well, the impact is about the same wether you want to change one or the
other (btw, what about other admin tools on Gentoo, e.g.
paludis/pkgcore, by your definition they'd also have to go
into /var/lib/gentoo, right?), and that impact is non-trivial (it's not
so much the code changes themselves but the inevitable transition
problems).
Compared to the IMO very questionable benefit of a cleaner
filesystem (by hiding files users usually don't see anyway one level
deeper in the tree structure) that more or less goes against the FHS,
that doesn't sound like a good deal to me.

Marius



Re: [gentoo-dev] Re: reorganization of /var/lib gentoo-related files

2008-12-31 Thread Marius Mauch
On Wed, 31 Dec 2008 16:15:54 +0100
Fabio Rossi ross...@inwind.it wrote:

 On Wednesday 31 December 2008, Jeremy Olexa wrote:
  Fabio Rossi wrote:
   On Wednesday 31 December 2008, Duncan wrote:
   Except that... in theory, some or all of those apps could
   technically be used on/for other distributions and platforms as
   well.
  
   Yes, this is the theory but I think they'll be never ported to
   other distributions.
 
  sabayon doesn't use these apps? How about gentoo based livecds,
  etc. ?
 
 Ok, you're right. But I wasn't speaking about gentoo-based
 distributions...

Well, a few people have actually been using portage on rpm-based distros
as well in the past. Granted that was usually quite a hack and required
a few modifications, but it might not be as impossible as you think.



Re: [gentoo-dev] reorganization of /var/lib gentoo-related files

2008-12-30 Thread Marius Mauch
On Wed, 31 Dec 2008 01:12:23 +0100
Fabio Rossi ross...@inwind.it wrote:

 I'm proposing to reorganize the files related to Gentoo
 inside /var/lib. Currently we have this situation (at least on my
 system):
 
 /var/lib/eselect
 /var/lib/gentoo/enews
 /var/lib/herdstat/
 /var/lib/module-rebuild
 /var/lib/portage
 
 The main dir should be something like /var/lib/gentoo, so I'd see all 
 gentoo-related files as
 
 /var/lib/gentoo/eselect
 /var/lib/gentoo/enews
 /var/lib/gentoo/herdstat/
 /var/lib/gentoo/module-rebuild
 /var/lib/gentoo/portage
 
 What do you think about?

Any reason for that? Aesthetics aren't a very compelling argument IMO,
and the FHS also seems to favor the current layout (in my
interpretation at least, as we're not really talking about
inter-related applications in technical terms).

Marius



Re: [gentoo-dev] [RFC] Should unicode be allowed in ebuild metadata variables?

2008-12-29 Thread Marius Mauch
On Tue, 30 Dec 2008 09:37:24 +0530
Nirbheek Chauhan nirbheek.chau...@gmail.com wrote:

 On Tue, Dec 30, 2008 at 8:27 AM, Ben de Groot yng...@gentoo.org
 wrote:
  Zac Medico wrote:
  Nevermind, apparently GLEP 31 already requires ASCII anyway:
 
http://www.gentoo.org/proj/en/glep/glep-0031.html
 
  The way I read that GLEP is that in ChangeLog and metadata.xml
  we should accept the full range of UTF-8.
 
 I read that as contents of portage tree should be in UTF-8, file
 paths should be in ASCII
 
 It is proposed that UTF-8 ([1]) is used for encoding ChangeLog and
 metadata.xml files inside the portage tree.
 
 [...]it is proposed that UTF-8 is used as the official encoding for
 ebuild and eclass files
 
 Patches must clearly be in the same character set as the file they
 are patching.
 
 Characters outside the ASCII 0..127 range cannot safely be used for
 file or directory names
 
 It is also worth mentioning that Python 3K uses UTF-8 as the default
 encoding for it's files rather than ASCII as Python 2.X did. Why
 should *we* go backwards? :p

And none of that is relevant to Zacs original question, which is
covered by the following section of the GLEP:
However, developers should be warned that any code which is parsed by
bash (in other words, non-comments), and any output which is echoed to
the screen (for example, einfo messages) or given to portage (for
example any of the standard global variables) must not use anything
outside the regular ASCII 0..127 range for compatibility purposes.

Marius



Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db

2008-12-09 Thread Marius Mauch
On Tue, 9 Dec 2008 11:21:24 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:

 On 01:44 Tue 09 Dec , Federico Ferri wrote:
  today I hit this annoyance, because my laptop hung in the middle of
  an 'emerge -e @world' (checking that my world set compiles with
  gcc-4.3... stopped at ~ 300 of 700  :S )
  
  I was looking for an entry in /var/db/pkg/cat/pkg/ that could have
  told me the compiler used to build the package, but couldn't find
  any. indeed it would be a fairly useful feature to have, both for
  testing purposes, and for user's everyday maintenance.
  
  please criticize this with anything constructive you can think of.
 
 As I mentioned on IRC, I think this isn't a very general use case
 (given the existence of --resume, --keep-going, etc.) so code to
 accomplish it would be better put into a custom portage bashrc than
 into portage proper.
 
 ISTR that you could no longer resume for some reason. Perhaps what
 you really wanted was a way to save the resume list across multiple
 emerges?

For the given use case it might also be an option to use the AgeSet
handler in portage-2.2, e.g.
   emerge -p '@old{class=dbapi.AgeSet,age=2}'
to list all installed packages that have been installed more than two
days ago.

Marius



Re: [gentoo-portage-dev] Re: equery refactorization

2008-12-06 Thread Marius Mauch
On Sun, 7 Dec 2008 12:44:25 +0900
Douglas Anderson [EMAIL PROTECTED] wrote:

 I also thought about renaming the list(l) option as search,
 because if you look at the help output, almost every module lists
 something. equery's list is actually a search, I don't see why we
 shouldn't name it that. I think maybe list was used because there were
 already two s options, stats and size. Stats is not implemented so
 I'm taking it out of help for now. Size can use the short z, becaues
 that's quite unique. That would free up s for search and it would be
 a whole lot clearer.
 
 Yes? No?

No. search (if used at all) should be reserved for a more
comprehensive search framework (though IMO a separate tool for that is
more appropriate), not just a simple name match. list makes sense if
you consider that the pkgspec argument is optional, and one of the main
tasks of it is to simply list the packages in the given repository
(that's why vardb is also the default for it) without further filtering.

Also one of the main goals of equery (according to karltk, the original
author) was to have a stable user interface, compared to the deprecated
qpkg and etcat scripts. And while the equery interface isn't exactly
the best I've seen it has been stable, so you might want to think twice
before renaming options and eventually pissing off users or breaking
third-party scripts.

Marius



Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-12-02 Thread Marius Mauch
On Wed, 03 Dec 2008 02:05:31 +0100
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote:

 metadata.xml already contains data that eix and other software should
 be able to search in (like longdescriptions), and having each package
 in kde-base report http://www.kde.org/ as its homepage is kinda
 pointless if you think about search, since that's not data, it's
 noise.

So you're saying if I'm interested in a url to look for information
about kalarm, I should search for it in metadata.xml of random kde
packages? Sorry, but that doesn't make any sense to me.

While I'm not necessarily against your primary goal here, your
argumentation is very subjective to say the least (e.g. just because
you find xml easier to read/parse than ebuilds doesn't mean the same
holds true for everyone else, ignoring the whole cache issue). It
feels a bit like you're looking for problems to justify your solution
rather than the other way round.

Marius



Re: [gentoo-dev] Re: debug/release builds extensions/clarification proposal

2008-12-02 Thread Marius Mauch
On Wed, 3 Dec 2008 08:19:18 +0100
Maciej Mrozowski [EMAIL PROTECTED] wrote:

 No, and I'm afraid I cannot provide any single evidence that users
 actually need features like:
 - per package cflags/ldflags/features
 - per category use flags, accept_keywords, cflags
 - or tag clouds instead of hard coded categories
 - user-defined packages sets (official)
 - multiple portage configurations support to ease building binaries
 for several targets on a same host
 - dynamic libraries tracking for safe package upgrade or removal
 - real backwards dependencies
 - maybe git driven Portage
 - automatic kernel modules rebuilding
 - mysql split ebuilds

Assuming that's a list of feature requests, you know that half of them
are already available, right? (not counting the non-feature in there)

Marius




Re: [gentoo-dev] debug/release builds extensions/clarification proposal

2008-12-01 Thread Marius Mauch
On Mon, 01 Dec 2008 11:39:35 +0300
Peter Volkov [EMAIL PROTECTED] wrote:

 This leads me to different conclusion. I was thinking about new
 portage feature: emerge --info pkg . So to make portage show not
 only global information but per-package either. In many cases this
 will simplify analyzing of the problem.

That feature already exists (for installed packages at least).

Marius



Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-12-01 Thread Marius Mauch
On Mon, 01 Dec 2008 15:35:32 -0700
Joe Peterson [EMAIL PROTECTED] wrote:

 My intention with the RFC was to see if the concept has any worth and
 to kick it around a bit.  I do not really see this as a deficiency in
 Gentoo's technology (which I have a feeling is how many here have
 interpreted it), but simply something that, if done correctly, could
 be useful.

Maybe provide a real example to demonstrate the difference between the
current solutions and what you're looking for, because I still don't
understand what you're after (using all the different terms, logs,
notes, docs, plain emerge log, ... without further explanation doesn't
help much to clear things up).

Marius



[gentoo-dev] Time to say goodbye

2008-11-30 Thread Marius Mauch
So, time has come for me to realize that my time with Gentoo is over. I
haven't actually been doing much Gentoo work over the last months due
to personal reasons (nothing Gentoo related), and I don't see that
situation changing in the near future. In fact I've already reassigned
or dropped most of my responsibilites in Gentoo a while ago, so there
are just a few pet projects left to give away:
- my gentoo-stats project (in the portage/gentoo-stats svn repository).
I know quite a few people are interested in the idea of collecting
various statistic data from gentoo user systems, and I'd encourage
everyone who wants to implement such a system to at least look at it (I
may have even finished it if I wouldn't have wasted my time focusing on
the wrong problems). There is quite a bit of documentation also that
should help to get you started
- a graphical security update tool (see bug #190397)

So if anyone wants to adopt those, complete or just parts, just take
them. As for Portage, Zac has practically already filled my role.

So I guess that wraps it up. It's been a nice ride most of the time,
but now it's time for me to leave the Gentoo train.

Marius




Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-11-30 Thread Marius Mauch
On Sun, 30 Nov 2008 09:25:51 -0700
Joe Peterson [EMAIL PROTECTED] wrote:

 Bottom line here is that there is extremely valuable and critical info
 in our emerge output.  In a way, these messages are like
 Gentoo-specific READMEs (or release notes and/or install
 instructions).  However, it is not saved for a user to use as a
 resource later (well, except that it is partially saved in the master
 emerge.log, but that's not quite useful enough).  There is no
 official place to go to look for Gentoo
 instructions; /usr/share/doc is one logical place, but it only
 contains files actually installed, not the notes output by emerge
 (and these are usually upstream-supplied, not Gentoo).
 
 I propose that, upon merging a package, we save the emerge messages in
 either: 1) a package-specific file that resides somewhere official
 or
 2) in the portage DB, so that the messages can be re-read via a
 portage utility.  In the latter case, either a new option to equery
 or a new q command (e.g. equery readme pkg or qreadme pkg
 could retrieve the text).

By default, messages generated by elog, ewarn and eerror are recorded
in /var/log/portage/elog/summary.log (emerge.log is just a
transaction log, so best to ignore it here). einfo isn't recorded on
purpose as it isn't intended for important information (that's the
purpose of elog). There are some tools available to simplify reading
these messages, and there several additional/alternative delivery
modules available (by mail, IM or in package specific files),
customizable via POTAGE_ELOG_* variables. Don't know if you just
haven't been aware of this, or if you're asking for something
completely different.

Marius



[gentoo-portage-dev] Time to say goodbye

2008-11-30 Thread Marius Mauch
So, time has come for me to realize that my time with Gentoo is over. I
haven't actually been doing much Gentoo work over the last months due
to personal reasons (nothing Gentoo related), and I don't see that
situation changing in the near future. In fact I've already reassigned
or dropped most of my responsibilites in Gentoo a while ago, so there
are just a few pet projects left to give away:
- my gentoo-stats project (in the portage/gentoo-stats svn repository).
I know quite a few people are interested in the idea of collecting
various statistic data from gentoo user systems, and I'd encourage
everyone who wants to implement such a system to at least look at it (I
may have even finished it if I wouldn't have wasted my time focusing on
the wrong problems). There is quite a bit of documentation also that
should help to get you started
- a graphical security update tool (see bug #190397)

So if anyone wants to adopt those, complete or just parts, just take
them. As for Portage, Zac has practically already filled my role.

So I guess that wraps it up. It's been a nice ride most of the time,
but now it's time for me to leave the Gentoo train.

Marius




Re: [gentoo-portage-dev] search functionality in emerge

2008-11-23 Thread Marius Mauch
On Sun, 23 Nov 2008 07:17:40 -0500
Emma Strubell [EMAIL PROTECTED] wrote:

 However, I've started looking at the code, and I must admit I'm pretty
 overwhelmed! I don't know where to start. I was wondering if anyone
 on here could give me a quick overview of how the search function
 currently works, an idea as to what could be modified or implemented
 in order to improve the running time of this code, or any tip really
 as to where I should start or what I should start looking at. I'd
 really appreciate any help or advice!!

Well, it depends how much effort you want to put into this. The current
interface doesn't actually provide a search interface, but merely
functions to
1) list all package names - dbapi.cp_all()
2) list all package names and versions - dbapi.cpv_all()
3) list all versions for a given package name - dbapi.cp_list()
4) read metadata (like DESCRIPTION) for a given package name and
version - dbapi.aux_get()

One of the main performance problems of --search is that there is no
persistent cache for functions 1, 2 and 3, so if you're just
interested in performance aspects you might want to look into that.
The issue with implementing a persistent cache is that you have to
consider both cold and hot filesystem cache cases: Loading an index
file with package names and versions might improve the cold-cache case,
but slow things down when the filesystem cache is populated.
As has been mentioned, keeping the index updated is the other major
issue, especially as it has to be portable and should require little or
no configuration/setup for the user (so no extra daemons or special
filesystems running permanently in the background). The obvious
solution would be to generate the cache after `emerge --sync` (and other
sync implementations) and hope that people don't modify their tree and
search for the changes in between (that's what all the external tools
do). I don't know if there is actually a way to do online updates while
still improving performance and not relying on custom system daemons
running in the background.

As for --searchdesc, one problem is that dbapi.aux_get() can only
operate on a single package-version on each call (though it can read
multiple metadata variables). So for description searches the control
flow is like this (obviously simplified):

result = []
# iterate over all packages
for package in dbapi.cp_all():
# determine the current version of each package, this is 
# another performance issue.
version = get_current_version(package)
# read package description from metadata cache
description = dbapi.aux_get(version, [DESCRIPTION])[0]
# check if the description matches
if matches(description, searchkey):
result.append(package)

There you see the three bottlenecks: the lack of a pregenerated package
list, the version lookup for *each* package and the actual metadata
read. I've already talked about the first, so lets look at the other
two. The core problem there is that DESCRIPTION (like all standard
metadata variables) is version specific, so to access it you need to
determine a version to use, even though in almost all cases the
description is the same (or very similar) for all versions. So the
proper solution would be to make the description a property of the
package name instead of the package version, but that's a _huge_ task
you're probably not interested in. What _might_ work here is to add
support for an optional package-name-description cache that can be
generated offline and includes those packages where all versions have
the same description, and fall back to the current method if the
package is not included in the cache. (Don't think about caching the
version lookup, that's system dependent and therefore not suitable for
caching).

Hope it has become clear that while the actual search algorithm might
be simple and not very efficient, the real problem lies in getting the
data to operate on. 

That and the somewhat limited dbapi interface.

Disclaimer: The stuff below involves extending and redesigning some
core portage APIs. This isn't something you can do on a weekend, only
work on this if you want to commit yourself to portage development
for a long time.

The functions listed above are the bare minimum to
perform queries on the package repositories, but they're very
low-level. That means that whenever you want to select packages by
name, description, license, dependencies or other variables you need
quite a bit of custom code, more if you want to combine multiple
searches, and much more if you want to do it efficient and flexible.
See http://dev.gentoo.org/~genone/scripts/metalib.py and
http://dev.gentoo.org/~genone/scripts/metascan for a somewhat flexible,
but very inefficient search tool (might not work anymore due to old
age).

Ideally repository searches could be done without writing any
application code using some kind of query language, similar to how SQL
works for generic database searches (obviously not that complex).
But 

Re: [gentoo-portage-dev] search functionality in emerge

2008-11-23 Thread Marius Mauch
On Sun, 23 Nov 2008 21:01:40 -0800 (PST)
devsk [EMAIL PROTECTED] wrote:

  not relying on custom system daemonsrunning in the background.
 
 Why is a portage daemon such a bad thing? Or hard to do? I would very
 much like a daemon running on my system which I can configure to sync
 the portage tree once a week (or month if I am lazy), give me a
 summary of hot fixes, security fixes in a nice email, push important
 announcements and of course, sync caches on detecting changes (which
 should be trivial with notify daemons all over the place) etc. Why is
 it such a bad thing?

Well, as an opt-in solution it might work (though most of what you
described is IMO just stuff for cron, no need to reinvent the wheel).

What I was saying is that _relying_ on custom system
daemons/filesystems for a _core subsystem_ of portage is the wrong
way, simply because it adds a substantial amount of complexity to the
whole package management architecture. It's one more thing that can
(and will) break, one more layer to take into account for any design
decisions, one more component that has to be secured, one more obstacle
to overcome when you want to analyze/debug things.
And special care must be taken if it requires special kernel support
and/or external packages. Do you want to make inotify support mandatory
to use portage efficiently? (btw, looks like inotify doesn't really
work with NFS mounts, which would already make such a daemon completely
useless for people using a NFS-shared repository)

And finally, if you look at the use cases, a daemon is simply overkill
for most cases, as the vast majority of people only use emerge
--sync (or wrappers) and maybe layman to change the tree, usually once
per day or less often. Do you really want to push another system daemon
on users that isn't of use to them?

 Its crazy to think that security updates need to be pulled in Linux.

That's IMO better be handled via an applet (bug #190397 has some code),
or just check for updates after a sync (as syncing is the only
way for updates to become available at this time). Maybe a message
could be added after sync if there are pending GLSAs, now that the glsa
support code is in portage.

Marius



Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

2008-11-14 Thread Marius Mauch
On Fri, 14 Nov 2008 11:35:44 +0100
Gilles Dartiguelongue [EMAIL PROTECTED] wrote:

 Le mercredi 12 novembre 2008 à 18:16 +0100, Peter Alfredsen a écrit :
 [snip]
   Mart had already proposed a static-lib USE flag. Donnie just
   suggested on IRC we turn this use flag into a FEATURES flag.
  
  That's problematic. You can't turn off a FEATURES flag for
  individual packages. See above.
 
 yes you can, can't find the related doc (it's not in portage man), but
 that's what /etc/portage/env/ can do for you.

Only for some FEATURES though (depending on where they are implemented).



Re: [gentoo-portage-dev] [RFC] portage-2.1.6 release plans

2008-11-07 Thread Marius Mauch
On Fri, 07 Nov 2008 15:38:48 -0800
Zac Medico [EMAIL PROTECTED] wrote:

 Since portage-2.2 isn't quite ready yet due to ongoing work in
 package sets and preserve-libs, and I don't want ongoing work to
 hold back other features that are stable, I'm planning to split a
 2.1.6 branch from trunk. This branch will have package sets and
 preserve-libs support disabled.

Disabled as in FEATURES=-preserve-libs and an almost empty
sets.conf, or disabled as in remove all traces from the code?

Marius



Re: [gentoo-dev] kerberos USE flag

2008-10-31 Thread Marius Mauch
On Fri, 31 Oct 2008 10:52:59 -0400
Doug Goldstein [EMAIL PROTECTED] wrote:

 Someone remind me again why we have the kerberos USE flag enabled by
 default?

AFAIK it was added so that the default profile provides support for
joining a Windows domain (same for the ldap flag).

 If no one opposes, I say we redact this USE flag asap.

Agreed (independent of the current breakage).

Marius



Re: [gentoo-dev] [RFC] some global useflags

2008-10-15 Thread Marius Mauch
On Thu, 16 Oct 2008 00:19:27 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:

 On Wed, 15 Oct 2008 14:47:06 -0700
 Robin H. Johnson [EMAIL PROTECTED] wrote:
  On Wed, Oct 15, 2008 at 05:43:38PM +0100, Ciaran McCreesh wrote:
   Utterly illegal, needs to die.
 
  Why? I don't agree that it needs to be the global useflags, but I
  don't consider it illegal either.
 
 It's illegal. Generated metadata must be constant and can't vary based
 upon user configuration, because if it does the package manager will
 show the wrong information at --pretend time.

There are also other issues, e.g. it breaks the generation of the
@installed package set as the installed slots can't be found in the
tree. As portage-2.2 makes increased use of slot atoms internally for
vdb handling we got a few bugreports simply due to the cache constraint
violation by USE=multislot.

Marius



Re: USE=multislot, xDEPEND-syntax in SLOT and Slot dependencies [Was: Re: [gentoo-dev] [RFC] some global useflags]

2008-10-15 Thread Marius Mauch
On Wed, 15 Oct 2008 17:20:32 -0700
Robin H. Johnson [EMAIL PROTECTED] wrote:

 Ignoring Vapier's tirade against ciaranm there, we need the
 xDEPEND-syntax for SLOTS as the real solution, however that still
 wouldn't resolve the portion that has CTARGET as part of the SLOT,
 since metadata generated on the rsyncmaster with a different CTARGET
 wouldn't match on the clients.

Are there significant USE cases for conditionals in SLOT that aren't
related to multislot and multiple ABIs? (the whole DEPEND syntax in
SLOT doesn't make sense)

For allowing multiple ABIs for a package to be installed I'm not
convinced that using SLOT is the right solution, this should probably
be considered as part of a more general multilib / cross-compile
support (there have been different designs for that).

And maybe in the (distant) future we can even add real multislot support
(same version of a package installed in multiple slots), but that's
going to need _major_ vdb and portage API changes first.

Marius



Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs

2008-10-14 Thread Marius Mauch
On Tue, 14 Oct 2008 10:59:39 +0200
Jose Luis Rivero [EMAIL PROTECTED] wrote:

 On Mon, Oct 13, 2008 at 05:38:34PM -0700, Donnie Berkholz wrote:
  On 02:03 Tue 14 Oct , Jose Luis Rivero wrote:
   
   There are some others sceneries but are not so common as the one
   presented could be. Any decent solution for this case?
  
  There are only a few obvious ones, you'll have to pick which one
  you like best. Most of the other options basically duplicate these
  in some way or add more work to them for negligible gain:
  
  - Backport the ebuild from EAPI=2 to EAPI=0
 
 EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is
 going to happen when we release new and more feature rich EAPIs), and
 changes usually come with bugs. The ebuild is committed directly to
 stable implies bugs in stable, which for me is a no-go.

Assuming the ebuild changes between foo-1 and foo-2 are mainly due to
the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many
cases) you could just reuse the foo-1 ebuild for foo-3.

If there are major differences between foo-1 and foo-2 not related to
the EAPI change then the maintainer probably didn't want foo-2 to
become stable anytime soon, so it's at least questionable if foo-3
should go straight to stable in the first place.

And adding a new version directly to stable always comes with a risk,
you can't eliminate that completely. It's all about risk assessment,
and how much work you're willing to do or time you want to spend to
minimize the risk.

  - Backport the security patch to the EAPI=0 ebuild
 
 Which sometimes is going to be impossible, require lot of work, and we
 fall into the risk of bad backported patches when non trivial backport
 patches are needed (which turns into buggy patches in the stable
 branch)

And sometimes it's a very viable option when patches are provided by
upstream.

In the end at least one of the above solutions should work in
almost every case. It might sometimes cause a bit more work than a bump
that doesn't involve any EAPI changes, but that's life.
If you have a real case where both suggested solutions aren't
realistic I'd like to hear about it, otherwise I think we're wasting
time making up solutions for a non-existant problem

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

2008-10-10 Thread Marius Mauch
On Fri, 10 Oct 2008 14:48:19 +0200
Fabian Groffen [EMAIL PROTECTED] wrote:

 Whatever.  Some of you seem to have some quite agressive dislikement
 to it.  In the end it's just a name/tag.  I guess I could live with
 anything, including c3p0.

Well, while I dislike x64 I'm more concerned about using different
names (amd64 and x64) for the same architecture (same would apply if
you had used i386 or ia32 in some cases instead of x86) and was just
checking if there was any functional reason for that difference.

Marius



Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms

2008-10-09 Thread Marius Mauch
On Thu, 9 Oct 2008 20:11:01 +0200
Fabian Groffen [EMAIL PROTECTED] wrote:

   amd64-linux
   x64-openbsd
   x64-solaris

Is there a special reason why you're using x64 instead of amd64 in
those cases? (IMO x64 is the most stupid name for the x86_64
architecture)

Marius



Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

2008-10-09 Thread Marius Mauch
On Fri, 10 Oct 2008 00:16:10 + (UTC)
Duncan [EMAIL PROTECTED] wrote:

 Marius Mauch [EMAIL PROTECTED] posted
 [EMAIL PROTECTED], excerpted below, on  Fri,
 10 Oct 2008 00:05:00 +0200:
 
  On Thu, 9 Oct 2008 20:11:01 +0200
  Fabian Groffen [EMAIL PROTECTED] wrote:
  
 amd64-linux
 x64-openbsd
 x64-solaris
  
  Is there a special reason why you're using x64 instead of amd64
  in those cases? (IMO x64 is the most stupid name for the x86_64
  architecture)
 
 AFAIK, that's not amd64/x86_64, but rather ia64, aka itanic aka
 itanium. At least, that's how I'd interpret them since I've seen that
 abbreviation made before, particularly since there's already amd64 in
 context.

No, x64 is the marketing name Microsoft made up for x86_64 (aka amd64,
ia32e and Intel 64), as Windows for x86_64 doesn't sound that sexy,
and was later adopted by Sun and others. 
ia64/Itanium doesn't have any other alias names AFAIK.

Marius



Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets (revised)

2008-10-04 Thread Marius Mauch
On Sat, 04 Oct 2008 03:46:41 +
Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] wrote:

 It would also be important to have versioned sets (depending on a
 slot, for example). Marius Mauch (genone) suggested a very
 interesting way to solve this by using a set config file (portage
 specific) that, as he stated, should work if I got the syntax right
 from memory [current Portage svn] (something similar to):
 
 -  sets.conf 
 [slot-4.1]
 class=dbapi.VariableSet
 variable=SLOT
 include=4.1
 
 [kdebase]
 class=files.StaticFileSet
 filename=kdebase
 
 [kdebase-4.1]
 class=base.DummyPackageSet
 extend=kdebase
 intersect=slot-4.1

Small correction: The example above doesn't actually work as intended,
as the VariableSet handler only operates on installed packages, so 
@kdebase-4.1 would actually contain atoms that are
- listed in @kdebase
- have SLOT=4.1
- are already installed

 -  sets.conf 
 
 Being able to take advantage of use deps for packages would be a
 bonus: kde? (
 x11-libs/compizconfig-backend-kconfig
 x11-wm/compiz[kde]
 )

Basic use deps are supported (those that don't expand to use
conditionals), use conditionals are not, and probably won't be for
various reasons.

 It would be really helpful if we could have a package.mask like
 structure that allowed users to mask deps from sets (does / could
 package.mask be used this way?)

Well, portage has a set handler for wrapping /etc/portage/package.*
files in sets, which in combination with the substraction operator /the
remove option in sets.conf can be used for this purpose.

 Perhaps we should start doing emerge -uDav @world/@installed.

What would be the point of that?

 So this is what I would like to see with sets. Am I crazy? Is it
 possible to do any of this? Anyone has some other needs?  

Well, pretty much all what you want is possible with current portage
codebase (only available via svn, not released yet), except for use
conditionals, and the issue about VariableSet mentioned above, but
that's fixable in several ways. Mind that details of the examples above
might change over time as that stuff is just a few days old.

Using that stuff in the tree however is a completely different issue,
as the current sets.conf format will likely never be supported by other
package managers than portage (as it's somewhat tied to the portage
API).

Marius



Re: [gentoo-dev] News item: World file handling changes in Portage-2.2

2008-09-25 Thread Marius Mauch
On Fri, 5 Sep 2008 17:24:57 +0200
Marius Mauch [EMAIL PROTECTED] wrote:

 - another idea that hasn't been mentioned yet is that we could simply
 inject @system into world_sets in the portage ebuild when we detect a
 2.1-2.2 upgrade (the ebuild already does a few other migrations that
 way). That would be the least-invasive way to keep the old behavior,
 but only works for poeple who haven't upgraded to 2.2 yet (not sure if
 that's a pro or contra)

This solution has been implemented now (to be released with 2.2_rc9).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: News item: World file handling changes in Portage-2.2

2008-09-09 Thread Marius Mauch
On Wed, 10 Sep 2008 01:43:45 +0100
Steve Long [EMAIL PROTECTED] wrote:

 Marius Mauch wrote:
 
  Second for the suggestions on how to handle the transition:
  - treating 'world' and '@world' differently is a no go from my POV.
  One of the main reasons to implement them as sets was to remove
  special case code in emerge, so I'm quite opposed to adding new
  special cases instead. And I'm quite sure that such a separation
  would cause confusion, and some isues regarding (end-user)
  documentation.
 
 We're talking about one special case in the command-line processing,
 to support the existing usage that all our users are used to. It adds
 practically nothing in execution time, simply expanding to @system
 @world, and means that users who don't want to know about sets, or
 are not thinking in set terms at the time of using emerge, will get
 the result they expect.

It also means we'd indefinitely have to carry another special
case around for legacy reasons (removing it later would be even more
painful than doing the switch now). You know, those are the things we
want to get rid off, as they really make our life harder in the long
run. YOu may consider it trivial in this cse, but these things always
look trivial when you're adding them, and you curse about them when you
have to modify the code later on.
Maybe the best solution is to drop the non-prefixed versions of 'world'
and 'system' completely 

Marius



Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)

2008-09-05 Thread Marius Mauch
On Sat, 23 Aug 2008 13:39:58 -0700
Zac Medico [EMAIL PROTECTED] wrote:

 Do the name and definition of this PROPERTIES=live value seem good?
 Would anybody like to discuss any changes to the name, definition,
 or both?

Not sure if 'live' is really the best choice here, as many things also
apply to e.g. automated daily/nightly snapshots/builds that might also
be useful to support. Maybe 'unversioned' is more accurate.

Marius



Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)

2008-09-05 Thread Marius Mauch
On Sun, 24 Aug 2008 14:01:48 -0700
Zac Medico [EMAIL PROTECTED] wrote:

 Do the name and definition of this PROPERTIES=virtual value seem
 good? Would anybody like to discuss any changes to the name,
 definition, or both?

If it's only used to indicate that the package doesn't install any
files I'd suggest to use 'empty' or 'nocontents' instead. 'virtual'
somehow implies that it's only applicable to packages in the 'virtual'
category, which isn't the case with the given definition (as you said).

Marius



Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)

2008-09-05 Thread Marius Mauch
On Tue, 26 Aug 2008 14:20:07 + (UTC)
Duncan [EMAIL PROTECTED] wrote:

 I therefore believe I like just moving them all to a *virtual*/
 category better, thus obviating the need for that particular property
 in the first place.

I strongly belive that it's a horrible idea to add special meanings to
certain (hardcoded) category names in the package manager.
Technically, names (including categories) should only be used as
identifiers, not as classifiers.

Marius



Re: [gentoo-dev] News item: World file handling changes in Portage-2.2

2008-09-05 Thread Marius Mauch
On Sat, 16 Aug 2008 22:39:41 +0300
Petteri Räty [EMAIL PROTECTED] wrote:

 As per glep 42 (http://www.gentoo.org/proj/en/glep/glep-0042.html)
 here is the required email for a new news item. This news item is
 important because otherwise users will be missing updates to the
 system set if they continue updating their system with the usual
 emerge --update 
 --deep world. Unless objections come out the new news item will be 
 committed at the same time as rc8 (rc8 will have an update man
 portage page describing world_sets).
 
 Title: World file handling changes in Portage-2.2
 Author: Petteri Räty [EMAIL PROTECTED]
 Author: Zac Medico [EMAIL PROTECTED]
 Content-Type: text/plain
 Posted: 2008-XX-XX
 Revision: 1
 News-Item-Format: 1.0
 Display-If-Installed: sys-apps/portage-2.2_rc8
 
 As of Portage 2.2 the world set does not include the system
 set any more. If you want emerge --update --deep @world to
 update the system set too, you need to add @system to the new
 world_sets file in /var/lib/portage/. For more information on
 world_sets see man portage.

Sorry for not replying earlier, I was without mail access for the last
few weeks.

First, regarding the news item, I'd suggest that instead of telling
users to modify world_sets manually to use `emerge --noreplace @system`.
Also there have been more changes that might not be as obvious and only
affect people with unusual usage patterns, namely `emerge @world`
without using --update or --noreplace will rebuild packages contained
in @world (same is true for all other sets).

Second for the suggestions on how to handle the transition:
- treating 'world' and '@world' differently is a no go from my POV. One
of the main reasons to implement them as sets was to remove special
case code in emerge, so I'm quite opposed to adding new special cases
instead. And I'm quite sure that such a separation would cause
confusion, and some isues regarding (end-user) documentation.
- adding a new @worldfile set to get the new behavior, and use @world
for the old. That one is quite interesting, and should actually
be rather simple to implement: rename the existing @world to
@worldfile, create a new StaticFileSet @world that just contains
@worldfile and @system (stored in /usr/share/portage), change most
references in emerge from @world to @worldfile (for technical reasons,
the WorldSet class is somewhat special), and add world-candidate=False
to the default sets.conf
- issuing a warning if 'world' is the only argument would also be a
special case, but by far not as invasive as the first suggestion. I've
actually considered to mark 'world' and 'system' without the set prefix
as deprecated but thought it would be too invasive/annoying at this
time.
- another idea that hasn't been mentioned yet is that we could simply
inject @system into world_sets in the portage ebuild when we detect a
2.1-2.2 upgrade (the ebuild already does a few other migrations that
way). That would be the least-invasive way to keep the old behavior,
but only works for poeple who haven't upgraded to 2.2 yet (not sure if
that's a pro or contra)

Though honestly I don't think this issue is as big as some other
people make it. People might miss some updates. The same would happen
if we remove packages from @system, or people switch profiles (so
@system changes).

Marius



Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?

2008-08-06 Thread Marius Mauch
On Fri, 01 Aug 2008 19:02:48 -0700
Zac Medico [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi everyone,
 
 It might good to add support for a new RESTRICT=live value in
 ebuilds. By specifying this value, an ebuild would be able to
 indicate that it uses src_unpack() to download sources from some
 type of live repository such as cvs, darcs, git, mercurial, or svn.

If we go with the RESTRICT solution, I'd rather use
RESTRICT=versioned to indicate that
a) ebuild version doesn't reflect upstream version (in most cases)
b) upstream changes don't result in a new version

Marius



Re: [gentoo-portage-dev] [2/4] proto-GLEPS for Tree-signing

2008-07-29 Thread Marius Mauch
On Tue, 29 Jul 2008 20:51:45 +0100
Mike Auty [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Sorry,
   I lost my notes from when I last looked these over several
 months ago, and only just found them again.  I haven't copied this to
 [EMAIL PROTECTED], so let me know if I should do that.  I just had a quick
 couple of things I was thinking about, and one of them I figured out
 during my re-read, so it's only really the following...
 
 In this Glep (xx+1), in the section discussing the procedure for
 creating a MetaManifest file, in step 3.3, does that include
 verification of the manifest's signature if it has one?  It would seem
 odd to ignore the signature if it's wrong (I'm not sure about the case
 if a signature isn't present).  I also don't know how this would then
 be handled (a complete abort, or ignoring the latest changeset to that
 ebuild?).

I don't think that verification at this stage would be a good idea. The
only sane way to respond to a failed check would be to either exclude
the whole package from the sync (keeping the state from the last run),
leading to various problems (what if it's a critical bugfix/security
bump, or breaks a the deptree of many packages?), or not record the
Manifest in the Metamanifest, which hasn't any benefits over reyling on
the client doing the verification.

Marius



Re: [gentoo-dev] metadata.xml USE flag descriptions

2008-07-28 Thread Marius Mauch
On Mon, 28 Jul 2008 12:50:01 -0400
Doug Goldstein [EMAIL PROTECTED] wrote:

 Please make sure you commit any changes to use.local.desc to 
 metadata.xml otherwise you risk the chance of having your changes
 lost. I'm currently in the process of converting use.local.desc to 
 metadata.xml. After a category is converted, it will be
 auto-generated EXCLUSIVELY from metadata.xml. This means it will be
 YOU QA error if you only commit to use.local.desc from here on out.

Hmm, maybe we should then disallow commits to use.local.desc on the cvs
server completely ...

Marius



Re: [gentoo-dev] Re: [RFC] New policy: LDFLAGS should be respected

2008-07-27 Thread Marius Mauch
On Sat, 26 Jul 2008 22:45:29 -0500
Jeremy Olexa [EMAIL PROTECTED] wrote:

 Arfrever Frehtes Taifersar Arahesis wrote:
  It will at least allow QA team to fix such bugs where patches are
  already available.
 
 So, if bugs are being fixed why is there a need to fix something that 
 isn't broken with regards to a policy _needed_ to enforce this
 action? Are bugs being ignored or RESOLVED, WONTFIX?
 
 Hypothetically, if there was such a policy and there was 100's of
 bugs filed with patches (maintainers should handle the patches
 anyway)

Should being the keyword here. Also assumes that all packages are
actually maintained. I guess the wording of the original request should
have been more like is anyone against QA fixing packages that ignore
LDFLAGS?.

Marius



Re: [gentoo-portage-dev] portage-2.2-rc3 parallel merges quit being parallel

2008-07-26 Thread Marius Mauch
On Sat, 26 Jul 2008 16:56:20 -0500
Andrew Gaffney [EMAIL PROTECTED] wrote:

 Duncan wrote:
  --jobs=10 --keep-going --load-average=15
 
 For a dual-dual-core setup, a load average of 4.0 is fully loaded.

Only in ideal cases, when you have long-running processes
hammering the cpu and little or no context switches. This isn't the case
with builds, the actual compile processes that need cpu time usually
terminate very quickly, which increases the load average.
I did some benchmarking a while ago with different combinations of -j
and -l in MAKEOPTS, using the kernel as testcase, and IIRC the fastest
builds were around -l6.0 (on a dual-core system) and high (or
unlimited) values for -j (sidenote here: some ebuilds like openoffice
parse MAKEOPTS to get parameters for their own build systems, but only
recognize/support -j and ignore -l, so one should still be careful with
the value for -j).

Marius



Re: [gentoo-dev] system set no longer in part of world set

2008-07-21 Thread Marius Mauch
On Mon, 21 Jul 2008 11:02:57 -0400
Doug Goldstein [EMAIL PROTECTED] wrote:

 Marius Mauch wrote:
  Now that's a big exaggeration. It _might_ be missing from world
  updates (there are still many cases where it will be included), but
  that's not the only available operation in portage.
 
  Marius

 We discussed this in #gentoo-portage the other day where I had a
 machine that was on gcc 4.3.1 (not -r1) and glibc 2.7 and didn't want
 to upgrade either of those packages to the latest ~arch.
 
I know, but just because it did (not) happen in your case doesn't mean
it will be the same for everyone else.

Marius



Re: [gentoo-dev] RFC: auto-detection of unpack dependencies

2008-07-20 Thread Marius Mauch
On Sun, 20 Jul 2008 17:41:58 +0400
Peter Volkov [EMAIL PROTECTED] wrote:

 В Чтв, 17/07/2008 в 04:51 +0200, Marius Mauch пишет: 
  At dev.gentoo.org/~genone/unpack.eclass is the draft for an eclass
  to implement this feature. 
 
 Marius, although it's possible to do this things in eclass why is
 eclass better? As I see portage's unpack() already has extension -
 program to unpack relation. Basically unpack() in ebuild.sh has the
 following code:
 
 unpack() {
 [snip]
 case ${x##*.} in
 tar)
 tar xof ${srcdir}${x} ${tar_opts} || die $myfail
 ;;
 tgz)
 tar xozf ${srcdir}${x} ${tar_opts} || die $myfail
 [snip and so on...]
 
 This means that every ebuild which uses 'unpack ${A}' should have in
 DEPEND a program which is selected by filename extension of sources.
 So as I understood your initial suggestion was to make this happen
 automatically. And this is very logical as makes ebuilds cleaner and
 more terse. So why did you changed your mind and try to write another
 eclass (which then should sit in the tree forever), to create
 duplicate unpack function instead of just making step you suggested
 initially? Is there any intension to remove unpack logic from package
 manager? And if yes, why?

The eclass is provided as a proof-of-concept implementation that can be
used without adding additional infrastructure and implementing and
defining a new EAPI version. PM-based solutions would be nicer
long-term, but are also more tricky to get right (mainly a question
of where to inject the deps). Also the eclass approach has the benefit
that the whole unpack logic can be maintained in one location vs. being
split between multiple places in the package manager and the tree, and
is easier to extend (no need for an EAPI change just to add a new unpack
format). 
And as you ask, there have been plans to move quite a bit of
the bash code from portage into the tree (transparently to ebuilds
though) as that's the better place to maintain many helper functions
like do* or new* that are only used by ebuilds/eclasses and not portage.
But those plans have already existed for years (long before EAPI
existed) without anything happening, and they've never been very
specific wrt what exactly could be moved.
Even with a PM-based solution it might be useful, depending on the
actual implementation, to have the unpack() funtion in the tree, for
the reasons outlined in the first paragraph.

Marius



Re: [gentoo-dev] system set no longer in part of world set

2008-07-18 Thread Marius Mauch
On Fri, 18 Jul 2008 10:01:28 -0400
Doug Goldstein [EMAIL PROTECTED] wrote:

 Olivier Crête wrote:
  On Mon, 2008-07-14 at 18:01 -0400, Doug Goldstein wrote:

  This brings out the fun of circular depends. I don't really know
  how to address this but a lot of packages are going to have to be
  updated to contain proper depends. i.e. C based apps will need 
  RDEPEND=virtual/libc. C++ packages will need a stdc++ depend.
  
 
  Adding a dep to libc almost everywhere seems extremely wrong to me.
  I though we had decided many times that it was a bad idea.
 

 Yes. Adding libc everywhere is wrong. However, if you don't have one
 of the packages listed here [1], your libc won't ever update.

Now that's a big exaggeration. It _might_ be missing from world updates
(there are still many cases where it will be included), but that's not
the only available operation in portage.

Marius
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] system set no longer in part of world set

2008-07-18 Thread Marius Mauch
On Fri, 18 Jul 2008 16:21:24 +0100
Robert Bridge [EMAIL PROTECTED] wrote:

 On Fri, 18 Jul 2008 16:30:20 +0200
 Arfrever Frehtes Taifersar Arahesis [EMAIL PROTECTED] wrote:
 
  IMHO it would be better to teach users to explicitly specify
  '@system' during updates, e.g. `emerge -uDN @system @world`.
 
 Why not just re-instate the implicit dependency of world on system?

Because that doesn't actually fix the problem, it just covers it up to
some degree (there has never been a guarantee that system is
actually satisifed when you install a package). Also the new solution is
more flexible as it still allows you to include system in world easily,
or update/rebuild system and world separately. And for a full system
updates there is a new target available that actually includes all
installed packages.
Yes, this is going to require some user reeducation, and yes, this will
take some time, but it isn't as dramatic as some people make it. The
whole implicit-system-dependency thing has never existed, it was
always a broken assumption that only didn't blow up badly because a) the
system target rarely changes b) most packages only depend on a tiny
part of system and c) most users actually do full system updates
regulary.
As soon as you want to install a package that actually implicitly
depends on something in system that isn't already installed the whole
thing breaks down.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: auto-detection of unpack dependencies

2008-07-17 Thread Marius Mauch
On Thu, 17 Jul 2008 07:00:32 -0500
Joe Peterson [EMAIL PROTECTED] wrote:

 Marius Mauch wrote:
  The eclass also contains it's own implementation of unpack (renamed
  to unpack2) and src_unpack so the logic which tools/packages are
  used for unpacking can be maintained in a single place instead of
  being splitted between the package manager and the tree.
 
 Marius, these look like nice functions.  A couple of questions:
 
 1) Since it requires altering an ebuild to use these features (i.e. no
 automatic), what is the advantage over just including the dep the
 usual way?

You wouldn't have to maintain the relevant deps, e.g. when you change
SRC_URI, when the unpack implementation changes (e.g. adding support
for new unpackers) or keeping the conditionals in sync with SRC_URI.

 2) The name unpack2 is intended to be temporary, right?  ;)  I'd
 guess that after this functionality is integrated into portage, there
 would be no need for the extra unpack func.  But then we'd probably
 have to keep unpack2 for a long time as an alias.  Any way to avoid
 that?

Well, it can't be named unpack to avoid conflicts with the internal
portage function. If this functionality would be added on the PM side
then there would be no more need for the eclass (you wouldn't want to
use both implementations at the same time), and it would be opt-in via a
new EAPI, so you'd have to change the ebuilds anyway to benefit from
it. So I don't see a need to have a unpack2 alias outside the eclass.

 3) Same would go for the needed call for unpack_update_depend,
 correct?  I.e. it would not be needed after portage has this
 functionality (and at that point, the unpack and dep code would be
 unified cleanly).  So this function would then become a stub,
 correct?  The only thing here is that ebuilds could linger for some
 time without being cleaned up.

See above.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: auto-detection of unpack dependencies

2008-07-16 Thread Marius Mauch
On Tue, 15 Jul 2008 04:14:18 +0200
Marius Mauch [EMAIL PROTECTED] wrote:

 As a result of Cardoes earlier mail we talked a bit about possible
 solutions in #gento-portage, and I suggested to let portage
 automatically inject the deps based on SRC_URI pattern matching.
 A mapping of extensions and their unpack deps would be kept in the
 tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )'

At dev.gentoo.org/~genone/unpack.eclass is the draft for an eclass
to implement this feature. It doesn't modify DEPEND by itself, ebuild
have to call unpack_update_depend on their own for that, as automatic
updates are problematic when you have to take indirect and multiple
inheritance of eclasses into account. As automatic updates aren't
implemented there is also no need for a RESTRICT setting or similar,
and also no requirements on the order of SRC_URI/RESTRICT/inherit.

The eclass also contains it's own implementation of unpack (renamed to
unpack2) and src_unpack so the logic which tools/packages are used for
unpacking can be maintained in a single place instead of being
splitted between the package manager and the tree.

If someone wants to use it I can add it on the tree (after the normal
review process and being better tested), but I'll only be doing it
when there is an actual demand for it (no point in adding an eclass that
nobody uses).

It's still possible to come up with a package-manager-based solution in
the future, but for the moment the eclass should help with the
immideate problem (though the problem isn't exactly new).

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: auto-detection of unpack dependencies

2008-07-15 Thread Marius Mauch
On Tue, 15 Jul 2008 19:12:37 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:

 On Tue, 15 Jul 2008 04:14:18 +0200
 Marius Mauch [EMAIL PROTECTED] wrote:
  As a result of Cardoes earlier mail we talked a bit about possible
  solutions in #gento-portage, and I suggested to let portage
  automatically inject the deps based on SRC_URI pattern matching.
  A mapping of extensions and their unpack deps would be kept in the
  tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )'
 
 Could do it just as an eclass...
 
 inherit work-out-my-unpack-deps-for-me
 
 In principle, there's nothing that can't be done on the ebuild side
 here.

Right, just I'd expect the parsing of SRC_URI (with conditionals) to be
a bit tricky in bash, not something I'm going to work on. An
eclass-based solution would have a few benefits though wrt the metadata
cache.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: auto-detection of unpack dependencies

2008-07-15 Thread Marius Mauch
On Tue, 15 Jul 2008 22:34:33 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:

 On Tue, 15 Jul 2008 23:23:26 +0200
 Marius Mauch [EMAIL PROTECTED] wrote:
  Right, just I'd expect the parsing of SRC_URI (with conditionals) to
  be a bit tricky in bash, not something I'm going to work on. An
  eclass-based solution would have a few benefits though wrt the
  metadata cache.
 
 Well... You don't really have to parse it.
 
 for p in $SRC_URI ; do
 if [[ ${p} == ( ]] || [[ ${p} == ) ]] || \
 [[ ${p%\?} != ${p} ]] ; then
 UNPACK_DEPENDS=${UNPACK_DEPENDS} $p 
 elif [[ ${p%.zip} != ${p} ]] ; then
 UNPACK_DEPENDS=${UNPACK_DEPENDS} app-arch/unzip 
 elif [[ ${p%.bz2} != ${p} ]] ; then
 UNPACK_DEPENDS=${UNPACK_DEPENDS} app-arch/bzip2 
 fi
 done
 
 Granted, it'll generate invalid output if SRC_URI is invalid (for
 example, if SRC_URI has mismatched parens, the output will too), but I
 can't think of any situation where breaking DEPEND if SRC_URI is
 already broken is a problem.

Interesting idea. Unfortunately our depstring parser doesn't like empty
parentheses (as they are usually problem indicators), so it doesn't
work out.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] RFC: auto-detection of unpack dependencies

2008-07-14 Thread Marius Mauch
As a result of Cardoes earlier mail we talked a bit about possible
solutions in #gento-portage, and I suggested to let portage
automatically inject the deps based on SRC_URI pattern matching.
A mapping of extensions and their unpack deps would be kept in the tree
(e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )'

Benefits:
- simplified depstrings for most packages (I assume 90% of the tree)
- easier maintenance if dependencies are changing, or additional
implementations become supported (this could also be achieved with
virtuals though)
- potentially more accurate dependencies, as some common errors would
be eliminated (e.g. proper treatment of use-conditionals, not adding
unpack deps to RDEPEND)
- long-term adds the possibility to remove bzip2, gzip and tar from
@system

Potential problems:
- might cause trouble for some packages that use custom code for
unpacking, or due to circular deps, this could simply be solved with a
new RESTRICT value though.
- automagic deps could be confusing to devs/users
- not available for existing EAPIs (due to the mentioned problems)
- slightly slower dep calculations due to the extra processing
- possible match errors

So, is this something ebuild maintainers would like in general, or does
such a feature cause you nightmares?

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Council meeting summary for 10 July 2008

2008-07-13 Thread Marius Mauch
On Sun, 13 Jul 2008 00:11:18 -0700
Donnie Berkholz [EMAIL PROTECTED] wrote:

 Betelgeuse@ dberkholz: with GLEP 55 EAPI X can add the support for
 scm 
 Betelgeuse@ dberkholz: and older Portage versions work just fine

I thought we established that EAPI (no matter how it's defined) only
controls ebuild _contents_ ...

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: 0-day bump requests

2008-07-03 Thread Marius Mauch
On Fri, 4 Jul 2008 01:16:09 +0200
Jeroen Roovers [EMAIL PROTECTED] wrote:

Disclaimer: I'm not really a package maintainer anymore.

 1) How do you feel when you receive an early version bump request?

I guess like with most people it depends 
a) If I'm already aware of the new version, or would have noticed it
myself very soon I'd get a bit annoyed by them
b) How the request is worded. Is it a demand $foo has been released 5
minutes ago, why isn't it in the tree yet?!?), or just a friendly
notification, possibly including helpful hints about changes (new deps
or configure options for example).
c) The nature of the release. If the release is important (e.g.
because it contains fixes for security or data corruption issues, or
problems affecting many users) then I'm more likely to appreciate an
early notification.

 2) If you had your way, would you discourage users from filing early
 version bump requests?

Not in general, only if they are worded in some way offensive or don't
contain useful information. But that applies to almost any bug report.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-portage-dev] A seemingly bug found when emerging @preserved-rebuild

2008-07-01 Thread Marius Mauch
On Wed, 2 Jul 2008 02:41:14 +0800
Zhang Le [EMAIL PROTECTED] wrote:

 Is this a bug? or did I miss something here?
 Thanks for your time!

The 'bug' here is that USE=multislot shouldn't exist. People using it
should be able to deal with resulting breakages on their own

Marius
-- 
gentoo-portage-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] When the version scheme changes

2008-06-29 Thread Marius Mauch
On Sun, 29 Jun 2008 15:52:37 +0200
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Bo Ørsted Andresen wrote:
  On Saturday 28 June 2008 17:03:13 Marijn Schouten (hkBst) wrote:
  PV=${PV/0./}
 
  to that new ebuild. This is the cleanest way to do it and doesn't
  require any variable name changes or any other changes to the
  ebuild regardless of what it does. Unfortunately it is also
  illegal per current PMS as PV is a read-only variable. Right now I
  feel that the gain of having PV read-only (catch a few bugs?) is
  much lower than the pain (extensive ebuild-dependend changes when
  the version scheme changes). Please comment.
  
  I don't really see how making PV not read-only is any easier than
  using MY_PV. Did you expect changing PV to magically change P, PVR
  and PF too?
 
 If we can agree to have those values writable we could define a
 function that will handle resetting all those too.

Not going to happen. These variables are used internally by portage in
various ways, and making their content inconsistent with the version in
the filename is likely to cause subtle bugs and/or weird behavior.
Besides, you've yet to explain the benefit of it, short of avoiding a
simple replace operation in an ebuild, and the given use case isn't all
that common anyway.

Marius
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] When the version scheme changes

2008-06-29 Thread Marius Mauch
On Sun, 29 Jun 2008 18:20:06 +0200
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Marius Mauch wrote:
  On Sun, 29 Jun 2008 15:52:37 +0200
  Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:
  
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Bo Ørsted Andresen wrote:
  On Saturday 28 June 2008 17:03:13 Marijn Schouten (hkBst) wrote:
  PV=${PV/0./}
 
  to that new ebuild. This is the cleanest way to do it and doesn't
  require any variable name changes or any other changes to the
  ebuild regardless of what it does. Unfortunately it is also
  illegal per current PMS as PV is a read-only variable. Right now
  I feel that the gain of having PV read-only (catch a few bugs?)
  is much lower than the pain (extensive ebuild-dependend changes
  when the version scheme changes). Please comment.
  I don't really see how making PV not read-only is any easier than
  using MY_PV. Did you expect changing PV to magically change P, PVR
  and PF too?
  If we can agree to have those values writable we could define a
  function that will handle resetting all those too.
  
  Not going to happen. These variables are used internally by portage
  in various ways, and making their content inconsistent with the
  version in the filename is likely to cause subtle bugs and/or weird
  behavior. Besides, you've yet to explain the benefit of it, short
  of avoiding a simple replace operation in an ebuild, and the given
  use case isn't all that common anyway.
 
 Why can't portage use its own variables and export these with an
 initial value but not use them further?

Because there is no need to create even more variables when there is
absolutely no benefit.

Marius
--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] License groups

2008-06-26 Thread Marius Mauch
While portage-2.2 has support for license visibility filtering (aka
ACCEPT_LICENSE) this currently isn't very usable as we still don't have
the necessary default license group and ACCEPT_LICENSE setting in the
tree (and even the only existing license group is of questionable use,
see bug #228527).
So if you care about this feature I'd like to ask you to collect the
necessary information to make it usable. This mainly means to create a
list of licenses that should be accepted by default. The recommended
way to do this is to list the licenses that can not be accepted by
default (legally), and trying to classify the rest into more managable
groups.

See bugs #152593 and #17367 for background information.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-dev] A few questions to our nominees

2008-06-14 Thread Marius Mauch
On Sat, 14 Jun 2008 10:38:18 +0200
Luca Barbato [EMAIL PROTECTED] wrote:

 Marius Mauch wrote:
  Ignoring possible semantic issues for the moment,
 
 Please point them so I could fix them properly ^^

For example all the ordering issues pointed out by others in this
thread. Also the whole 'template' approach is likely going to introduce
a number of issues. And as your proposal is lacking a lot of details
more problems will come up over time.

  Which in turn either means that the PM has to internally support
  the SCMs or support some new phase functions to extract the
  revision.
 
 After some discussions with dev-zero, I think we'll need a new phase, 
 possibly trigged by maint, before I was thinking about adding it to
 sync.

What exactly do you mean with 'maint'?

  Plus it has similar (unstated) transition issues as GLEP-54, just
  avoids a new comparison algorithm and the CPV vs. atom issue.
 
 Hmm, give me more informations about your concern.

Simply how would you actually introduce this stuff without breaking
existing setups?

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: A few questions to our nominees

2008-06-14 Thread Marius Mauch
On Sat, 14 Jun 2008 12:32:22 +
Patrick Lauer [EMAIL PROTECTED] wrote:

 Portage 2.2 and others support sets, portage 2.2 even supports
 dynamic sets like the @preserved-rebuild. Shouldn't be that hard to
 add a live-ebuilds dynamic set.
 (Comments on the feasibility of my idea from portage people
 appreciated)

Should be simple if there is a definite way to determine if an ebuild
is a 'live' eubild or not, wether that's by examining the
name/category/version/metadata/external list/moon phase doesn't really
matter (well, moon phase might complicate it a bit ;)

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] A few questions to our nominees

2008-06-13 Thread Marius Mauch
On Thu, 12 Jun 2008 11:05:01 +0200
Luca Barbato [EMAIL PROTECTED] wrote:

 Piotr Jaroszyński wrote:
  Hello,
  
  looks like every nominee wants the council to be more technical so I
  have a few technical questions for you:
  
  1. GLEP54
 
 Just for fun I took some of the ideas about alternative management of 
 the issue and specified the features it makes it worth changing
 (better management and automated snapshot generation from the live
 ebuild).
 
 http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst
 
 I'd like to see some comment on it (I put it in glep form just now so
 it isn't exactly perfect)

Ignoring possible semantic issues for the moment, I'd be against this
simply because it would require the PM to be aware of the current
revision of the repository and to transform it into a integer value
(trivial for SVN, not so trivial for CVS for example). Which in turn
either means that the PM has to internally support the SCMs or support
some new phase functions to extract the revision.
Plus it has similar (unstated) transition issues as GLEP-54, just avoids
a new comparison algorithm and the CPV vs. atom issue.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-10 Thread Marius Mauch
On Wed, 11 Jun 2008 00:11:32 +0200
Bo Ørsted Andresen [EMAIL PROTECTED] wrote:

 On Tuesday 10 June 2008 18:26:55 Doug Goldstein wrote:
  Let's try to aim to do an EAPI=2 sometime soonish since Portage now
  has USE flag depends in version 2.2 which is looming on the
  horizon. It'd be nice to hit the ground running with supporting
  these. I know it'll be trivial for the Paludis and pkgcore guys to
  make this work since they already support USE flag depends.
 
 I would like the portage devs to comment upon which of the following
 features they think could easily be implemented before portage 2.2
 goes stable. There's still some time since it hasn't left
 package.mask yet, so I'd rather they exclude the features that will
 take too long to implement than anybody else doing that...

Well, actually I would rather not add any new features between pre8 and
rc1 to not further delay 2.2. And generally I'm also not in favor of
adding new features during the rc phase as it's there to eliminate
remaining bugs and for refinement of existing features, not to add new
unknowns.

 Already implemented:
 - Use dependencies, it's not clear to me whether we all agree
 entirely upon the syntax yet though (bugs #2272 and #174406)
 
 Things I believe should be trivial to implement:
 - Custom output names in SRC_URI, also called arrows (bug #177863)

This I'd definitely delay as it probably affects a number of things.

 - Guarantee trailing slashes (bug #174408)

Mostly a matter of finding the relevant spots, the actual work to
implement it would be trivial. Could be considered as bugfix.

 - Limit values in $USE (bug #176467)

Also requires little actual work, question is only if this should be
enabled for EAPI=0/1 as well, and how it relates to USE_EXPAND and ARCH.
If it should be done for existing EAPIs as well could be considered as
bugfix.

 - doins support for symlinks (bug #179932)

If someone implements it it can be included (do you want an EAPI bump
for that?)

 - Enable FEATURES=test by default (bug #184812)

Only if 99% of the stable and ~arch tree and all potential system
packages build with it (IOW: no)

 - GLEP 42 - news items

Already implemented.

 Bigger features I'm interested in:
 - Making do* die on failure by default (without changing their
 behaviour for previous eapis). Possibly adding either nonfatal or
 try_do* for cases where this isn't desired. (bug #138792)
 - More phases
   - src_prepare, for applying patches and running autotools etc.
   - src_configure, for running configure scripts (bug #197859)
   - pkg_pretend (bug #177860 - could also be used to fix bug #75936)
   - maint_*, it's not clear to me if this has been fleshed out in
 sufficient detail yet (bug #185567)

Unlikely for 2.2.

 - default_*, allows an ebuild to redefine phases to add more
 functionality and then call default_$phase. Currently the default
 phases are lost when redefining the phases.

Should be trivial to implement off-hand (just converting the existing
defaults to wrappers)

 - default for src_install (bug #33544)

Should also not be terribly difficult, though I'd rather wait until
after 2.2 final.

 - Ranged dependencies (bug #4315)

Unlikely for 2.2.

 Of course I'd like GLEPs 54 and 55 too but since the council still
 hasn't made a decision about them I'll leave them out..

Well, I already said everything about those during the first discussion
round and the relevant council meeting.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] Portage persistence structures :: information about ports tree

2008-06-09 Thread Marius Mauch
On Mon, 09 Jun 2008 17:36:14 -0300
João Macaíba [EMAIL PROTECTED] wrote:

 May someone give me some help on this ? How does portage do the
 searchs ? Walk into the ports tree and build some structure or store
 this info on some embedded database like berkeley db or sqlite ?

You're probably looking for the portdbapi class defined in
pym/portage.py (or pym/portage/dbapi/porttree.py in 2.2), in particular
the cp_all(), cpv_all(), cp_list() and aux_get() methods.

Marius
--
gentoo-portage-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] merging two packages - upgrade path?

2008-06-05 Thread Marius Mauch
On Thu, 5 Jun 2008 13:44:06 +0200
Ulrich Mueller [EMAIL PROTECTED] wrote:

  On Thu, 5 Jun 2008, Matthias Schwarzott wrote:
 
  With #1 the user will get a message about the blockers immediately.
  With #2 his emerge (maybe of many packages) will needlessly die
  when it reaches your package.
 
  With #1 user will get no message, as neither the user nor the
  package manager know of the merged package that should be emerged.
 
 So nothing depends on it that would pull in the new package? Now I see
 what your problem is. ;-)
 
 Isn't it possible to package.move -server or -client to the new
 package?

Assuming you're talking about global updates commands: Don't use it
for this kind of use case. The move command just renames a package in
vdb, and using it for anything that goes beyond a simple relocation in
the tree _will_ result in problems later on (we've been there already).

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] [GLEP56] USE flag descriptions in metadata

2008-06-05 Thread Marius Mauch
On Thu, 05 Jun 2008 15:42:24 -0400
Doug Goldstein [EMAIL PROTECTED] wrote:

 All,
 
 Here's a GLEP for the addition of USE flag descriptions to package 
 metadata. It does not address any future ideas that others may have
 had or suggested. It merely gives developers the necessary tools to 
 document their USE flag usage it better detail on a per package basis.
 
 An clearly motivation explanation that I didn't add, which I'm going
 to add once I send this is the fact that as per the QA Project, 
 use.local.desc can not contain a USE flag that already appears
 globally in use.desc. This would allow a description for that USE
 flag to be contained in the metadata.
 
 http://www.gentoo.org/proj/en/glep/glep-0056.html
 
 I encourage any and all _technical_ feedback.

Doesn't include any statement about compability with existing tools or
how it's related to use.local.desc (replacement, extension, ...)

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] [GLEP56] USE flag descriptions in metadata

2008-06-05 Thread Marius Mauch
On Thu, 05 Jun 2008 17:01:00 -0400
Doug Goldstein [EMAIL PROTECTED] wrote:

 Marius Mauch wrote:
  On Thu, 05 Jun 2008 15:42:24 -0400
  Doug Goldstein [EMAIL PROTECTED] wrote:
 

  All,
 
  Here's a GLEP for the addition of USE flag descriptions to package 
  metadata. It does not address any future ideas that others may have
  had or suggested. It merely gives developers the necessary tools
  to document their USE flag usage it better detail on a per package
  basis.
 
  An clearly motivation explanation that I didn't add, which I'm
  going to add once I send this is the fact that as per the QA
  Project, use.local.desc can not contain a USE flag that already
  appears globally in use.desc. This would allow a description for
  that USE flag to be contained in the metadata.
 
  http://www.gentoo.org/proj/en/glep/glep-0056.html
 
  I encourage any and all _technical_ feedback.
  
 
  Doesn't include any statement about compability with existing tools
  or how it's related to use.local.desc (replacement, extension, ...)
 
  Marius

 It purposefully does not. XML is an extensible language that allows
 for this type of expandability. Current tools should be able to
 validate that adding these tags are valid if they appear in the DTD.
 However, if those tools do not handle those tags they should not do
 anything with them, hence the nature of XML.

I was more talking about tools that process use flag information
(equery, euse, ufed, ...).

 The replacement of use.local.desc would necessitate a change to any
 and all tools which use that file and require them to support the new
 XML data. This of course introduces a chicken/egg issue. I have
 mentioned to infra the possibility of having a pre-rsync process that
 condensed all metadata.xml's into a use.local.desc that would be part
 of rsync data but not part of CVS. This could be written as a CVS
 hook to see when a metadata.xml was touched and run the utility
 appropriately.
 
 But again, this is outside the scope of this GLEP, whose purpose
 merely is to provide a way to document this.

I disagree. At the very least state that the GLEP does not replace
use.local.desc if that's the intention, and which location is
supposed to take priority if a flag is defined in both. Otherwise
different tools will use different rules and generating inconsistent
results. And there are many tools affected by this ...

Marius

PS: I like the general idea, but as long as compability issues are
completely ignored by the GLEP I have to oppose it.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)

2008-05-31 Thread Marius Mauch
On Sat, 31 May 2008 04:26:39 -0700
Alec Warner [EMAIL PROTECTED] wrote:

 Just to jump in quickly; this thread is about adding --as-needed to
 the default CFLAGS.  To get this accomplished you need to:
 
 A.  Convince the portage developers to put it in
 make.conf/make.defaults.

Wrong.

We don't control make.conf (the user does) or make.defaults (profile
maintainers do). 
We only control make.conf.example (which these days
only serves as documentation) and make.globals (which isn't the right
place for any arch-specific stuff, and CFLAGS are arch-specific by
definition).

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)

2008-05-30 Thread Marius Mauch
On Sat, 31 May 2008 00:47:44 +0300
Mart Raudsepp [EMAIL PROTECTED] wrote:

 Portage developers - is there anything we should do to get --as-needed
 to make.conf.example and other places, beyond fixing the known bugs on
 the appropriate bug tracker?

make.conf.example is no big deal, that's just documentation, though
personally I'd prefer to remove the toolchain (CHOST, *FLAGS) stuff from
there so we don't have to maintain all the arch-specific diffs.

If you want to really enable it by default you'll have to persuade the
profile maintainers to add it into the appropriate make.defaults.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: Should preserve-libs be enabled by default?

2008-05-29 Thread Marius Mauch
On Thu, 29 May 2008 09:28:16 +0100
Mike Auty [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Marius Mauch wrote:
 | The purpose of this is to keep the system operational after library
 | upgrades until all affected packages could be rebuilt and to
 | simplify the process, not to avoid the rebuilds.
 
 I couldn't find it mentioned in your email, but if portage is
 effectively doing reference counts, what happens when its reference
 count gets to 0?  Once no ebuilds rely on the old library is it
 removed automatically, or do the you need to rebuild these message
 just go away?

They are removed automatically.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?

2008-05-29 Thread Marius Mauch
On Thu, 29 May 2008 11:02:55 +0200
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote:

 Marius Mauch [EMAIL PROTECTED] writes:
 
 As much as we want preserve-libs to be an all-curing magic, it's
 not. When you need to replace a library you need to do so _for all its
 users at once_, if you allow it to be gradually you're opening the
 hellgate of symbol collision.

That's what `emerge @preserved-rebuild` does, or do you mean something
different?

 My solution would be to disallow _building_ anything that is or
 depends directly or indirectly on a package on the set until it is
 removed, or at the request of merging mickeymouse, depending on
 bar, re-emerging libfoo first, and bar if the user is not using
 --as-needed (checking the NEEDED lines).

Well, with preserve-libs the situation is this (using your example):
- user upgrades expat, portage keeps libexpat.so.0 around
(some packages might now be linked against both versions if the session
included other packages as well)
- emerge tells the user to rebuild all affected packages (affected =
contains libexpat.so.0 in NEEDED, so includes both libfoo and bar) by
using `emerge @preserved-rebuild` (in the future this could also be done
automatically, but that won't be before 2.2 final)
- when all affected packages have been rebuilt (so their NEEDED entries
don't contain libexpat.so.0 anymore) libexpat.so.0 is automatically
removed

So, if I understand you correctly (probably not), you want portage to
prevent the user from building any packages depending on any affected
package before the last step is completed?

 With all due respect to everybody, the right course of action here has
 to be selected by people who knows how the runtime linker works,
 symbol collision and all the rest, as that's what's at stake here.

Whoever that is is welcome to voice his opinion here, that's the point
of this thread after all.

Marius
--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] RFC: Should preserve-libs be enabled by default?

2008-05-28 Thread Marius Mauch
As portage-2.2 is about to be unmasked into ~arch soon (there is one
weird bug to solve before) it's time to ask for some input on one of
the important new features, FEATURES=preserve-libs.

(if you're already familiar with it you can skip this paragraph)
Simply said, when this feature is enabled portage keeps track of all
installed libraries and binaries linked against them, and if a package
upgrade would remove a library that's still in use portage will keep
the library around, owned by the new version and also registered in a
separate file. There is also an internal package set that can be used
to rebuild all packages linked against libraries preserved in this way,
and the user is notified after each emerge operation that he should do
that (the example is from an expat downgrade in case you wonder about
the versions): 
!!! existing preserved libs:
 package: dev-libs/expat-1.95.8
 *  - /usr/lib64/libexpat.so.1
 *  - /usr/lib64/libexpat.so.1.5.2
Use emerge @preserved-rebuild to rebuild packages using these libraries

The purpose of this is to keep the system operational after library
upgrades until all affected packages could be rebuilt and to simplify
the process, not to avoid the rebuilds.

Now the question is if this behavior should be enabled by default?

In the existing prereleases it has been enabled to get some real-world
testing, and it's been quite effective, though there are still a few
issues to be worked out (e.g. if libraries are moved between packages).
And no doubt a few more bugs will turn up over time.
Also it is not going to be a perfect solution against all runtime link
errors, but if enabled it should eliminate the need for revdep-rebuild
in most cases.
One concern raised by some people is that it might cause old libraries
with security issues to stay on the system for eternity even though
the package was upgraded, and eventually be preferred by new builds.
I can't rule this out completely but thinks it's very unlikely, as
preserved libraries are specially tracked and the user is notified
about their existance after every emerge operation (similar to glep42
news). And new builds shouldn't find them as the unversioned .so
symlinks ar going to point to the current versions.
So personally I'm not too worried about this concern becoming reality,
but I can understand if others are.

So, do you think it should be enabled by default?

Marius

PS: Obviously, if you haven't tested portage-2.2 yet, now would be a
good time.

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: About herds and their non-existant use

2008-05-23 Thread Marius Mauch
On Thu, 22 May 2008 08:05:07 +0200
Tiziano Müller [EMAIL PROTECTED] wrote:

 While I think the herds concecpt is somewhat useless, I'd rather like
 to see something like this instead:
 
 maintainer
   teamfoobar/team
 /maintainer
 
 This makes it clear that it is a team instead of a person (where
 name would have been used)
 
 And the herds.xml isn't completely useless, but I'd rather name it
 teams.xml and list the teams there. This way we can validated the
 team mentioned in team.../team against the list of available
 teams and make sure the complete thing is valid (can be done in the
 current metadata.dtd or in a future metadata.xsd).
 (If we're gonna re-use the email.../email element for the
 herd-alias, we can never validate it. And I'm personally for the: if
 something can be automatically validated, it should be)

Hmm, in that case maybe it's be possible to use a similar system for
devs, e.g. 
maintainer
  devgenone/dev
/maintainer
and only use the email element for non-dev maintainers and upstream
contacts. Anyway, as long as we use the same tag to list both
individual and group maintainers it would be an improvement IMO.

  This would have a number of benefits:
  - you no longer have to look at herds.xml to determine the actual
  maintainers of a given package (as herd-name and associated mail
  alias don't always match)
 I don't consider this much of a problem. You just have to know
 xsl/xpath to cope with this as generating the list of mail-aliases to
 assign this bug to is a simple xsl-transformation...
 When we use XML we can also use the right tools to handle them, can't
 we?

My point is that it's an unneccessary extra step Sometimes you only
have the raw XML file. Anyway, that's maybe more of a policy problem,
we just need to enforce 'name == mail alias' (or would that be such a
horrible requirement?)

  - it would simplify bug assignment rules, as the current case
  where a package has both a herd and a maintainer tag in
  metadata.xml no longer exists
 It doesn't. You can still have more than one maintainer in there.
 We'd have to introduce an attribute to mark the primary maintainer.

Relying on the order of maintainer elements doesn't work because ...?
(Assign to first listed maintainer, CC others)

  - only have one location where members of a given team are listed,
  currently it's possible and quite likely that herds.xml and the
  mail alias files get out of sync
 Well, we need one location where the name of the team is mapped to the
 actual mail-alias. But I don't get what you're trying to say...

Why do you need to separate the name from the alias? Sure, sometimes
there are technical reasons why you can't use your preferred name as
mail alias (when it matches a system account), but then you can just
adjust your name a bit (e.g. adding some suffix).
Don't know if you're aware of this, but the separation of herd names
and aliases of the herd maintainers has always been something that
bug-wranglers complained about.
But my main issue is that currently we have multiple unconnected
locations where teams are defined, some more and some less important:
- herds.xml
- project pages
- mail aliases
- cvs access groups
- role definitions in ldap/roll-call
So when someone wants to change his roles there are a lot of places to
care about, and it's likely that one or more are forgotten and things
get out of sync, so you have different views of who actually belongs to
a group depending on what source you use. Don't know if it has improved
in the last years, but it used to happen quite often that herds.xml was
completely out of sync with reality simply because it didn't
really affect anything (now that jeeves is using it it's probably
become a bit better).
Ideally we could list that information in just one authorative
location, but that's not feasable for technical reasons, but if we can
eliminate one source (or auto-generate it from another source) the
problem is already reduced quite a bit. And herds.xml is IMO the most
likely candidates for that, but there are of course also other ways to
improve the situation.

Marius
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: About herds and their non-existant use

2008-05-23 Thread Marius Mauch
On Fri, 23 May 2008 14:07:41 +0200
Tiziano Müller [EMAIL PROTECTED] wrote:

 Santiago M. Mola wrote:
 
  On Fri, May 23, 2008 at 10:39 AM, Tiziano Müller
  [EMAIL PROTECTED] wrote:
  Marijn Schouten (hkBst) wrote:
  While we're changing things around, perhaps we can then also
  standardize the mail alias to [EMAIL PROTECTED]
  What Marius is saying though is that there are two files that
  handle people and their herds. One XML for saying who is in a
  herd and one for each herd mail alias on woodpecker with a list
  of developer email prefixes.
 
  Which could be generated out of the XML file, right?
 
  
  It could, but it would be nice to preserve a method for allowing
  lurkers on aliases.
 
 I'm sure something like this should be possible:
 
 ### AUTOGENERATED PART, DO NOT EDIT ###
 ...
 ### AUTOGENERATED END ###
 
 ### Add additional aliases here:
 ...

When you want to generate mail aliases from an XML file I'm quite sure
you could list lurkers in the XML file by tagging them somehow
(attribute or different element name). The main thing is to have one
authorative location.

Marius
--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: [gentoo-project] About herds and their non-existant use

2008-05-21 Thread Marius Mauch
Moving the discussion to -dev per leios request.

On Wed, 21 May 2008 23:42:19 +0200
Marius Mauch [EMAIL PROTECTED] wrote:

 As this topic jus came up in #-dev, and most people there seemed to
 agree with me I thought it might be worth to bring this topic up
 again. The topic is that I think that the whole 'herd' concept we're
 using is a huge mess and should be removed. Now before eveyone starts
 screaming, lets look at what this concept actually is, as many people
 are quite confused by it:
 
 1) a herd is a group of packages (not a group of people)
 2) the herds.xml file is used to assign people and mail aliases as
 maintainers of a given herd. Unfortuntely the syntax there give
 the impression that those people/mail aliases actually form the herd
 3) the herd tag in metadata.xml is used to assign a package to a
 certain group.
 4) the maintainer tag in metadata.xml can be used to assign
 individual maintainers for a package in addition to/instead of the
 herd maintainers
 5) the combination of 2), 3) and 4) is used to determine the
 maintainers of a given package
 
 Now most people will be familiar with 5) to some degree, and that is
 actually the only valid use case for the herd concept that I'm aware
 of. Or has anyone some use case where you'd like to know what herd a
 package belongs to, but don't care about by whom that herd is
 maintained?
 If we can agree that this is the only real use case for the herd
 concept, then I think the concept is quite useless as it's just a
 redundant layer of indirection. You could just list mail aliases
 directly as maintainers, without having to consult herds.xml first.
 
 This would have a number of benefits:
 - you no longer have to look at herds.xml to determine the actual
 maintainers of a given package (as herd-name and associated mail alias
 don't always match)
 - it would simplify bug assignment rules, as the current case where a
 package has both a herd and a maintainer tag in metadata.xml no
 longer exists
 - eliminate confusion about what a herd actually is
 - only have one location where members of a given team are listed,
 currently it's possible and quite likely that herds.xml and the mail
 alias files get out of sync
 - as others said in #-dev: it makes sense ;)
 
 Now there of course are a few things to consider:
 - obviously, some tools, docs and processes would have to be updated,
 but that's always the case with changes
 - someone said that it might no longer be obvious if a package is
 maintained by an individual or a group of people. But is that really
 necessary? And it's not even obvious now, as some herds are maintained
 by a single person.
 - when I brought this up several months ago it was mentioned that
 sometimes people want to be on the mail alias of a herd, but don't
 want to be listed as members (and therefore be responsible). But that
 can likely be just implemented by some kind of blacklist in the
 relevant tools instead of using this whole indirection layer all the
 time.
 
 So, what do you think? Is there some benefit in keeping this concept,
 or can we live without it and make life simpler for everyone?
 
 Marius
 
 -- 
 Public Key at http://www.genone.de/info/gpg-key.pub
 
 In the beginning, there was nothing. And God said, 'Let there be
 Light.' And there was still nothing, but you could see a bit better.


-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] [PATCH] Repoman subversion support

2008-05-13 Thread Marius Mauch
On Mon, 12 May 2008 20:01:34 +0200
Fabian Groffen [EMAIL PROTECTED] wrote:

 After a short discussion on #-portage, here a feature patch from the
 prefix branch, diffed to the trunk, irrelevant hunks removed.
 
 Antarus once was working on factoring out the vcs bits of repoman into
 pym/repoman/utilities.py, but he never finished it.  I'm willing to
 give that some more time, provided it'll end up in the trunk.  Sofar,
 here's the svn patch that we tested extensively in Prefix ;)  I still
 believe that it has a significant value for non-Prefix users
 (overlays...), even though the code doesn't deserve any price for its
 beauty.  I'd say it fits nicely with large chunks of Portage :p

Merged in r10325 with some minor changes (removed the 'svn update' bit
until someone remembers why exactly it's there, skip the commit
optimization for svn regarding Manifest regeneration, unify isVcs and
vcs variables)

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Moving some packages around

2008-05-11 Thread Marius Mauch
On Mon, 12 May 2008 02:58:55 +0200
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote:

 - bison and flex should get out of the system package set, what
 clearer than moving them out of sys-*?

system and the sys-* categories don't have much of a relationsship,
so that's no argument IMO.

 Yes these are a lot of moves, sincerely I think sys-* categories are a
 bit bloated as they are, and I suppose we should start moving the
 things around rather than waiting forever ad ever..

I don't consider that to be a valid reason when looking at the
following numbers:

$ ls -1 /srv/portage/porttree/dev-util/ |wc -l
265
$ ls -1 /srv/portage/porttree/sys-devel/ |wc -l
41

~40 packages isn't much for any category, if you really want to
relocate packages you could just as well eliminate the entire category.

Marius
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] escaping variables in sed expressions

2008-04-15 Thread Marius Mauch
On Tue, 15 Apr 2008 16:17:54 +0200
Frank Gruellich [EMAIL PROTECTED] wrote:

 * Santiago M. Mola [EMAIL PROTECTED] 15. Apr 08:
  On Tue, Apr 15, 2008 at 1:14 PM, Marijn Schouten (hkBst)
  Currently is use ':' as sed delimiter when paths are involved. I'd
  also like to hear from you about proper delimiters if you think ':'
  is not safe enough.
  
  AFAIK, the only corner case which would make this fail would be
  Windows paths (C:/gentoo-prefix).
 
 Even though it's probably stupid to use it, but ':' is a valid
 character within a path.  I've no solution for this problem, however.

Valid maybe (but then pretty much every character is valid), but colon
is used as path delimiter in many other contexts (e.g. $PATH) so it's
rather unlikely to be used.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-portage-dev] BNF for DEPEND in EAPI0 and EAPI1

2008-04-14 Thread Marius Mauch
On Sun, 13 Apr 2008 20:04:41 +0200
Björn Michaelsen [EMAIL PROTECTED] wrote:

 Hi there,
 
 I worked through the current PMS and tried to formalize the grammar
 for DEPEND a little better. Maybe someone could have a look at it and
 check it for correctness. It could even become part of the gentoo
 development docs or be an appendix to the PMS. The other grammars
 (SRC_URI etc.) should be fairly easy.
 
 Any comments?

Offhand the 'package name' part is wrong/incomplete, pretty sure even
PMS says that they can't start/end with underscores or dashes (it's a
real PITA to get it right).
Haven't really read the non-terminals section as it's hard to read in
this form, using EBNF or some markup language might help with that.

Marius
--
gentoo-portage-dev@lists.gentoo.org mailing list



[gentoo-dev] changes to staffing-needs page and project pages

2008-04-02 Thread Marius Mauch
Since a few weeks ago project pages can contain a new recruitment
section to list open positions within the project that require fresh
blood (thanks to neysx for implementing this). Historically those were
only listed centrally
http://www.gentoo.org/proj/en/devrel/staffing-needs/index.xml, which
had a number of problems (limited visibility, unclear responsibility)
But as a central page also has advantages that page has been updated to
collect the recruitment sections from project pages and list them all
in one place (again thanks to neysx for the implementation).

I hope that this new feature will help us to better communicate where
users can help the project and improve our recruitment process.

Marius

PS: people with existing entries on the old page have been notified a
few weeks ago with the offer to migrate their entries, and only when
people replied have their entries been migrated.

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] Re: querying whether pkg is installed with version X or upwards (atom syntax) (re-post)

2008-03-26 Thread Marius Mauch
On Wed, 26 Mar 2008 12:07:13 +0200
Amit Dor-Shifer [EMAIL PROTECTED] wrote:

 reposting, hoping for a reply this time.
 Thanks,
 Amit
 
 Amit Dor-Shifer wrote:
  emerge features syntax for installing a package according to certain
  bounds. This is referred to in the manpage as atom specification.
 
  I'm wondering whether equery has the same feature for querying.
  E.G: I'd like to be able to ask:
 
  equery l '=app-misc/my-pkg-1.1'
 
  I'd expect the listing to be empty when my-pkg is not installed, or
  is installed by of version less than 1.1.

Well, most equery subcommands support the same atom syntax, just 'list'
and 'size' apparently don't implement it, as those support regular
expressions instead.

Marius
-- 
gentoo-portage-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Remaining PMS todo list etc

2008-03-19 Thread Marius Mauch
On Wed, 19 Mar 2008 18:32:41 -0600
Ryan Hill [EMAIL PROTECTED] wrote:

 Ciaran McCreesh wrote:
  There's an updated, pre-built copy of current PMS at:
  
  http://dev.gentoo.org/~spb/pms.pdf
 
 Thanks for keeping up with this.
 
  * 174335: Some ebuild use FEATURES. Can we get them to stop doing
  that, or do we have to force package managers to emulate it?
 
 We seriously need a PM-independent way of saying run the testsuite,
 run the testsuite with user privledges, and run the testsuite with
 root privledges if you can, otherwise forget it.  Also required is
 the ability to make test failures non-fatal on a per-package basis,
 though this probably has nothing to do with the PMS.

How about just checking EUID == 0 in src_test and skip the tests (with a
ewarn message) if it doesn't match your needs?

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: RFC: New build types

2008-03-19 Thread Marius Mauch
On Thu, 20 Mar 2008 03:59:01 +
Steve Long [EMAIL PROTECTED] wrote:

 Rémi Cardona wrote:
 
  What would be the point of such a change? What problem are you
  trying to solve or to improve?
 
 Secondly efficiency; in the case of a pbuild it could be run from
 within the PM; for something like a jbuild it would use the native
 tools and existing libraries like ANT. For hbuild it would tie into
 Cabal. While these may be used already, we go from PM - BASH -
 LangX. I'm just saying give the _option_ to leave out the BASH bit
 when you have mature tools in langX.

Generally those build tools are designed to be invoked from the shell,
not from within their implementation language. Of course you can invoke
use a distutils setup.py script from within a python interpreter, but
that's not how it's designed to be used and will probably end up being
more complicated to handle than invoking it from the shell.

Maybe it's 1% or 2% faster, but that's not worth the additional
complexity.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] Re: [gentoo-qa] splitting up package.mask

2008-03-15 Thread Marius Mauch
On Sat, 15 Mar 2008 07:45:19 -0400
Mike Frysinger [EMAIL PROTECTED] wrote:

 i dont see it being any different from an ebuild declaring its own
 KEYWORDS. if you want to be lazy, then have a magic KEYWORD: +pmask.

What's wrong with KEYWORDS= ? (I'm not saying it's the perfect
solution, just looking for specific requirements)

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] Re: [gentoo-qa] splitting up package.mask

2008-03-15 Thread Marius Mauch
On Sat, 15 Mar 2008 01:34:24 -0700
Alec Warner [EMAIL PROTECTED] wrote:

 On 3/14/08, Mike Frysinger [EMAIL PROTECTED] wrote:
  On Friday 14 March 2008, Alec Warner wrote:
On 3/14/08, Mike Frysinger [EMAIL PROTECTED] wrote:
 i think the real solution here is allowing masking in a package
   
 
   You want to add a metadata key and cache it you mean?
 
 
  i dont care terribly much about the logistics, just the results.
  as long as an ebuild can declare itself masked, it sounds good to
  me.
 
   this doesnt preclude the other ideas as there are often times
  where you want to have 1 global package mask piece (like large
  package set bumps ... so X or KDE or GNOME or ...).
 
  -mike
 
 
 
 [-gentoo-qa, +gentoo-portage-dev]
 
 Original thread was splitting up package.mask entries.
 
 Genone notes the code to do this already is basically in already (we
 just don't invoke it for $PORTDIR/profiles afaik).
 
 Genone, do we use existing code for package.mask (ie if we switch from
 a file to  a dir will it break existing versions?  I am unsure if we
 used the directory code for $PORTDIR/profiles/*


The handling code for all package.mask files is identical, in
particular they all support recursion (just search for package.mask
in portage/__init__.py).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

2008-03-05 Thread Marius Mauch
On Wed, 5 Mar 2008 22:41:58 +0530
Anant Narayanan [EMAIL PROTECTED] wrote:

 Hi,
 
  If you have something you'd wish for us to chat about, maybe even
  vote on, let us know !  Simply reply to this e-mail for the whole
  Gentoo dev list to see.
 
 If it's not too late for this month's meeting, I'd like to discuss
 the possibility of including a new post in our developer base -
 the package maintainer.
 
 a) The requirements to become a package maintainer for Gentoo may be  
 lesser than that of the full-fledged developer.

Please elaborate on how a full.fledged developer would differ from a
package maintainer technically. What requirements and/or
priviledges do you think could be reduced?

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Proposal for (next year's probably) SoC

2008-03-05 Thread Marius Mauch
On Wed, 05 Mar 2008 22:07:37 +0100
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote:

 The tasks are minor tasks that don't require a lot of time at hand,
 but gives a good way to judge if the person is in for the experience
 or the money, and might be able to cut the deal even for Gentoo devs
 if that is really wanted.
 
 How to implement it for Gentoo? Well I think we have the tool already:
 Bugzilla. We just need to add a keyword SOC_QUALIFICATION_TASK; when a
 developer think of a working qualification task, he can add the
 keyword and CC the soc team or something like that.

While the concept itself is a good one, I think that such qualification
tasks have to be related to the proposed project to be of real use.
With a single codebase and a single implementation language like
ffmpeg a single list of tests can work, but Gentoo has many aspects that
require completely different skills. 
For us a generic list of tasks you may help in testing the motivation,
but it hardly helps to assess the technical skills of a student to
complete e.g. a webapp project if he fixes some ebuilds or writes a
patch for a random package.
I think we should just require students to list some references related
to their project in their application and have the relevant mentors
check those. If a student can't find some references on his own he can
the soc team/mentors/devs for something. In fact I think what is
needed most is improved communications instead of random tests.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] please explain use of hooks

2008-03-02 Thread Marius Mauch
On Sun, 2 Mar 2008 11:18:39 +0100
Jonas Bernoulli [EMAIL PROTECTED] wrote:

 And if not the handbook this should really go into the portage
 manpage.
 
 bashrc
 
 If  needed, this  file can  be  used to  set up  a
 special  environment for  ebuilds,  different from
 the standard root  environment.  The syntax is the
 same as for any other bash script.
 + One thing you can do here is define phase hooks.
 + A phase hook function name begins with a pre_ or post_ prefix to
 indicate that it will be called before or after one of the ebuild
 phases. The prefix is followed by the name of the ebuild function that
 the hook will be associated with. + For example, a hook named
 pre_src_compile will be called before src_compile, and a hook named
 post_src_compile will be called after src_compile.

Care to write a patch? (nobody likes to edit manpages)

 postsync.d should also be documented there.

No, as it isn't used by portage itself.

 All in all now that I have looked at the documentation installed with
 portage I think it is obsolete. Not in the sense that it is outdated
 but everything in it is documented elsewhere already or should be
 moved there.

Well, it's horribly incomplete and a work in progress. Eventually it
will replace the manpages (in the sense that manpages will be generated
from the same source). And authorative documentation (which isn't
exactly the same as a specification) should be kept with the
implementation, and that's not the case with the dev handbook/manual.

 If some developers an the list agree with me and welcome me to do so
 then I could file a bug(s) for those changes.

No.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Google SOC 2008

2008-02-28 Thread Marius Mauch
On Tue, 26 Feb 2008 10:32:45 -0800
joshua jackson [EMAIL PROTECTED] wrote:

 All,
 
 Google is once again doing the summer of code for students. I'm
 helping organize it this year and am putting out a call for some
 elements to help.
 
 1) We need idea's for things to do. Diego has already submitted some
 via his blog which have been taken into consideration.
 2) We need mentors, so far confirmed I have: Diego and Saleem

Something nice would be to reimplement revdep-rebuild as a package set
for portage-2.2 (the ground work for that is already done, but most of
the processing logic from revdep-rebuild is still missing).
Unlike most other portage-related ideas this one doesn't require a huge
understanding of portage internals, and I'd be willing to mentor
applicants for this.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Keyword amd64 - x86_64

2008-02-21 Thread Marius Mauch
On Wed, 20 Feb 2008 19:40:23 +0100
Fabian Groffen [EMAIL PROTECTED] wrote:

 On 20-02-2008 19:23:26 +0100, Marius Mauch wrote:
  On Wed, 20 Feb 2008 12:59:11 -0500
  William L. Thomson Jr. [EMAIL PROTECTED] wrote:
  
   Please excuse my ignorance if this is a naive comment or has been
   brought up before. With all the non amd processors now with 64bit
   support. amd64 as a keyword seems a bit odd and off maybe.
   
   What's the possibility of switching amd64 to x86_64?
   
   Unless the work to do that is greater than the value of the
   change.
  
  As the benefit is close to nothing IMO the required work is
  definitely greater by several orders of magnitude.
 
 Well, that depends a bit.  We basically introduced x64 a shorthand,
 and changed some keywords in prefix, of which I just finished the
 transition.  It's basically just setting the new keyword in the
 profiles, and then gradually changing the keywords, e.g. on a repoman
 commit.  That's sort of how I did it.  You don't need any Portage
 support, IMHO.

- sorry, but comparing prefix with its limited and (I assume)
technically skilled userbase that is used to change to the main tree
where people sometimes don't update their system for years is like
comparing apples and oranges
- you forgot the necessary updates to documentation and renaming of
other amd64 related stuff, only changing the keyword would make things
worse IMO
- what I wanted to say is that any amount of work required to realize
this is greater than the benefit
- x64 is IMO the worst name for the architecture (originally a MS
marketing term later adopted by Sun, looks too similar to x86, name
doesn't make any sense really if you compare it to x86)

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Keyword amd64 - x86_64

2008-02-20 Thread Marius Mauch
On Wed, 20 Feb 2008 12:59:11 -0500
William L. Thomson Jr. [EMAIL PROTECTED] wrote:

 Please excuse my ignorance if this is a naive comment or has been
 brought up before. With all the non amd processors now with 64bit
 support. amd64 as a keyword seems a bit odd and off maybe.
 
 What's the possibility of switching amd64 to x86_64?
 
 Unless the work to do that is greater than the value of the change.

As the benefit is close to nothing IMO the required work is definitely
greater by several orders of magnitude.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass

2008-02-13 Thread Marius Mauch
On Wed, 13 Feb 2008 01:44:22 +0200
Petteri Räty [EMAIL PROTECTED] wrote:

 What do you think about adding support to base.eclass for running 
 eautoreconf?
 
 so instead of
 
 src_unpack() {
   unpack ${A}
   cd ${A}
   eautoreconf
 }
 
 would just add
 
 EAUTORECONF=yes
 inherit base

How many packages do you think could directly benefit from this?

Marius
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] new portage categories

2008-02-07 Thread Marius Mauch
On Thu, 7 Feb 2008 12:56:43 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:

 On 15:12 Wed 06 Feb , Alec Warner wrote:
  On 2/4/08, Jonas Bernoulli [EMAIL PROTECTED] wrote:
   On 2/4/08, Donnie Berkholz [EMAIL PROTECTED] wrote:
On 20:11 Mon 04 Feb , Jonas Bernoulli wrote:
 Thinking about it again I would say tags and categories just
 fulfill different purposes. Tags can not replace categories
 but might be a useful extension to categories for the tasks I
 described, not more not less. They are not better or worse,
 just different:)
   
Why don't you think they can replace categories?
  
   Quick answer: Because there are packages with the same name in
   different categories. How would tags deal with that?
  
  Techincally you could enforce UNIQUE(pkg,[tags]), I agree thats a
  poor constraint though ;)
 
 I would probably print the ambiguous package name, with info on each 
 package, and a list of tags unique to each that could be used to
 specify which one you want. Perhaps a numbered list too.

That only works for the user interface, not so good for depend strings,
config files and pretty much everything else.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Changes to some profiles

2008-02-02 Thread Marius Mauch
On Sat, 02 Feb 2008 09:50:21 +0100
Rémi Cardona [EMAIL PROTECTED] wrote:

 Vlastimil Babka a écrit :
  How about just some elog If you use make install, emerge
  --noreplace debianutils in the kernel's postinst or something.
 
 Bellow is my contribution to this thread :)
 
 Cheers,
 
 Rémi
 
 
 --- kernel-2.eclass   2007-12-17 17:06:02.0 +0100
 +++ kernel-2.eclass   2008-02-02 09:48:25.0 +0100
 @@ -659,6 +659,11 @@ postinst_sources() {
   ewarn For specific information on why this kernel
 is unsupported, please read:
   ewarn
 http://www.gentoo.org/proj/en/security/kernel.xml; fi
 +
 + # display debianutils message
 + echo
 + einfo If you use \make install\ to install your kernel
 to /boot,
 + einfo you will need to emerge \sys-apps/debianutils\
   }
 
   postinst_headers() {

s/einfo/elog/ and people might even read it ;)

Marius
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Move SCMs to their own category?

2008-02-01 Thread Marius Mauch
On Fri, 1 Feb 2008 17:57:39 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:

 On Fri, 1 Feb 2008 12:52:16 -0500 (EST)
 Caleb Tennis [EMAIL PROTECTED] wrote:
  It seems like all source control/revision control programs live in
  dev-util, but they might be better served in something like dev-scm
  or something like that.  I'm thinking things like darcs, git, cvs,
  svn, mercurial, bzr.  Then the slew of packages that depend on them:
  gitosis, bzrtools.
  
  Any objections to this potential move, or comments on a better
  category name?
 
 You might want to ask Seemant (?) why he didn't do the move several
 years back. There were plans to do it, but it never happened for some
 reason -- not sure whether it was just a time issue or whether there
 was something in particular that made it impossible.

IIRC it was because you argued that cvs didn't qualify
as a VCS (as the proposed category name back then was app-vcs)

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] debianutils: system worthy ?

2008-01-28 Thread Marius Mauch
On Mon, 28 Jan 2008 21:43:38 +0100
Matthias B. [EMAIL PROTECTED] wrote:

 What's wrong with making it an optional dependency? Something like a
 useflag 

Because if this would be done consistently we'd end up with several
thousand use flags long term, not really what I'd call managable.
Unfortunately use flags aren't the answer to everything.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] How to force homedir on enewuser

2008-01-18 Thread Marius Mauch
On Fri, 18 Jan 2008 03:46:58 +0100
Hanno Böck [EMAIL PROTECTED] wrote:

 What is the correct way to handle this? I'd suggest that enewuser might get 
 some force-parameter that tells it to delete and recreate the user if it 
 already exists. Thoughts?

Tell the user to do it manually in pkg_setup/postinst. This is
something that IMO shouldn't be done by the ebuild/package manager for
two reasons:
- extreme cornercase, or how often does this come up?
- the system might rely on the current settings in unexpected ways

Marius
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Seeking questions for a user survey

2008-01-16 Thread Marius Mauch
On Wed, 16 Jan 2008 15:09:20 +0100
Arfrever Frehtes Taifersar Arahesis [EMAIL PROTECTED] wrote:

 2008-01-15 15:05 Marius Mauch [EMAIL PROTECTED] napisał(a):
  - what feature would you like most to be implemented in portage?
  (parallel builds, localization, revdep-rebuild integration, overlay sync 
  support, gpg verification
  support, support for non-ebuild repositories, better query tools, 
  interactive user interface)
 
 Other features: USE flag dependencies, repository dependencies.

I've not listed those (and a few others where we know that they are
critical) on purpose.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Seeking questions for a user survey

2008-01-15 Thread Marius Mauch
On Mon, 14 Jan 2008 04:33:48 -0800
Robin H. Johnson [EMAIL PROTECTED] wrote:

 Ok, so per the one discussion in #-dev this evening, I'm looking for
 questions to put on a new user survey.
 
 For style of questions, multiple choice (both pick-one and pick-many) or
 simple integers would be best. However some freeform questions are
 probably going to end up in there anyway. 'Prefer not to answer' and 'I
 don't know' should be available in most questions.
 
 I don't have the original questions on hand right now (but i'm trying to
 get them), so used some classical census questions. Some of the ones I
 threw in are just what came to mind, I'd love to hear more questions and
 more sections.
 
 In the style of census, maybe offering a short form and a long form
 questionnaire would be useful too?
 
 Basic demographics - a bunch of this should probably be optional but 
 recommended
 - Gender (M, F, and the various other forms here)
 - Year of birth
 - # of children??
 - How many years have you been using computers?
 
 Sociocultural information (again, optional stuff):
 - Location (country, and free-form city)
 - Level of education?
 - Job? (type coding this one is hard, and I'd prefer not to have it)
 - Income level

Such questions usually are a reason to not complete a survey for me, and I 
don't see how they are relevant to us (except for maybe location).

 - Do you share your portage tree between systems
 - Do you share your distfiles between systems
 - Do you share your binpkgs between systems

Those should all be multiple choice or at least be more explicit due to 
multiple meanings of share (and in case of binpkgs a I don't use binpkgs 
option should be present as well in some way)

 Portage-related questions:
 (portage team, maybe you can help here?)

(just brainstorming here)
- what feature would you like most to be implemented in portage?
(parallel builds, localization, revdep-rebuild integration, overlay sync 
support, gpg verification support, support for non-ebuild repositories, better 
query tools, interactive user interface)
- do you think that portage has improved significantly over the last 12 months?
- how happy are you with portage in general (scale 1-10)?
- how happy are you with portage documentation (manpages, official online docs, 
...)?
- do you use pkgcore/paludis in addition/in place of portage on Gentoo 
(yes/no/don't know what pkgcore/paludis is)?
- would you be in favor of an automated feedback system to report 
successful/failed package installations for statistical purposes 
(yes/opt-out/opt-in/no)?
- how important is backward compability in the user interface for you (e.g. 
names of commandline options, output format)?

Mind that the survey shouldn't contain too many questions, or many people won't 
complete it IMHO. I guess 10-30 questions might be the sweet spot, if we have 
much more we should run multiple surveys for specific topics spread over time. 
Also can we take measures that such general surveys are repeated at regular 
intervals (once per year/6 months), as a single survey is a nice snapshot, but 
the really interesting thing are the trends evolving over time.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] [RFC] Reducing the size of the system package set

2008-01-10 Thread Marius Mauch
On Tue, 08 Jan 2008 00:42:57 +0100
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote:

 I already ranted about the fact that the dependency tree of our
 ebuilds is vastly incomplete, as many lack dependency on zlib; trying
 to get this fixed was impossible, as Donnie and other insisted that
 as zlib was in system, we shouldn’t depend on it at all. I disagree,
 and I would like to know why we can’t depend on a system package, but
 whatever.

Somewhat related:
http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2575

Marius
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Projects and subproject status

2008-01-10 Thread Marius Mauch
About portage:

Current status:
The portage project is mostly fine, though we've missed my original
plan to release the first 2.2 test versions last year, mostly because
of lack of time on my part. I hope we can fix that within the next two
or three months.
As Paul has already mentioned, the tools-portage subproject definitely
needs more people, or we may just dissolve it completely (it has been a
one man show for some time already). Some people to help with
(technical) documentation would also be useful (manpages, docbook
stuff, ...)

Plans:
- release test versions of portage-2.2, see how all the new stuff works
in practice and adjust things if necessary
- help to fix external tools (including gentoolkit) and documentation to
fully support portage-2.2
- some ideas for the time after 2.2:
  * merge gentoolkit into portage
  * redesign some of the old APIs (dbapi, config) and implement new
ones (query framework)
  * replace revdep-rebuild with a package set
  * implement a new installed-package database
  * new dep resolver (as always ;)
  * new user interface(s)
  * ...

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]

2007-12-31 Thread Marius Mauch
On Sat, 22 Dec 2007 16:43:10 +0100
Piotr Jaroszyński [EMAIL PROTECTED] wrote:

 Hello,
 
 I have updated the GLEP, hopefully it is less confusing now and hence the 
 discussion 
 will be more technical.

Still doesn't address my concerns, namely:
- silently expands the scope of EAPI beyond ebuild contents (which is a
blocker for me)
- doesn't mention compability issues on the dev side (minor)

Marius
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [GLEP] Use EAPI inside ebuild filename (.EAPI-ebuild of different?)

2007-12-31 Thread Marius Mauch
On Thu, 20 Dec 2007 15:50:02 +0300
Peter Volkov [EMAIL PROTECTED] wrote:

 This hack is just to solve portage problem which does not ignore .ebuild
 files which does not follow pkg-ver.ebuild syntax and suggested solution
 is not the only solution. Other possibilities are, which I like more:
 
 1. USE pkg-ver.EAPI-ebuild

Same thing really, just looks even messier IMO.

 2. USE pkg-ver${EAPITAG}EAPI.ebuild
Here ${EAPITAG} is string to simplify parsing EAPI from
version. E.g. EAPITAG could be _eapi or EAPI or something
else.

Isn't backwards compatible in any way.

Marius
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: EAPI definition Was: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-31 Thread Marius Mauch
On Fri, 28 Dec 2007 23:34:44 + (UTC)
Duncan [EMAIL PROTECTED] wrote:

 I understand the ban on non-EAPI-0 features in in-tree profiles, since 
 users could be using old PMs, but it's fine using them in /etc/portage/*, 
 provided one has upgraded to an appropriately compatible PM, correct?

Yes (in case of portage).

Marius
-- 
[EMAIL PROTECTED] mailing list



  1   2   3   4   5   6   >