| View previous topic :: View next topic |
| Author |
Message |
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
 Posted: Wed Jun 01, 2011 4:04 pm Post subject: what does the future bring? |
 |
|
I don't know about you guys, but I miss some kind of agenda stating long-/short-term goals for Gentoo.
I admit, I don't closely follow all mailinglists, since that's just too much, the newsletter is dead for years and the planet mostly copes with things involving but not about Gentoo. Once a year, a pretty big list pops up about ideas the devs have, but for which they don't have time or will to follow - GSoC.
There are devs out there, which talk widely, openly and often about what they are doing, from my p.o.v. Diego/flameeyes is such a case. I don't know where he finds the time to blog this much and in high quality, mostly even trying to explain his work to people with lesser knowledge, but imho he does a pretty good job - there are others, too, of course.
Sure, as a "meta"-distribution it's somewhat hard to find/tell a goal, we're not Ubuntu trying to reimplement OS X on opensource.
Either we don't have or I can't find a place where the devs list what they are currently working on, which imho is a shame. I'd like to know for what I could maybe donate time and/or some money to get stuff done.
When I look around the "Gentoo ecosystem", I find some interesting things, being it stuff done in Funtoo, Exherbo or Sabayon, they all imho work more in the open.
To close up, some things I'd like to see in the future, for some I know people are already working on it:
- tags in portage, as in ie. `eix browser AND KDE` or `eix python OR ruby library AND twitter NOT python-twitter`, etc
- something like RedHat's kickstart: ie. create a custom profile from the current installation with the option to leave out stuff, transfer profile to another system, `emerge @profile`
- radically slimming down portage
- provide a better system than having portage + a gazillion overlays, making it easier for non-devs to participate/provide
- a way to query the bugtracker directly via emerge, ie when a build fails, ask the user if he thinks it's a bug, query bugtracker for this problem and report it automatically if nothing is found (direclty adding things like USE/CFLAGS, --info, etc).
tl;dr? Give me a place where I can see what's up for the future, ideally directly allowing to donate money or jump on board.
_________________
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
| Back to top |
|
 |
