Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 57153 - Support for regex pattern matching in /etc/portage/package.*
Summary: Support for regex pattern matching in /etc/portage/package.*
Status: RESOLVED WONTFIX
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 59893 125977 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-07-15 04:00 UTC by Patrick Borjesson
Modified: 2007-01-28 10:19 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Borjesson 2004-07-15 04:00:02 UTC
I would be nice to have the a more advanced pattern matching in the masking files of portage so that one could write rules such as "sys-kernel/development-sources-.*_rc[0-9]*" in /etc/portage/package.mask. Gives me as a user more control over what gets installed on my system...
Comment 1 SpanKY gentoo-dev 2004-08-02 20:25:06 UTC

*** This bug has been marked as a duplicate of 24469 ***
Comment 2 SpanKY gentoo-dev 2004-08-09 23:31:51 UTC
*** Bug 59893 has been marked as a duplicate of this bug. ***
Comment 3 Andy Lutomirski 2004-08-10 11:11:12 UTC
Maybe I'm missing something here, but this doesn't look like a duplicate of 24469.  24469 wants to emerge a wildcard/regex.  This bug (and mine: 59893) want to change the configuration.

Running something like
ACCEPT_KEYWORDS=~amd64 cd /usr/portage && find gnome-base -mindepth 1 -maxdepth 1 | xargs emerge
does _not_ do what I want.  This will merge all of gnome-base once and leave the system in a state where emerge -uD world is confused, at best.  I want to set it so that a future emerge gnome or emerge -uD world will choose the testing version.

Similarly, I might want to unmask all of KDE 3.3 in one fell swoop.

Am I missing something obvious here?  And, no, I don't consider an ugly shell command that adds entries to package.* for me a solution -- the resulting mess will be completely unmaintainable?

Does anyone object to reopening this?
Comment 4 SpanKY gentoo-dev 2004-08-10 19:39:37 UTC
"sys-kernel/development-sources-.*_rc[0-9]*"

that is equivalent to sys-kernel/development-sources
Comment 5 Patrick Borjesson 2004-08-12 11:31:25 UTC
I just threw a regex together, but if you want to get picky this might be the one I wanted:
sys-kernel/development-sources-[0-9.]*_rc[0-9]*

Btw, the regex I wrote before seems to give the right answer from sed on my machine. Try it your self:

cd /usr/portage/sys-kernel/development-sources;
dir -1 |sed -n -e 's|\(development.*\)\.ebuild|\1|p' |egrep 'development-sources-.*_rc[0-9]*'
Comment 6 SpanKY gentoo-dev 2006-03-12 19:21:17 UTC
*** Bug 125977 has been marked as a duplicate of this bug. ***
Comment 7 Patrick Borjesson 2006-03-13 02:34:53 UTC
I really _really_ don't see how this could be a duplicate of bug #24469. This one has to do with extending the way you can express atoms in portage, so that you for example can mask pre-, beta-, alpha-, rc-releases of packages without using some ugly hack with /etc/portage/package.mask using shell commands. The "solutions" I've seen so far regarding this problem is far from acceptable, and being able to explain portage atoms in regex would ease maintaining /etc/portage/package.* tremendeously. 

I've looked a bit at the latest development code of portage also, and don't think it would be extremely hard to fit in with the restriction framework already there. 
Comment 8 Marius Mauch (RETIRED) gentoo-dev 2006-03-13 03:19:11 UTC
(In reply to comment #7)
> I've looked a bit at the latest development code of portage also, and don't
> think it would be extremely hard to fit in with the restriction framework
> already there. 

Sounds like saviour codebase, which is still a long way to go and therefore not subject for bugzilla yet.
Comment 9 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-03-13 09:04:30 UTC
> I've looked a bit at the latest development code of portage also, and don't
> think it would be extremely hard to fit in with the restriction framework
> already there. 
> 

1) Why would you extend atom support for regex's only in /etc/portage/package.* and not the whole thing?

