Hi! On Fri, 15 Jun 2007, Kent Fredric wrote: > On 6/15/07, John R. Graham <[EMAIL PROTECTED]> wrote: > > I occasionally run across a package version dependency issue that cannot > > be elegantly solved by the current dependency syntax. Every time I've > > come across this, it's boiled down to a range. For example, package > > some-cat/foo has the following versions in the tree > > some-cat/foo-4.0.0-r2 > > some-cat/foo-4.1 > > some-cat/foo-4.1.1 > > some-cat/foo-4.1.2-r2 > > some-cat/foo-4.2.1-r5 > > some-cat/foo-4.3 > > some-cat/foo-4.4 > > > > /me votes for rubyesqe range syntax > > some-cat/foo-( s:4.1 .. s:4.2) // start at slot 4.1 , and go upto > and including 4.2 > some-cat/foo-( s:4.1 ... s:4.2) // start at slot 4.1 and go upto, but > not including 4.2 > some-cat/foo-( v:4.1.0 .. v:4.2.0 ) // start at version 4.1.0 and go > upto and including 4.2.0 > some-cat/foo-( v:4.1.0 ... v:4.2.0 ) // start at version 4.1.0 and go > upto , but excluding 4.2.0 > > I know thats probably not possible in a bash env tho, but hopefully > the 'range' concept will give some inspiration, as IMO, having to > specify the ebuild atom name for both upper and lower values is > redundant, and easily missused as lamented by Vlastimil Babka > > /me hides in his corner to avoid abuse from people despising ruby lovers > > /me goes and joins ruby addicts anonymous
As a side note, while we're talking ranged dependencies. It would also be really, really nice to be able to (un)mask ranges in /etc/portage/package.(un)mask. Just my 1.953 Eurocent (adjusted for inflation). Rgards, Tobias -- In the future, everyone will be anonymous for 15 minutes. -- [EMAIL PROTECTED] mailing list