Dr.Willy
Guru
Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany
|
| Posted: Thu Jun 02, 2011 9:27 am Post subject: Re: what does the future bring? |
|
|
| avx wrote: | | - radically slimming down portage |
In which aspects?
| avx wrote: | | - provide a better system than having portage + a gazillion overlays, making it easier for non-devs to participate/provide |
I don't see how less overlays would make anything easier.
In fact I think the opposite is true.
I mean I agree that personal overlays of devs are not overly useful, especially when you can get the same ebuild from different sources, but if you have topic-centered overlays (like an overlay for KDE, an overlay for Gnome, etc) I think that's a good thing. |
|
| Back to top |
|
|
mahdi1234
Guru
Joined: 19 Feb 2005
Posts: 559
Location: Being There
|
| Posted: Thu Jun 02, 2011 10:56 am Post subject: Re: what does the future bring? |
|
|
| Dr.Willy wrote: | | but if you have topic-centered overlays (like an overlay for KDE, an overlay for Gnome, etc) I think that's a good thing. |
I second that, I always choose overlay with the least packages not the most complex one (if on par with ebuild freshness) and I wouldn't like to use ones with gazillion of ebuilds. Also don't understand what's so complicated in going to the http://gpo.zugaina.org/ find your package and issue layman -a ... couldn't be easier imo
What I'd like to see though is again fully working GLSA - I've heard in many discussions that gentoo has very bright ideas which often die and this seems to be the case here as well. And of course newsletter, newsletter, newsletter - focused on where's gentoo going, pretty ok couple pages every second month or so (don't need stats on added/removed packages, bugs solved etc ...) |
|
| Back to top |
|
|
nCdy
n00b
Joined: 30 Aug 2010
Posts: 5
|
| Posted: Thu Jun 02, 2011 11:58 am Post subject: |
|
|
[quote]Give me a place where I can see what's up for the future[/quote]
just was on thinking about asking same question
_________________
Eternal reservoir of artificial lifeforms |
|
| Back to top |
|
|
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
| Posted: Thu Jun 02, 2011 1:05 pm Post subject: Re: what does the future bring? |
|
|
| Dr.Willy wrote: | | avx wrote: | | - radically slimming down portage |
In which aspects? |
Mostly in size and format.
Considering size, the fact alone that most files in portage are tiny, but still use (at least) a 4kb block uses much space, which apart from normal computers/notebooks sometimes is a problem - think mobile, embedded, ... Yes, it can be shared (ie via NFS), but that often brings another layer of complication.
One way this could be treated is placing all files in a single file and loop-mounting it, that should at least save 50% (not counting distfiles of course). Even better, use a combination of squashfs+aufs(2). There are already scripts for that, which quite some people use, but imho this functionality should be included directly into portage, making it easier to maintain and add features if needed.
Added to that, a kind of 'selected' portage would be nice. The rsync already can exclude files from syncing and portage can benefit from it, but for now, it's a mostly manual task. For example, if one uses a GNOME-only system, there is just no use of having kde-*, xfce-*, etc laying around. This costs bandwith on both sides and space (maybe more problematic, inodes) on the disk - more files which are read/write quite often are of course also bad for SSDs.
Thus, in addition to @sets, maybe something like @exclude-sets should be added.
To not let the user run in a situation, where he wants to install something, but doesn't have the ebuilds, there should be a single-file database (plaintext, sqlite - latter imho prefered), which stores relations between app-names, tags/categories and the respective ebuild. Thus, if I f.e. excluded kde-*, but now want to install konqueror, I could use something like `emerge -s KDE AND browser`, it finds konqui, then I do `emerge konqui` it fetches the konqueror-ebuild, checks the dependency list against the ebuilds on disk, fetching what's needed - loop if needed.
Built up on that, there could be functionality like Fedora has it, when you enter the name of an executable and it's not found, yum asks to install.
As for the format, I already often 'hated' about the bashisms, but devs aren't willing to change, since that's too much work - well, it won't get less magically over time.
Besides this, the manifests are also in question, DRobbins has done some work here on Funtoo, making use of already existing git-functionality - which of course would require portage to go on git - which IIRC was planned or is worked on.
Ebuilds should also be checked more closely for dependencies. I.e. I have a couple of bugs open, where things like asciidoc are in depends, although the upstream tarball already brings ready-built documentation - this is just useless waste of diskspace and cpucycles, imho - espacially if they get pulled in on a space-limited system where I've got FEATURES="... nodoc noman noinfo ..." defined.
--
As for overlays, I mostly need them for specific ebuilds, which no dev wants to maintain any longer or not include into portage. So I google for ebuilds/overlays, pick what I need and place them in my local overlay - hoping to not miss important updates. There's a lot of duplicated stuff flowing through dozens of overlays, which is just plain useless. Sure, Arch's AUR has it's problems and I wouldn't want it that way, but it has it's uses. IMHO, Gentoo should open up overlays.gentoo.org to everybody, requiring some standards, so that a single main overlay-source exist, which is unified and thus could be querried on the fly to select which ebuild you want from which person.
Ideally, we'd have some kind of ebuild wiki, we're everyone could contribute - or it could be limited to f.e. everyone with X valid non-OTW forum posts. Combined with some vote-system and a dedicated dev bringing the best/most often requested ebuilds into portage.
--
There is so much stuff floating around, people writing cool scripts, etc. but the majority can't benefit since they don't know about, that should change.
_________________
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
| Back to top |
|
|
Dr.Willy
Guru
Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany
|
| Posted: Thu Jun 02, 2011 2:21 pm Post subject: Re: what does the future bring? |
|
|
Oh, so you mean the ebuilds.
| avx wrote: | | Considering size, the fact alone that most files in portage are tiny, but still use (at least) a 4kb block uses much space, which apart from normal computers/notebooks sometimes is a problem - think mobile, embedded, ... Yes, it can be shared (ie via NFS), but that often brings another layer of complication. |
only if you have 4k blocks, no?
As for the single portage-tree-blob … I don't know, can rsync do a bindiff transfer? Otherwise one would definitely need to check the server load if ~130mb get transferred everytime someone syncs.
| avx wrote: | | Added to that, a kind of 'selected' portage would be nice. The rsync already can exclude files from syncing and portage can benefit from it, but for now, it's a mostly manual task. For example, if one uses a GNOME-only system, there is just no use of having kde-*, xfce-*, etc laying around. This costs bandwith on both sides and space (maybe more problematic, inodes) on the disk - more files which are read/write quite often are of course also bad for SSDs. |
…kindof like overlays, where you only include the ones you want? |
|
| Back to top |
|
|
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
| Posted: Thu Jun 02, 2011 2:55 pm Post subject: Re: what does the future bring? |
|
|
| Dr.Willy wrote: | Oh, so you mean the ebuilds.
| avx wrote: | | Considering size, the fact alone that most files in portage are tiny, but still use (at least) a 4kb block uses much space, which apart from normal computers/notebooks sometimes is a problem - think mobile, embedded, ... Yes, it can be shared (ie via NFS), but that often brings another layer of complication. |
only if you have 4k blocks, no? |
Of course, and 4k is the default for pretty much any filesystem - and if you want to change that, you should place portage on it's own partition.
| Quote: | | As for the single portage-tree-blob … I don't know, can rsync do a bindiff transfer? Otherwise one would definitely need to check the server load if ~130mb get transferred everytime someone syncs. |
No no, you get that wrong. | Code: | dd if=/dev/zero of=portage.file bs=1M count=200
losetup portage.file /dev/loop8
mkfs.ext2 /dev/loop8
mount /dev/loop8 /usr/small_portage
mv /usr/portage/* /usr/small_portage
rm -rf /usr/portage
umount /usr/small_portage
mount /dev/loop8 /usr/portage |
This acts like any normal partition, thus rsync can act as usual - provided the file is big enough, ie not storing distfiles. Using squashfs+aufs would take care of the size problem, by the cost of temporarily needing a little RAM and CPU - portage doesn't need to always be mounted.
| Quote: | | avx wrote: | | Added to that, a kind of 'selected' portage would be nice. The rsync already can exclude files from syncing and portage can benefit from it, but for now, it's a mostly manual task. For example, if one uses a GNOME-only system, there is just no use of having kde-*, xfce-*, etc laying around. This costs bandwith on both sides and space (maybe more problematic, inodes) on the disk - more files which are read/write quite often are of course also bad for SSDs. |
…kindof like overlays, where you only include the ones you want? |
Yes, basically. Only have stuff on the system you need. Doesn't matter to me, if I pull everything and throw away what I don't need or just pull what I need - the latter may be better to the servers, if done right, though.
_________________
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
| Back to top |
|
|
Dr.Willy
Guru
Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany
|
| Posted: Thu Jun 02, 2011 3:46 pm Post subject: Re: what does the future bring? |
|
|
| avx wrote: | | Quote: | | As for the single portage-tree-blob … I don't know, can rsync do a bindiff transfer? Otherwise one would definitely need to check the server load if ~130mb get transferred everytime someone syncs. |
No no, you get that wrong. |
No, I didn't. Squashfs is read-only so you do have to do some fiddling with aufs …which is not even in the mainline kernel. So I thought about distributing sqashfs images instead.
If you keep the portage tree in a blob and put a "normal" filesystem on it, the only advantage is that you can use a smaller block-size, thus saving you ~250M - right? |
|
| Back to top |
|
|
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
| Posted: Thu Jun 02, 2011 3:57 pm Post subject: |
|
|
Of course squashfs is ro, that's why I used the OR (is das denn sooo kompliziert :p).
As I said, it also saves inodes - at least on the partition holding the portage.file. I often had disk full errors, where the disk wasn't really full, but ran out of inodes. Besides, 250mb is big, it may not seem this way on modern disks, but as I said, think mobile, think embedded, 50%+ savings are a very good thing here(ie. my PDA only supports SDcards up to 2GB and yes, I want portage to be on there)!
_________________
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
| Back to top |
|
|
Dr.Willy
Guru
Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany
|
| Posted: Thu Jun 02, 2011 4:37 pm Post subject: |
|
|
| avx wrote: | Of course squashfs is ro, that's why I used the OR (is das denn sooo kompliziert :p).
As I said, it also saves inodes - at least on the partition holding the portage.file. I often had disk full errors, where the disk wasn't really full, but ran out of inodes. Besides, 250mb is big, it may not seem this way on modern disks, but as I said, think mobile, think embedded, 50%+ savings are a very good thing here(ie. my PDA only supports SDcards up to 2GB and yes, I want portage to be on there)! |
But … if you just loop-mount, there is nothing portage has to do for you. Create file, copy portage-tree, profit.
I feel like squashfs+aufs is a hack-ish solution. Of course portage could support that anyway, but that just doesn't sound like a solid idea to me. |
|
| Back to top |
|
|
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
| Posted: Thu Jun 02, 2011 6:24 pm Post subject: |
|
|
Well, I never said my ideas are perfectly though to the end 
I'm just thinking, that there is a lot of unused potential and some people have good ideas. Portage is already a pretty big - and partly ugly - codebase, so not easy to jump in without knowing on what features others are already working.
But maybe we're a little ot already?
_________________
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
| Back to top |
|
|
dol-sen
Retired Dev
Joined: 30 Jun 2002
Posts: 2805
Location: Richmond, BC, Canada
|
| Posted: Fri Jun 03, 2011 12:47 am Post subject: |
|
|
avx check out this years GSOC projects. Among them one is an auto-dependency builder, another is an ebuild generator, yet another is a VM builder. Using those in conjunction will help test and prevent missing deps in the ebuilds. It will also make it easier to get ebuilds for packages not already in the tree.
_________________
Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch... |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