2) The restrictions framework CAN handle it, but that is no longer actively maintained by Gentoo Developers, you will want to talk to Brian Harring (ferringb@gmail.com) and submit any patches to him directly.

If/When saviour is re-integrated with trunk, this will be re-opened.
Comment 10 Patrick Borjesson 2006-03-13 10:23:15 UTC
(In reply to comment #9)
> > I've looked a bit at the latest development code of portage also, and don't
> > think it would be extremely hard to fit in with the restriction framework
> > already there. 
> > 
> 
> 1) Why would you extend atom support for regex's only in /etc/portage/package.*
> and not the whole thing?

After my last post I thought I made it pretty clear that I'd want this supported at the basic portage level so that it could be used everywhere, just like the ordinary <>=!~ "operators" are now... 

> 
> 2) The restrictions framework CAN handle it, but that is no longer actively
> maintained by Gentoo Developers, you will want to talk to Brian Harring
> (ferringb@gmail.com) and submit any patches to him directly.

Is Brian the only one working on the saviour branch now? I'd thought that increasingly more work would be spent on this line of development instead of the 2.x branch since the framework of saviour seems a whole lot more sane and extensible than the current one. 

I hope I'm not seeing an abandonment of saviour just because Brian resigned as a Gentoo developer. As I see it, there's nothing in the way of him continuing developing portage with Gentoo's current portage developers, just because he left Gentoo as a whole. 
Of course, I'm only a user, so I'll let the Gentoo developers handle internal Gentoo policies ;)
 
> If/When saviour is re-integrated with trunk, this will be re-opened.
 
Ok. The only reason I opened this bug again is because I really didn't see this bug a duplicate of bug #24468, and didn't see the arguments against implementing support for bug #24469 really applying against this bug. 
Comment 11 Brian Harring (RETIRED) gentoo-dev 2006-03-16 04:50:19 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > > I've looked a bit at the latest development code of portage also, and don't
> > > think it would be extremely hard to fit in with the restriction framework
> > > already there. 
> > > 
> > 
> > 1) Why would you extend atom support for regex's only in /etc/portage/package.*
> > and not the whole thing?

Because atom's should not be category restriction version restriction only; they're category restriction, package restriction, optional version restriction.

This moreso comes down to what an atom is- it's used by ebuilds in DEPEND/RDEPEND. Those keys should _not_ be able to specify package globs, its way too much of a mess dealing with it if it were implemented.

So... package.* would support an 'extended' atom syntax that allows globs.

> After my last post I thought I made it pretty clear that I'd want this
> supported at the basic portage level so that it could be used everywhere, just
> like the ordinary <>=!~ "operators" are now... 
See above...

With an extended atom syntax, VersionMatches (<>=!~ prefixes) would still be supported.

> > 2) The restrictions framework CAN handle it, but that is no longer actively
> > maintained by Gentoo Developers, you will want to talk to Brian Harring
> > (ferringb@gmail.com) and submit any patches to him directly.
> 
> Is Brian the only one working on the saviour branch now?
Same # of folks helping as I had before; namely, not enough ;)
If interested in helping out, drop me an email or track me down on irc- got folks helping, but the more people contributing the faster it gets finished.

 
> Ok. The only reason I opened this bug again is because I really didn't see this
> bug a duplicate of bug #24468, and didn't see the arguments against
> implementing support for bug #24469 really applying against this bug. 
24468 is similar to this, although the request differs; both are addressed by the restriction framework.
Comment 12 Marius Mauch (RETIRED) gentoo-dev 2007-01-11 13:20:26 UTC
Reopening for consideration.
Comment 13 Andy Lutomirski 2007-01-12 00:23:01 UTC
Now that we have /etc/portage/package.keywords/somefile, this may not be as important anymore.  Maybe if we had some /etc/portage/shell_script_that_runs_after_sync, we could just have a script autogenerate some of these files after a sync.
Comment 14 Marius Mauch (RETIRED) gentoo-dev 2007-01-28 10:19:42 UTC
See http://bugs.gentoo.org/show_bug.cgi?id=140002#c1