Re: [gentoo-dev] The Python problem
On Mon, 27 Jun 2011 16:49:23 -0400 Mike Frysinger wrote: > if you dont want multiple builds on your system, then dont install > multiple versions of python. > -mike This would be nice, but unfortunately the python maintainer forced 3.x on everyone, despite the fact that nothing uses it and no one really wanted it made the default. So now it's shipped with all the stage tarballs, in addition to 2.7. You've got it whether you want it or not. This is one of the things that needs to be rescinded, along with the python eclass changes. Get everyone down to just one version of python installed. signature.asc Description: PGP signature
Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)
On Tue, 28 Jun 2011 10:16:06 +0400
Peter Volkov wrote:
> But still our documentation explicitly suggests ':' for CFLAGS cases
> and example allows bash substitution.
>
> http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/building/index.html
> see example in "Fixing Compiler Usage" section and text below:
> sed -i -e "s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}:" build.sh
>
> Are there any objections to suggest '|' for CFLAGS, LDFLAGS (see
> attachment)?
I think that also a good idea may be to provide an Makefile example,
showing that often sed is unnecessary, and it's enough to do things
like:
emake CC="$(tc-getCC)" CFLAGS="${CFLAGS}"...
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)
On 28-06-2011 10:16:06 +0400, Peter Volkov wrote: > Are there any objections to suggest '|' for CFLAGS, LDFLAGS (see > attachment)? Not from my side. It's what we've been using so far. > > -When using sed with CFLAGS or LDFLAGS, it is not safe > to use > -a comma or a slash as a delimiter. The recommended character is a colon. > +When using sed with CFLAGS or LDFLAGS, it is not safe to > +use a comma, a colon or a slash as a delimiter. gcc options may > contain gcc -> gcc, ld, ar, etc. > +this characters so sed will fail after bash expansion. The recommended > +character is a vertical bar: '|' (the pipe). -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Are tags just sets?
On Mon, 27 Jun 2011 20:21:29 +0200 Maciej Mrozowski wrote: > > The problems with PROPERTIES=set remain exactly the same as they > > were when it was first proposed. > > Which is? > No, "been there, done that, won't work" is not sufficient. Please > elaborate. You can find and read the original discussion as well as I can. No point in going over exactly the same material all over again since the design hasn't been updated since. > > Uh, I don't see how that's in any way difficult to maintain. > > No, it's not difficult, it's pain in ass to keep a hundred files with > a few thousands lines each up2date with tree changes (pkgmove, cvs > remove). Yes, it could be automated by some crafty cvs hook on > server. However cvs hooks should be the last resort and not a tool to > deal with consequences of broken design. If that were true, you'd be doing the same thing for package.mask... *shrug* If you really think it's that bad, though, go with Brian's proposal, and whilst you're at it, make package.mask and all those other profile files that contain long lists of package names be created the same way. > > > Tag is a property or attribute of package > > That one's highly debatable. > > It's not debatable for those familiar with object oriented design > concept. Clearly it is. Have a look at posts in this thread. Some people insist that tags are properties of ebuilds, some that they're properties of packages, some that they're repository-level properties, and some that they're external, user-level properties. For that matter, ebuilds aren't object oriented. > > Good, so you'll be happy going with what Unix has been using for > > decades then. > > Indeed, with sets in bash (ebuild) format. No point, just like there's no point in package.mask being an ebuild. > > Depends upon what you think the "tags concept" is. We've already > > established that everyone has a different idea of what tags are > > anyway. > > I don't know what's everyone's idea behind the tag, I refer to: > > http://en.wikipedia.org/wiki/Tag_(metadata) Sure, and that's sufficiently vague that all sorts of completely different ideas could be called tags. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Are tags just sets?
On Mon, 27 Jun 2011 16:23:54 -0400 Rich Freeman wrote: > Sets should really be something carefully controlled by the > repository. While I'm fine with having tags in the repository also, > there is talk about giving users ways of supplying them as well. Why? You can have carefully controlled sets for fancy things. But tag sets don't need to be carefully controlled. The way you give users control over tags using sets is to make sets in overlays be merged with sets with the same name in the main tree, and then allow users who feel like it to publish an overlay containing their tags. > Here is how I see tags being used: > > 1. I want a WYSIWYG html editor. > 2. I search for tags like "editor" and "html" and "WYSIWYG" and maybe > even "text." > 3. I check out descriptions and homepages or whatever for a few > likely candidates, and install one or maybe two. $package_mangler search-tags editor html wysywig > What I doubt I'd ever do is just install any package that has anything > to do with text/html editing. Not really a problem. Sets are usable for lots of things, not just installing. They're useful in configuration files, for example -- you'd probably never want to install every X driver either, but you might want to set some options for every X driver. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Thoughts about broken package handling
On Tue, 28 Jun 2011 16:54:43 +1200 Kent Fredric wrote: > Reminds me of the other awkward behaviour I once hit where a package > depends on something that is slotted, and mysteriously uses a middle > version of the things that are slotted, and then breaks with that > version that it for some mysterious reason found a preference for, and > upon removing that particular version of the slot, it uses the most > recent slotted version instead, and then works perfectly. There was going to be a really simple, elegant, ebuild-controllable and provably working fix for that in EAPI 4 in the form of := deps, but they got dropped because Portage couldn't implement it. Which is strange, because it should have been a ten minute job... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)
В Пнд, 27/06/2011 в 17:01 +0200, Fabian Groffen пишет:
> On 27-06-2011 14:08:52 +, Justin Lecher wrote:
> > Please do not use / as seperater when using sed with CFLAGS. I came
> across a bug today where it failed for crossdev. Here the toolchain
> header paths in the cflags and consowuently the seds fail.
This is already documented (see link below).
> Please also don't use ':' as separator, as some platforms have options
> for their toolchain that includes colons.
But still our documentation explicitly suggests ':' for CFLAGS cases and
example allows bash substitution.
http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/building/index.html
see example in "Fixing Compiler Usage" section and text below:
sed -i -e "s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}:" build.sh
Are there any objections to suggest '|' for CFLAGS, LDFLAGS (see
attachment)?
--
Peter.
>From 989cd3700ec0f3aa13cfca08b97c4c461b738883 Mon Sep 17 00:00:00 2001
From: Peter Volkov
Date: Tue, 28 Jun 2011 10:05:17 +0400
Subject: [PATCH] Use | as a separator for sed'ing CFLAGS
/, : is a bad idea per thread on gentoo-dev:
http://archives.gentoo.org/gentoo-dev/msg_654cd9daf2548a524c8a09a82b80916f.xml
---
.../functions/src_compile/building/text.xml|8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/ebuild-writing/functions/src_compile/building/text.xml b/ebuild-writing/functions/src_compile/building/text.xml
index 700f0f1..550ef5c 100644
--- a/ebuild-writing/functions/src_compile/building/text.xml
+++ b/ebuild-writing/functions/src_compile/building/text.xml
@@ -58,15 +58,17 @@ src_compile() {
# We have a weird build.sh to work with which ignores our
# compiler preferences. yay!
-sed -i -e "s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}:" build.sh \
+sed -i -e "s|cc -O2|$(tc-getCC) ${CFLAGS} ${LDFLAGS}|" build.sh \
|| die "sed fix failed. Uh-oh..."
./build.sh || die "Build failed!"
}
-When using sed with CFLAGS or LDFLAGS, it is not safe to use
-a comma or a slash as a delimiter. The recommended character is a colon.
+When using sed with CFLAGS or LDFLAGS, it is not safe to
+use a comma, a colon or a slash as a delimiter. gcc options may contain
+this characters so sed will fail after bash expansion. The recommended
+character is a vertical bar: '|' (the pipe).
--
1.7.3.4
Re: [gentoo-dev] Re: Thoughts about broken package handling
On 28 June 2011 04:44, Graham Murray wrote: > Ciaran McCreesh writes: > >> The fix for that is to slot things properly. You're screwed anyway if a >> preserved library tries to access installed data that has either been >> removed or upgraded to a new format that it doesn't recognise. > > Or some "awkward" packages which when rebuilt will still link against > the preserved library, but if the preserved library is deleted and the > package manually rebuild will link against the new one. > > Reminds me of the other awkward behaviour I once hit where a package depends on something that is slotted, and mysteriously uses a middle version of the things that are slotted, and then breaks with that version that it for some mysterious reason found a preference for, and upon removing that particular version of the slot, it uses the most recent slotted version instead, and then works perfectly. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Are tags just sets?
On 28 June 2011 15:26, Brian Harring wrote: > This is a bit inverted- tagging is fundamentally pkg specific. If we > did as you proposed and I wanted to find out all tags/descriptions for > a pkg, the PM would have to scan every tags file there. > > Additionally, as others have indicated, it sucks have this data tucked > away in another chunk of the tree, away from where the package data > actually is (in cat/pkg/*). > >> Advantages: dead easy to implement, backwards compatible, we need sets >> anyway. >> >> Disadvantages: doesn't use some horribly convoluted system of XML, >> wikis and web 2.0. > > Counter proposal; use what you're proposing as a cache. metadata.xml > is the proper place for this- we store use.local data there for > example, and cache the results of it in profiles/use.local.desc. Via > this vcs concerns are addressed, data locality is preserved, and > multiple modes of lookup are sanely supported. > > Roughly, and this is definitely a rough sketch: > > > tag1 tag2 tag2 tag3 > awesomeness > > > From there, jammed into profiles, a master description list in 'tag: > description' style format. Identifying the eapi is easy enough- just > inspect the atom's that wind up in the tags list. Easy enough. > > Either way... thing everyone admits the current tree format has it's > flaws; strikes me it's better to fit to the standards/conventions of > the repo format as it is now. > > > ~harring > > I agree whole heartedly, I do, really. Ultimately the best design will involve: A. Storing tag data in metadata.xml ( package -> tag association ) B. Developing a tool that aggregates the contents of metadata.xml to produce a cache for the data going the other way ( tag -> package ) People searching for packages that match a tag will thusly be able to read this cached data ( Our primary use case ) and people who want to know what tags a specific package have will read/augment metadata.xml I Believe both these parts are required for the design to be successful. However, both parts have a bit of bike-shedding involved in them, part A of the system requires changes to exisiting structures, and part A requires bike shedding about part B's format. For the sake of simplicity, I'm ( and I believe others ) are simply suggesting we develop part B first. Yes, the initial complications in creating the tag indexes will be somewhat large, but it does mean we can create an early proof of concept that implements a somewhat "usable" tag-search for users without having to really touch portage itself. Once we get that part sorted out and agree upon the general format and requirements of this index/cache, we can then decide how we'll fit it in to metadata.xml -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Are tags just sets?
On Sun, Jun 26, 2011 at 08:02:57AM +0100, Ciaran McCreesh wrote: > Here's a completely different way of doing tags: > > First, standardise sets. We probably want to go with a format along the > lines of: > > eapi = 4 > description = Monkeys > > dev-monkey/howler > dev-monkey/spider > >=dev-monkey/spanky-2.0 > dev-monkey/squirrel > > where eapi has to be on the first line. > > Second, make a bunch of sets named kde-tag, editors-tag, xml-tag, > monkeys-tag etc. This is a bit inverted- tagging is fundamentally pkg specific. If we did as you proposed and I wanted to find out all tags/descriptions for a pkg, the PM would have to scan every tags file there. Additionally, as others have indicated, it sucks have this data tucked away in another chunk of the tree, away from where the package data actually is (in cat/pkg/*). > Advantages: dead easy to implement, backwards compatible, we need sets > anyway. > > Disadvantages: doesn't use some horribly convoluted system of XML, > wikis and web 2.0. Counter proposal; use what you're proposing as a cache. metadata.xml is the proper place for this- we store use.local data there for example, and cache the results of it in profiles/use.local.desc. Via this vcs concerns are addressed, data locality is preserved, and multiple modes of lookup are sanely supported. Roughly, and this is definitely a rough sketch: tag1 tag2 tag2 tag3 awesomeness >From there, jammed into profiles, a master description list in 'tag: description' style format. Identifying the eapi is easy enough- just inspect the atom's that wind up in the tags list. Easy enough. Either way... thing everyone admits the current tree format has it's flaws; strikes me it's better to fit to the standards/conventions of the repo format as it is now. ~harring
Re: [gentoo-dev] RFC: split up media-sound/ category
On 06/27/2011 07:23 AM, Jesús J. Guerrero Botella wrote: > I still don't understand why > > A) you need to build a project, a glep, whatever the course of action > is, I am bad at bureaucracy. > B) you need to code the solution, to fix What? Some people requested a "tags" feature. I'm not sure if "fix" is the best word. Tags will provide a new way to search for packages, that's all. > C) "ls $PORTDIR/whatever-category" is a command that's way simpler > than the one you posted. There are lots of possible approaches. See Ciaran's "Are tags just sets?" approach that is very similar to your suggested symlink approach, except that it represents a tag using a text file containing a list of packages instead of a directory containing symlinks. > XML seems to be the trend, but we should really think a moment, what's > what we are trying to fix? Again, maybe "fix" isn't the best word. I believe that the goal it to provide a new method of searching that is based on tags. > We just needed to add some categories or rename them when someone > started this thread, but now, even when we know we are lacking dev > power in some areas we start arguing that the base concept of our OS > (portage) is wrong, and that we should redo it completely by putting > every ebuild into a directory and tagging them. I would advise against going down the "redo it completely" path, since it's relatively easy to implement a tagging mechanism that will coexist with the existing category framework. > Again, that's not "port-age". Read on ports: > > http://en.wikipedia.org/wiki/FreeBSD_Ports Interestingly, the wiki page that you linked has a link to a project to add tags to the ports collection: http://www.tobez.org/port-tags/ > I don't even use tags for my music collections and now I am going to > be forced to use them to operate my OS. Again, I would advise against going down the "redo it completely" path that this statement implies, given that it's relatively easy to implement a tagging mechanism that will coexist with the existing category framework. -- Thanks, Zac
Re: [gentoo-dev] SHA256 and indention in metadata.xml
On Sunday, June 26, 2011 12:51:53 Nirbheek Chauhan wrote: > On Sun, Jun 26, 2011 at 9:45 PM, Mike Frysinger wrote: > > On Sat, Jun 25, 2011 at 13:51, Nirbheek Chauhan wrote: > >> On Sat, Jun 25, 2011 at 10:54 PM, Mike Frysinger wrote: > >>> On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote: > On Sat, Jun 25, 2011 at 6:16 PM, justin wrote: > > Another question, do we have a rule, how the metadata.xml has to be > > indented? Tabs or n spaces? > > There's no rule, but we should follow the same rule as ebuilds — > indentation should be with a tab that's displayed as 4 spaces in > editors (no expansion of tabs to spaces). > >>> > >>> meh ... let devs do whatever they want > >> > >> Didn't I just say there's no rule? > > > > and if you keep reading, you'll see that you also said "devs should XXX" > > should != must. and all i said was "devs should do whatever they want" > I understand that you're touchy about rules after the whole ChangeLog > mess, but must we debate the nuances of the English language and > contribute to the massive amount of pre-existing bikeshed noise on > this mailing list? i'm really not. i dont why you read more into it than is actually there. if anything, your responses seem a bit more touchy. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: split up media-sound/ category
2011/6/27 Wyatt Epp : > 2011/6/27 Jesús J. Guerrero Botella : >> That still doesn't answer my question anyway: both features (symlinks >> and +65k files on a single dir) are incompatible with fat32. And >> someone said fat32 compatibility is a feature we want (still can't >> guess why, but well, be consequent...). Obviously, we want fat32 >> compatibility when it comes to arguing against symlinks, which have >> always been with us by the way, but that's not important when we talk >> about other things that are not compatible with fat32. > > I'm not sure where you're getting 65k files. Unless I misinterpreted > everything everyone else was saying, every package would still have > its own directory. There are fewer than 20k even with a bunch of > overlays installed. Regardless, you might check the other (other) > thread; I think we're probably going to go quick and > not-necessarily-dirty with sets to get 99% of what we're looking for > almost trivially. Well, someone suggested a flat directory, which I understand as having all the ebuilds in a single directory, that's also why they are talking about the need to make ebuild names unique, to avoid file names collision. > 2011/6/27 Jesús J. Guerrero Botella : >> C) "ls $PORTDIR/whatever-category" is a command that's way simpler >> than the one you posted. >> > It's also fundamentally broken because one package can only be in one > category and their expansion has not historically been speedy. Tags > are a non-exclusive one-to-many relationship. So a package can have > as many tags as it needs, and users will be able to leverage tags > alone or in combinations to find things they want or need. I wouldn't call that broken. Again, symlinks can perfectly solve that with little extra work. We use them for that same purpose in lots of things. For example, eselect sets symlinks to select the active mesa implementation from between all the installed ones. And we have been using symlinks to make libs and paths available with different names in linux fs's since ever. I am not saying that my idea is better than the rest. I am just wondering why the heck symlinks are not an option when linux has supported them natively since almost the day zero. >> I don't even use tags for my music collections > > That's very curious, and I wouldn't mind talking about why that is > off-list (not quite joking; that's really interesting). Feel free to mail me if you want extra clarification. But to sum up, I just keep everything in a estructured directory tree. I could easily use easytag to automatically tag everything with little or not extra effort, automatically, but I rarely resort to tags. I don't use behemoths like amarok or the likes. I use mplayer or moc, usually. And locate is the only tool I need to find quickly a song in less than one second. > So to sum it up, we're fixing package navigation and discovery because > Gentoo is about choice. Even 15,000 packages is too many to have to > play "guess the category", and it's cruel to expect users (including > ourselves) to know everything in the tree at all times. It's in all > our best interest to make it easy to know what choices are available > so we can get back to more important things. Tags help further this > ideal. That's fine by me, as long as some sense is retained in the underlying fs estructure and tags are an added value, not a substitute for what's already in there. What I wouldn't like is to get 140k ebuilds dumped into a single directory. -- Jesús Guerrero Botella
Re: [gentoo-dev] Are tags just sets?
On Mon, Jun 27, 2011 at 17:23, Rich Freeman wrote: > That wasn't what I was thinking of. Package masking is also something > we carefully control in the repository but users can override it FOR > THEIR OWN SYSTEMS. With tags I think that there were concepts > floating around of letting anybody influence how packages are tagged. > Ah yes, I think it was Jorge that mentioned that. And it's a good idea, too: it streamlines the patch process for tag updates and it gives us an idea of what sorts of things users find important for discovering packages. But because the proposed solution is so simple, we can handle that later pretty easily as long as we agree on what we're doing up front to actually enable this. Cheers, Wyatt
Re: [gentoo-dev] Are tags just sets?
On Mon, Jun 27, 2011 at 5:06 PM, Wyatt Epp wrote: > On Mon, Jun 27, 2011 at 16:23, Rich Freeman wrote: >> I too feel that tags should be distinct from sets, for a bunch of reasons. >> >> Sets should really be something carefully controlled by the >> repository. While I'm fine with having tags in the repository also, >> there is talk about giving users ways of supplying them as well. >> > Too late; /etc/portage/sets/ That wasn't what I was thinking of. Package masking is also something we carefully control in the repository but users can override it FOR THEIR OWN SYSTEMS. With tags I think that there were concepts floating around of letting anybody influence how packages are tagged. With some of the offline suggestions there is really nothing stopping anybody from making their own tagging solution outside of the repository. I could set up my own packages.g.o site and implement user-supplied tagging if I wanted to. That might not be a bad way to get this started, as somebody else in one of these threads seemed to be implying. Rich
Re: [gentoo-dev] Are tags just sets?
On Mon, Jun 27, 2011 at 16:23, Rich Freeman wrote:
> I too feel that tags should be distinct from sets, for a bunch of reasons.
>
> Sets should really be something carefully controlled by the
> repository. While I'm fine with having tags in the repository also,
> there is talk about giving users ways of supplying them as well.
>
Too late; /etc/portage/sets/
> Sets are generally used to tell the package manager to do something
> with a lot of packages at once. I'm not sure there is much of a need
> to do this with tags, at least not in most of the use cases that have
> been suggested.
>
At the moment, yes, that's very true. But that's a matter of lacking
tools, more than a necessarily orthogonal concept. If you look at
sets (or categories), you find they describe attributes of packages.
For example, @world is "everything the user has merged". The kde
overlay provides things like @kde-live, "kde packages built from
subversion" (it's more specific than ${PN} in this case, but generally
won't need to be). I don't think anyone here believes this feature
exists without some tool support to glue it together.
> Maybe if we define multiple namespaces for tags we could move to using
> tags as dependencies or whatever, and those tags would be distinct and
> much more carefully defined and controlled. However, I think this is
> more far-out and not the immediate goal.
>
I'd say that's rather unnecessary. We should be wary of conflating
all metadata together in our heads: Tags are not a replacement for
structured key-value that we already have. When we talk of tags,
we're talking about general purpose semantic descriptors that are only
loosely structured and benefit from emergent community standards. We
already have the things that benefit from rigid definition.
> Sets might work, but they seem a bit like a hack...
>
Oh, absolutely. But nearly anything is better than the current state
of affairs; if it falls apart, we find a different way.
Re: [gentoo-dev] The Python problem
On Mon, 2011-06-27 at 16:52 -0400, Mike Frysinger wrote: > On Monday, June 27, 2011 12:00:19 Dirkjan Ochtman wrote: > > On Mon, Jun 27, 2011 at 17:53, Petteri Räty wrote: > > > I like the ruby approach for the reason that it doesn't require users to > > > run update scripts like python-updater. > > > > Sure, but if that means the developers now have to bump every package > > in the tree when a new version of Python comes out, I'm not sure > > that's the best trade-off. > > if that's the requirement, i'd lean towards the python route we have today. > especially because python-updater will hit all necessary packages where-as > ruby will often not as that requires you to do `emerge -u packages>`. This approach works for ruby because we have multiple implementations (e.g. jruby, hopefully rubinius soon) rather than just multiple versions, and because major version updates that break compatibility are rare. Bumping happens more often than new versions or implementations come out, and we can't expect implementations to be fully compatible. Note that minor versions (ruby 1.8.6 vs ruby 1.8.7) are usually backward compatible, so we can just swap these in within the slot. I don't really see how a ruby-updater tool would work, so the approach we've taken works for ruby. Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] The Python problem
Dirkjan Ochtman wrote: > On Mon, Jun 27, 2011 at 15:08, Fabian Groffen wrote: >> On 27-06-2011 14:28:34 +0200, Dirkjan Ochtman wrote: >> It would be nice when a similar technique could be implemented only >> once, in a consistent way. In a way, multilib-portage can be considered >> equal to one of the objectives of the python (and ruby) eclass: >> multiple times compiling and installing for different ABIs. > > Yeah, but it'd be nice not to have to compile subversion three times > just because we want the python bindings installed in three different > Python environments. You wont be able to prevent this with a general solution, only with some specialized solution inside the build, if you really want and need that. Currently, if you want python bindings for three different python environments, you will have to build everything for all three python environments, even if you only need a subset. Moving to a similar system like ruby, in the long term maybe based on a general PM-implementation, would users at least allow to select the targets per package and not just global like now. > On Mon, Jun 27, 2011 at 17:53, Petteri Räty wrote: >> I like the ruby approach for the reason that it doesn't require users to >> run update scripts like python-updater. > > Sure, but if that means the developers now have to bump every package > in the tree when a new version of Python comes out, I'm not sure > that's the best trade-off. For multilib-portage, packages dont need to define the possible cross-compile targets, they have all possible options in the USE flag list. Something similar could be done for this case: Simplified: Define the range of supported python versions in the dependency section and allow the eclass or PM to sort out the rest (you of course need a bit more, but this should be the only required dependency/python-version related part). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The Python problem
On Monday, June 27, 2011 12:00:19 Dirkjan Ochtman wrote: > On Mon, Jun 27, 2011 at 17:53, Petteri Räty wrote: > > I like the ruby approach for the reason that it doesn't require users to > > run update scripts like python-updater. > > Sure, but if that means the developers now have to bump every package > in the tree when a new version of Python comes out, I'm not sure > that's the best trade-off. if that's the requirement, i'd lean towards the python route we have today. especially because python-updater will hit all necessary packages where-as ruby will often not as that requires you to do `emerge -u `. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] The Python problem
On Monday, June 27, 2011 09:43:05 Dirkjan Ochtman wrote: > On Mon, Jun 27, 2011 at 15:08, Fabian Groffen wrote: > > It would be nice when a similar technique could be implemented only > > once, in a consistent way. In a way, multilib-portage can be considered > > equal to one of the objectives of the python (and ruby) eclass: > > multiple times compiling and installing for different ABIs. > > Yeah, but it'd be nice not to have to compile subversion three times > just because we want the python bindings installed in three different > Python environments. it'd be nice to not build glibc multiple times for diff multilibs, but it simply isnt possible. either you want multilib support (or in this case multi-python version support), or you dont. if this feature is something like (and it sounds like it is), then this is simply something that is accepted. if you dont want multiple builds on your system, then dont install multiple versions of python. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] The Python problem
On 27.06.2011 19:00, Dirkjan Ochtman wrote: > On Mon, Jun 27, 2011 at 17:53, Petteri Räty wrote: >> I like the ruby approach for the reason that it doesn't require users to >> run update scripts like python-updater. > > Sure, but if that means the developers now have to bump every package > in the tree when a new version of Python comes out, I'm not sure > that's the best trade-off. > And why can't this be handled by the eclass? If the ebuild is able to specify it supports >=3.0 meaning it's expected that future versions work then the eclass can make the new values available through IUSE when new python versions are out and ebuilds don't require any changes. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Don't use / when applying sed with CFLAGS
On Monday, June 27, 2011 15:56:24 justin wrote:
> On 6/27/11 9:26 PM, Mike Frysinger wrote:
> > On Monday, June 27, 2011 11:23:58 Lars Wendler wrote:
> >> Am Montag 27 Juni 2011, 17:01:01 schrieb Fabian Groffen:
> >>> On 27-06-2011 14:08:52 +, Justin Lecher wrote:
> Please do not use / as seperater when using sed with CFLAGS. I came
> across a bug today where it failed for crossdev. Here the toolchain
> header paths in the cflags and consowuently the seds fail.
> >>>
> >>> Please also don't use ':' as separator, as some platforms have options
> >>> for their toolchain that includes colons.
> >>
> >> Rather than telling us what to _not_ use as separator how about
> >> suggesting a list of konwn to be good separators for such cases. How
> >> about the @ character?
> >
> > "|" tends to be safe for *FLAGS
> >
> > this topic has come up before, so it's probably useful to read the
> > history in the archives rather than rehash the whole thing from scratch
> > every year or so. i thought we also had a section in the devmanual
> > covering this ...
>
> I am not cross compiling so I never hit this issue nor was interested
> in. And not even thought about it, so the addressed audience are people
> like me.
it's not a cross-compiling issue. anyone can use these chars in their flags.
like the prefix weirdos doing native builds.
> Due to this bug I did a grep on the tree and there are really many
> package doing it wrong. So any section in the manuals or past
> discussions here didn't change a thing as it seems.
probably because it's such a minor issue and only crops up with people using
uncommon values. also, i'd suspect you have quite a bit of false positives as
it isnt just a matter of "using / or : as the separator is always wrong". and
it only matters if the variables from users get expanded in the middle of the
sed expression. using 's:...:${CFLAGS}:' is not a problem.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Are tags just sets?
On Mon, Jun 27, 2011 at 1:49 AM, Ciaran McCreesh wrote: > On Sun, 26 Jun 2011 17:12:27 +0200 > Maciej Mrozowski wrote: > >> Sets concept is completely orthogonal to tags concept, please do not >> mix unrelated things. > > Depends upon what you think the "tags concept" is. We've already > established that everyone has a different idea of what tags are anyway. I too feel that tags should be distinct from sets, for a bunch of reasons. Sets should really be something carefully controlled by the repository. While I'm fine with having tags in the repository also, there is talk about giving users ways of supplying them as well. Sets are generally used to tell the package manager to do something with a lot of packages at once. I'm not sure there is much of a need to do this with tags, at least not in most of the use cases that have been suggested. Here is how I see tags being used: 1. I want a WYSIWYG html editor. 2. I search for tags like "editor" and "html" and "WYSIWYG" and maybe even "text." 3. I check out descriptions and homepages or whatever for a few likely candidates, and install one or maybe two. What I doubt I'd ever do is just install any package that has anything to do with text/html editing. When you search google you care about the top 5-10 - not the whole set of results. Maybe if we define multiple namespaces for tags we could move to using tags as dependencies or whatever, and those tags would be distinct and much more carefully defined and controlled. However, I think this is more far-out and not the immediate goal. Sets might work, but they seem a bit like a hack... Rich
Re: [gentoo-dev] Don't use / when applying sed with CFLAGS
On 6/27/11 9:26 PM, Mike Frysinger wrote: > On Monday, June 27, 2011 11:23:58 Lars Wendler wrote: >> Am Montag 27 Juni 2011, 17:01:01 schrieb Fabian Groffen: >>> On 27-06-2011 14:08:52 +, Justin Lecher wrote: Please do not use / as seperater when using sed with CFLAGS. I came across a bug today where it failed for crossdev. Here the toolchain header paths in the cflags and consowuently the seds fail. >>> >>> Please also don't use ':' as separator, as some platforms have options >>> for their toolchain that includes colons. >> >> Rather than telling us what to _not_ use as separator how about suggesting >> a list of konwn to be good separators for such cases. How about the @ >> character? > > "|" tends to be safe for *FLAGS > > this topic has come up before, so it's probably useful to read the history in > the archives rather than rehash the whole thing from scratch every year or > so. > i thought we also had a section in the devmanual covering this ... > -mike I am not cross compiling so I never hit this issue nor was interested in. And not even thought about it, so the addressed audience are people like me. Due to this bug I did a grep on the tree and there are really many package doing it wrong. So any section in the manuals or past discussions here didn't change a thing as it seems. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The Python problem
On Mon, 27 Jun 2011 14:28:34 +0200 Dirkjan Ochtman wrote: > So I know a bunch of people have already looked at it, and I'd like to > know: what do you find better about the Ruby approach compared to the > Python approach? Is it just the size of python.eclass, or are there a > number of other issues? Working targets. USE_PYTHON is junk. What python.eclass does now with ABIs is a PITA, and requires manually providing a lot of redudant information (namely, RESTRICT_PYTHON_ABIS). Right now, each ebuild has to provide the same information in PYTHON_DEPEND and RESTRICT_PYTHON_ABIS. Moreover, if an ebuild supports, say, py3 and its dependency doesn't, the ebuild has to restrict py3 too. I'd like to see that fixed somehow. I'd like to set a single supported Python version information in an ebuild, and let the dependency resolver handle everything else. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Don't use / when applying sed with CFLAGS
On Monday, June 27, 2011 11:23:58 Lars Wendler wrote: > Am Montag 27 Juni 2011, 17:01:01 schrieb Fabian Groffen: > > On 27-06-2011 14:08:52 +, Justin Lecher wrote: > > > Please do not use / as seperater when using sed with CFLAGS. I came > > > across a bug today where it failed for crossdev. Here the toolchain > > > header paths in the cflags and consowuently the seds fail. > > > > Please also don't use ':' as separator, as some platforms have options > > for their toolchain that includes colons. > > Rather than telling us what to _not_ use as separator how about suggesting > a list of konwn to be good separators for such cases. How about the @ > character? "|" tends to be safe for *FLAGS this topic has come up before, so it's probably useful to read the history in the archives rather than rehash the whole thing from scratch every year or so. i thought we also had a section in the devmanual covering this ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] The Python problem
On Mon, Jun 27, 2011 at 2:28 PM, Dirkjan Ochtman wrote: > So I know a bunch of people have already looked at it, and I'd like to > know: what do you find better about the Ruby approach compared to the > Python approach? Is it just the size of python.eclass, or are there a > number of other issues? the way python applications are built currently renders all binary packages useless, since portage does not know which version of python it was built against. the explicit selection with RUBY_TARGETS or PHP_TARGETS solves this problem at the small cost of commiting new values to these variables from time to time.
Re: [gentoo-dev] Are tags just sets?
On Monday 27 of June 2011 07:49:24 Ciaran McCreesh wrote: > On Sun, 26 Jun 2011 17:12:27 +0200 > Maciej Mrozowski wrote: > > On Sunday 26 of June 2011 09:02:57 Ciaran McCreesh wrote: > > > Here's a completely different way of doing tags: > > As far as sets are concerned, how about PROPERTIES=set? > > https://bugs.gentoo.org/show_bug.cgi?id=272488 > > It's been proposed years ago. Is there a need to reinvent sets format > > every time it's bought up? > The problems with PROPERTIES=set remain exactly the same as they were > when it was first proposed. Which is? No, "been there, done that, won't work" is not sufficient. Please elaborate. > > I see major disadvantage with this approach. It's painful to maintain. > > Imagine hundreds of different tags, with each package having at least > > two tags. You certainly don't expect anyone to be able to maintain > > that. > Uh, I don't see how that's in any way difficult to maintain. No, it's not difficult, it's pain in ass to keep a hundred files with a few thousands lines each up2date with tree changes (pkgmove, cvs remove). Yes, it could be automated by some crafty cvs hook on server. However cvs hooks should be the last resort and not a tool to deal with consequences of broken design. > > Tag is a property or attribute of package > That one's highly debatable. It's not debatable for those familiar with object oriented design concept. It may be debatable for database designers what's the best way to implement many to many association because they have means to auto-update referenced keys - we don't have those means so proposal to "move tags to separate table" isn't practical. > > PROPERTIES=set have the same advantages - they can also be pulled > > within dependency tree by other packages. > Yes, but PROPERTIES=set has all of the problems it had when it was > first proposed, and is the wrong way to implement sets. > > > Disadvantages: doesn't use some horribly convoluted system of XML, > > > wikis and web 2.0. > > Using already proven technologies and tools is barely disadvantage. I > > think last thing we need is yet another obscure format nothing widely > > usable understands. > Good, so you'll be happy going with what Unix has been using for > decades then. Indeed, with sets in bash (ebuild) format. > > Sets concept is completely orthogonal to tags concept, please do not > > mix unrelated things. > Depends upon what you think the "tags concept" is. We've already > established that everyone has a different idea of what tags are anyway. I don't know what's everyone's idea behind the tag, I refer to: http://en.wikipedia.org/wiki/Tag_(metadata) -- regards MM signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: RFC: split up media-sound/ category
Jesús J. Guerrero Botella posted on Mon, 27 Jun 2011 16:19:57 +0200 as excerpted: > someone said fat32 compatibility is a feature we want (still can't guess > why, but well, be consequent...). I believe that "someone" that mentioned fat32 compatibility in the context of symlinks was me. But "we want" is rather strong for what I intended. More, "it's a factor to keep in mind", and "if we decide we do NOT want to keep fat32 compatibility, we should be sure the feature we're implementing that breaks it is worth the tradeoff." Maybe it is worth the tradeoff. Maybe it isn't. But either way, we shouldn't break that compatibility accidentally, simply because we didn't think of it as a factor. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: RFC: split up media-sound/ category
2011/6/27 Jesús J. Guerrero Botella : > That still doesn't answer my question anyway: both features (symlinks > and +65k files on a single dir) are incompatible with fat32. And > someone said fat32 compatibility is a feature we want (still can't > guess why, but well, be consequent...). Obviously, we want fat32 > compatibility when it comes to arguing against symlinks, which have > always been with us by the way, but that's not important when we talk > about other things that are not compatible with fat32. I'm not sure where you're getting 65k files. Unless I misinterpreted everything everyone else was saying, every package would still have its own directory. There are fewer than 20k even with a bunch of overlays installed. Regardless, you might check the other (other) thread; I think we're probably going to go quick and not-necessarily-dirty with sets to get 99% of what we're looking for almost trivially. 2011/6/27 Jesús J. Guerrero Botella : > C) "ls $PORTDIR/whatever-category" is a command that's way simpler > than the one you posted. > It's also fundamentally broken because one package can only be in one category and their expansion has not historically been speedy. Tags are a non-exclusive one-to-many relationship. So a package can have as many tags as it needs, and users will be able to leverage tags alone or in combinations to find things they want or need. > I don't even use tags for my music collections That's very curious, and I wouldn't mind talking about why that is off-list (not quite joking; that's really interesting). So to sum it up, we're fixing package navigation and discovery because Gentoo is about choice. Even 15,000 packages is too many to have to play "guess the category", and it's cruel to expect users (including ourselves) to know everything in the tree at all times. It's in all our best interest to make it easy to know what choices are available so we can get back to more important things. Tags help further this ideal.
Re: [gentoo-dev] Re: Thoughts about broken package handling
Ciaran McCreesh writes: > The fix for that is to slot things properly. You're screwed anyway if a > preserved library tries to access installed data that has either been > removed or upgraded to a new format that it doesn't recognise. Or some "awkward" packages which when rebuilt will still link against the preserved library, but if the preserved library is deleted and the package manually rebuild will link against the new one.
Re: [gentoo-dev] The Python problem
On Mon, Jun 27, 2011 at 17:53, Petteri Räty wrote: > I like the ruby approach for the reason that it doesn't require users to > run update scripts like python-updater. Sure, but if that means the developers now have to bump every package in the tree when a new version of Python comes out, I'm not sure that's the best trade-off. Cheers, Dirkjan
Re: [gentoo-dev] The Python problem
On 27.06.2011 15:28, Dirkjan Ochtman wrote: > > So I know a bunch of people have already looked at it, and I'd like to > know: what do you find better about the Ruby approach compared to the > Python approach? Is it just the size of python.eclass, or are there a > number of other issues? > I like the ruby approach for the reason that it doesn't require users to run update scripts like python-updater. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Don't use / when applying sed with CFLAGS
On Mon, 27 Jun 2011 17:01:01 +0200 Fabian Groffen wrote: > On 27-06-2011 14:08:52 +, Justin Lecher wrote: > > Please do not use / as seperater when using sed with CFLAGS. I came > > across a bug today where it failed for crossdev. Here the toolchain > > header paths in the cflags and consowuently the seds fail. > > Please also don't use ':' as separator, as some platforms have options > for their toolchain that includes colons. Then don't do it at all or we could be here til Christmas. That is, do not inject CFLAGS/LDFLAGS/CC/... into any file, but use the file's native variable format so that it picks up the information from the environment. :) jer
Re: [gentoo-dev] Don't use / when applying sed with CFLAGS
On 17:23 Mon 27 Jun , Lars Wendler wrote: > Am Montag 27 Juni 2011, 17:01:01 schrieb Fabian Groffen: > > On 27-06-2011 14:08:52 +, Justin Lecher wrote: > > > Please do not use / as seperater when using sed with CFLAGS. I came > > > across a bug today where it failed for crossdev. Here the toolchain > > > header paths in the cflags and consowuently the seds fail. > > > > Please also don't use ':' as separator, as some platforms have options > > for their toolchain that includes colons. > > Rather than telling us what to _not_ use as separator how about suggesting a > list of konwn to be good separators for such cases. How about the @ character? One of my favorites for weird cases is ~. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpaaKjqoCZiQ.pgp Description: PGP signature
Re: [gentoo-dev] Don't use / when applying sed with CFLAGS
Am Montag 27 Juni 2011, 17:01:01 schrieb Fabian Groffen: > On 27-06-2011 14:08:52 +, Justin Lecher wrote: > > Please do not use / as seperater when using sed with CFLAGS. I came > > across a bug today where it failed for crossdev. Here the toolchain > > header paths in the cflags and consowuently the seds fail. > > Please also don't use ':' as separator, as some platforms have options > for their toolchain that includes colons. Rather than telling us what to _not_ use as separator how about suggesting a list of konwn to be good separators for such cases. How about the @ character? -- Lars Wendler (Polynomial-C) Gentoo package maintainer and bug-wrangler signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Don't use / when applying sed with CFLAGS
On 27-06-2011 14:08:52 +, Justin Lecher wrote: > Please do not use / as seperater when using sed with CFLAGS. I came across a > bug today where it failed for crossdev. Here the toolchain header paths in > the cflags and consowuently the seds fail. Please also don't use ':' as separator, as some platforms have options for their toolchain that includes colons. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] RFC: split up media-sound/ category
2011/6/27 Zac Medico : > On 06/24/2011 12:52 AM, Jesús J. Guerrero Botella wrote: >> 2011/6/24 Zac Medico : >>> On 06/22/2011 11:15 PM, Jesús J. Guerrero Botella wrote: Symlinks are clean, and portage has always been file-oriented so I see no problem with using them for this. All we need is to deference the symlink to find the real name of the package and put it in world instead of the symlinked name, so the rest of packages won't even need to be retouched to fix the dependencies. I don't really know if it's that simple as it sounds, but it's an idea. >>> >>> For some reason, using symlinks to represent tags seems like an odd >>> approach to me. I think it would be much more sensible to put them in >>> metadata.xml or an ebuild variable. If for some reason you want symlinks >>> representing the tags (I don't know why you would), you can always use a >>> script to generate symlinks from metadata.xml files. >> >> You might not like it, but Gentoo categories have always been >> directories, not words into metadata.xml. Most portage tools rely on >> that. Not a strong argument, I know that. But someone used this >> argument when someone else wanted to put portage into a database >> instead of an fs-based tree. That was long ago, admittedly, don't know >> if that conversation ever came up again. > > I see, so you want to optimize the tree layout for use with simple shell > commands. For a shell-friendly alternative to metadata.xml, I suppose > that we could instead use a plain text file called "tags" in the same > directory as metadata.xml. If it listed one tag per line, you could use > a simple shell command like this to search for packages with a specific tag: > > find /usr/portage -name tags | xargs grep I still don't understand why A) you need to build a project, a glep, whatever the course of action is, I am bad at bureaucracy. B) you need to code the solution, to fix What? C) "ls $PORTDIR/whatever-category" is a command that's way simpler than the one you posted. XML seems to be the trend, but we should really think a moment, what's what we are trying to fix? We just needed to add some categories or rename them when someone started this thread, but now, even when we know we are lacking dev power in some areas we start arguing that the base concept of our OS (portage) is wrong, and that we should redo it completely by putting every ebuild into a directory and tagging them. Again, that's not "port-age". Read on ports: http://en.wikipedia.org/wiki/FreeBSD_Ports I don't even use tags for my music collections and now I am going to be forced to use them to operate my OS. We might even end having something like ... ... .. . . . . :P Or boot usr lib home genpatches could also remove symlink stuff from the kernel, since it's taking precious memory that could be used for the /proc.xml file. Yes, feeling sarcastic, but I am really trying to understand what's what we need to fix today. -- Jesús Guerrero Botella
Re: [gentoo-dev] Re: RFC: split up media-sound/ category
2011/6/26 Kent Fredric : > 2011/6/26 Jesús J. Guerrero Botella : >> I am really amazed that someone didn't want to use links (a solution >> with next to zero work involved) because they are not available in >> fat32 (as if fat32 was relevant at all for us) but then people is >> suggesting that we should put everything into a flat folder and use >> tags. > > Well, the difference being "Symlinks are only really surplus utilities > that make it easier for users" and "Some degree of backcompat" instead > of "Core Functionality that will be required to make the code work". > > In theory, if you have the "most recent" versions of your package > manager, after this change takes place, you will not need any symlinks > at all, and functionality should still be retained if they were blown > out completely. The real question is why something that has been into POSIX since ever can't be used for something that has also always been fs-based since it was born (that's "portage"). I an not saying that this other system doesn't have it's advantages. I am just saying that if I wanted a db-like-but-not-db-based system I'd probably reinvent any .deb or .rpm based distro, rather than retouch something based (even marginally) on BSD ports. That still doesn't answer my question anyway: both features (symlinks and +65k files on a single dir) are incompatible with fat32. And someone said fat32 compatibility is a feature we want (still can't guess why, but well, be consequent...). Obviously, we want fat32 compatibility when it comes to arguing against symlinks, which have always been with us by the way, but that's not important when we talk about other things that are not compatible with fat32. Links seem to look not so elegant today, but we use them everyday for eselect, /etc and even in the handbook. but Oh!, They are not that good for portage. -- Jesús Guerrero Botella
[gentoo-dev] Don't use / when applying sed with CFLAGS
Hi Please do not use / as seperater when using sed with CFLAGS. I came across a bug today where it failed for crossdev. Here the toolchain header paths in the cflags and consowuently the seds fail.
Re: [gentoo-dev] The Python problem
On Mon, Jun 27, 2011 at 15:08, Fabian Groffen wrote: > On 27-06-2011 14:28:34 +0200, Dirkjan Ochtman wrote: >> So I know a bunch of people have already looked at it, and I'd like to >> know: what do you find better about the Ruby approach compared to the >> Python approach? Is it just the size of python.eclass, or are there a >> number of other issues? > > Part of the eclass problem is IMO coding style. Change it to use > normally-sized variable names, and to respect 80-columns width, and it > already becomes much more consumable. That seems like the somewhat more straightforward part. > The whole comparison of Python vs Ruby vs Java and perhaps the outlook > to Perl is kind of hard. What the python eclass accomplishes is very > neat. What probably started as a way to be able to have both python 2.x > and 3.x installed side by side (because the latter is not really > compatible with the former) got IMO out of hand by supporting any python > version to coexist with another. I guess many people developing with > Python actually love this feature, and in itself, I believe it has use > that cannot be ignored any more now. The way in which this feature was > implemented -- sometimes it more felt as pushed through the throat -- is > more of the rebelious kind than the smooth path for ebuild developers. Right. I think the ability to have python packages simultaneously installed in python2.6, python2.7 and pypy1.5, for example, is pretty cool to have. And going from USE to RESTRICT (Ruby vs. Python, right now) is probably more sensible in the Python ecosystem (i.e. where something that runs on 2.6 is likely to also run on 2.7). > It would be nice when a similar technique could be implemented only > once, in a consistent way. In a way, multilib-portage can be considered > equal to one of the objectives of the python (and ruby) eclass: > multiple times compiling and installing for different ABIs. Yeah, but it'd be nice not to have to compile subversion three times just because we want the python bindings installed in three different Python environments. > All in all, I don't fancy a rewrite from scratch, since it all works > at the moment, and doing so takes another large bit of work. Instead, > aligning the work with others to create a similar approach in ebuilds > (for ebuild developers) would be favourable to me. And perhaps that > should mean that variables which contain versions with some syntax that > specify ranges and more should just go, to be replaced by something > which is much less powerful in expressiveness, but much easier to > understand in the general picture, such as the USE-flags from the ruby > eclass. That sounds very similar to what I think would be best. Cheers, Dirkjan
Re: [gentoo-dev] The Python problem
On 27-06-2011 14:28:34 +0200, Dirkjan Ochtman wrote: > So I know a bunch of people have already looked at it, and I'd like to > know: what do you find better about the Ruby approach compared to the > Python approach? Is it just the size of python.eclass, or are there a > number of other issues? Part of the eclass problem is IMO coding style. Change it to use normally-sized variable names, and to respect 80-columns width, and it already becomes much more consumable. The whole comparison of Python vs Ruby vs Java and perhaps the outlook to Perl is kind of hard. What the python eclass accomplishes is very neat. What probably started as a way to be able to have both python 2.x and 3.x installed side by side (because the latter is not really compatible with the former) got IMO out of hand by supporting any python version to coexist with another. I guess many people developing with Python actually love this feature, and in itself, I believe it has use that cannot be ignored any more now. The way in which this feature was implemented -- sometimes it more felt as pushed through the throat -- is more of the rebelious kind than the smooth path for ebuild developers. It would be nice when a similar technique could be implemented only once, in a consistent way. In a way, multilib-portage can be considered equal to one of the objectives of the python (and ruby) eclass: multiple times compiling and installing for different ABIs. All in all, I don't fancy a rewrite from scratch, since it all works at the moment, and doing so takes another large bit of work. Instead, aligning the work with others to create a similar approach in ebuilds (for ebuild developers) would be favourable to me. And perhaps that should mean that variables which contain versions with some syntax that specify ranges and more should just go, to be replaced by something which is much less powerful in expressiveness, but much easier to understand in the general picture, such as the USE-flags from the ruby eclass. Just my €0.02 -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] The Python problem
Dirkjan Ochtman writes:
> I guess by now pretty much everyone knows that the python eclass is
> rather complex, and that this poses some problems. This has also been
> an important cause for the disagreements between Arfrever and some of
> the other developers. Since it appears that Arfrever won't be
> committing much code to gentoo-x86 in the near future, I'm trying to
> figure out where we should go with the python.eclass. This email is an
> attempt at figuring that out, plus eliciting ideas to come up with a
> general framework that will also solve this for ruby and other similar
> runtimes (while supporting some of the features that the current
> python eclass has, but that ruby-ng doesn't have).
>
> So I know a bunch of people have already looked at it, and I'd like to
> know: what do you find better about the Ruby approach compared to the
> Python approach? Is it just the size of python.eclass, or are there a
> number of other issues?
Let's skip the Ruby step, and go directly to Common Lisp!
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Re: [gentoo-dev] The Python problem
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
[gentoo-dev] The Python problem
Hi guys, I guess by now pretty much everyone knows that the python eclass is rather complex, and that this poses some problems. This has also been an important cause for the disagreements between Arfrever and some of the other developers. Since it appears that Arfrever won't be committing much code to gentoo-x86 in the near future, I'm trying to figure out where we should go with the python.eclass. This email is an attempt at figuring that out, plus eliciting ideas to come up with a general framework that will also solve this for ruby and other similar runtimes (while supporting some of the features that the current python eclass has, but that ruby-ng doesn't have). So I know a bunch of people have already looked at it, and I'd like to know: what do you find better about the Ruby approach compared to the Python approach? Is it just the size of python.eclass, or are there a number of other issues? Cheers, Dirkjan
