In my last post I mentioned that users of packages lacking a maintainer in portage should submit patches for the open bugs; while this is all good and fine, it is true that often there are bugs with patches that stays there to rot as well. I wish to point out here some things that might not be obvious to users as well as developers.

The first point I want to make is that it’s not like the problem is limited to user-submitted bugs and patches; bugs and patches submitted by developers can follow the same road too, waiting for months, if not years, before they are accepted and merged in. The problems here are many, some technical some social, some difficult to fit into a single category.

The biggest technical problem I can find is that there is no easy way to identify bugs which have patches waiting for review from a simple search. Modifying the Bugzilla workflow is probably a matter too complex to be worth it, but there is an easy way to avoid this, although it requires more coordination between reporters and assignees: using the “Status whiteboard” field to write “Patch waiting review” or something like that; the status whiteboard appears in searches by default, and would be useful to signal stuff like that (I used that to ask developers to signal me particular cases where gnuconfig_update couldn’t be removed).

Another technical problem is that maybe some developer is interested in fixing eventual bugs with patches for a particular package that lacks a maintainer, without becoming maintainers themselves; or an users would like to submit patches for the new bugs about a particular package. Adding themselves to maintainer-needed alias, or watching it, is most likely going to throw at them a huge amount of bug mail they are absolutely not interested in; I’m sure I sent some hundreds of bugs the m-n way in the last month (I’ll have fun watching the bug statistics on the next GMN), and I’m sure most people wouldn’t care of all those bugs.

The feasible way to handle this in the current infrastructure would be to set up bug whining filtering by package name in subject, but that’s not the nicest option I guess, although it is doable without changing anything. Another idea I got would require a huge effort from our infrastructure team and might not really e that feasible: creating multiple package name aliases; basically creating an @packages.g.o domain, and then creating dynamic aliasing for addresses like app-arch+libarchive@p.g.o so that it would then redirect the mail to the maintainer (developer or team) looking at metadata. This is of course a very complex solution, requires technical changes, and might as well be quite worse on other things, like for instance it would be a huge mess to search for all the bugs for a given herd, and would increase the amount of spam that each alias receive in a HUGE manner. On the other hand, the domain could be ste to only receive mail through bugzilla, and the addresses being otherwise invalid.

There are then some social problems, for instance there is the fact that Gentoo developers are volunteer, so you can’t force them to accept patches, or to improve submitted patches if they are not seen fit for merge in the tree. This means that if you want your patch to be merged in the tree you need to make sure you have a good case for it, and that you improve it as much as it’s needed for it to be merged, which might take an incremental amount of time. Of course not all users are programmers, but you cannot expect all developers to take charge of improving patches indeterminately until they can be merged, if they have no need for such patches. You can always try to find some person interested in helping out who can help you improve the patch; in the worst case you can resolve to pay someone to fix your patch up.

Also, most of the developers are likely swamped and might require some prodding to remember to take care of patches, and this is probably the heaviest showstopper; the only way to fix that is to join Gentoo and start improving the situation; of course it requires training, it’s not like we can accept every user as a developer, there are standards that one has to consider. Yes, I know there are some developers who not always live up to those standards, but that’s also a problem. I’m not saying that new developers should be perfect before joining, but they have to be open to critics and ready to learn; “works for me, it’s your problem” is not a good answer.

Does anybody have better ideas on how to fix these problems?

As reported in my previous post I am without a permanent internet connection. At this point a distributed version control system (dVCS) comes in handy, which most known variant is Git. Gentoo currently uses CVS which is a centralized VCS and needs a connection to the server to work properly and has some more disadvantages which you can find out about by your favourite search engine. For a long time people propagate a switch from CVS to a dVCS, but this is more easily said than done as we have dozens of tools which need migration, documentation and lots of other details (Git lacked some features we needed a while ago).

GNU Emacs upstream has the same problems, but the decision to switch has been made and the target will be Bazaar, one of the big three in dVCS business. Once some performance problems are sorted out, Emacs will center its workflow (branch merging has been really painful in the past there) around Bazaar...and so did I for my personal projects, after using Git for some time. Some aspects of Bazaar convinced me: It is really easy to learn, Git is a bit more cryptic and harder to grasp. And Bazaar has robust renaming where Git can get confused, learn more about it in a blog post by Mark Shuttleworth (yes, Bazaar is Canonical funded and also an official GNU project).

When Emacs upstream was discussing the switch there were three repositories of dVCS systems: tla (GNU Arch, obsolete and only used for branch merging as there was a CVS<->Arch interface), Git and Bazaar. The Gentoo Emacs team tested them regarding performance and usability and Bazaar was just sloooooow and we were really irritated by the final decision. But the situation is getting better as Bazaar is improving fast, Git still outruns it in some functions (you will find dozens of benchmarks on the net, look at the date), but everyday operation is very realiable und usable.

So we need a dVCS in Gentoo, people are working on it, though I think meanwhile that Bazaar would be the better choice. Hearing about exactly those renaming problems in Git overlays (seldomly but they are there), makes me think. And now my big but: The guy doing most of the migration work (robbat2) is really into Git, has invested lots of time, gained experience because of developer and project overlays. And Git is still a good choice in the end, especially its flexibility may proof useful for ends I cannot see now.

Another year is over, I finished my second year being a developer for Gentoo Linux. Some things have changed since my first summary one year ago. Most important of all (for me): I am no longer member of any architecture team due to personal changes, which I really pity. At the moment I have no constant net access, so I have to transfer all things I need for my desktop from my crappy laptop which I can connect at work to the world. Apart from those problems I try to do my best to still maintain Emacs and some other packages I still care for. Personally also some things have changed: My mentor and my recruiter left the project, and I near the statistical end of my term (as shown by Donnie Berkholz on LWN, cannot find the article at the moment), but I am not done yet. So expect me stick around for a while.

So if somebody was wondering why I haven’t written much lately, well, I spent the weekend with friends, and yesterday I picked up a new drug still, Unreal Tournament 3 at less than half the price (sometimes that shop has crazy low prices on stuff, I still don’t know how they do that). I used to be a heavy player of Unreal Tournament, to the point I was admin of an Unreal Tournament server, the first european server of the Thievery UT mod, too.

Anyway, I connected an extra keyboard and my trackball first to try UT3 out and.. it’s cool! The visual is much better than the good old Unreal Tournament when I started playing FPS seriously, and the response of the keyboard is not bad at all; I had to replace the trackbal with a mouse though since I couldn’t play with that (or with the gamepad), and now I’m getting my practice back. For the Gentoo developers out there playing UT3: time to get rolling with a tournament guys! :P

But even if I’m now playingone of my favourite games types, it does not mean I’m not continuing my work for Gentoo and free software; although I cannot connect to the Gentoo CVS server, because my ISp is probablty having routing problems, I left the chroot to build again a part of the tree so that it could check if something is going to break with linux-headers, especially in those bitrotting packages that lack a maintainer and most common users don’t use themselves.

Talking about bitrotting and packages lacking maintainers, last week I started filing bugs for packages that don’t respect CC and other variables by calling directly some common tools’ names, like cc, gcc, g++ and so on. Although I didn’t finish filing bugs (also because I noticed a trend in the bugs being often related to the same team of maintainers, and I wanted to give them a chance to proactively fix their ebuilds instead of waiting for the bugs to be reported), I got one idea that hopefully Zac will implement, if he hasn’t already by now: warning users for unmaintained packages.

When you install a package, explicitly, so not as a dependency, that is not actively maintained in the tree, it makes sense to warn the user of this, so that who merges it won’t find it strange if it does not build, work or if it’s so outdated that it nears uselessness. The idea is that if users start to see that the software they rely on is unmaintaiend, they can decide to either join Gentoo to maintain it or proxy-maintain it, or at least submit patches for the bugs that are open, or for the problems they do find.

Right now I’m testbuilding packages against linux-headers 2.6.27, although not a huge update, it might as well have problems, and then I’ll move on to gcc 4.4 (since 4.3 does not seem to build on that chroot right now it might as well be a good idea to try). While I’m sure automated testing that some developers are working on will be a nice thing, for nowI’m still glad I can do manual testing on my chroots, I think I’ll keep that way; adding to that I’m probably going to test for more respecting of chost-prefixed tools, like ld, ar and ranlib, and maybe if it’s no too noise to do, I would check for packages that force optimisation on even if the user requested -O0 (knowing that some software fails to build with -O0).

So while Yamato builds, I’ll take the rest of the night off, enoy!

Hi All,

My P4 laptop died recently, which is a pain as I now have to look at replacing it in the near future… however, this has meant I now have 2GB of DDR400 SODIMMS that can be used in the Lemote systems.

There was a catch however.  The PROM had to be flashed on one of the units so it would initialise the RAM properly, otherwise the kernel would b0rk.  With this done, both units now recognise the 1GB sticks of RAM installed.

At present, both systems are available for developer use.

How to upgrade the PROM on the Fulong.

For the reference of others who may wish to perform this upgrade on their Lemote equipment.  This is the procedure.

1. Download pmon_v1.1.zip from this page and unpack it.
2. Copy the pmon.bin file located inside, to your /boot partition (or somewhere else accessible to the PROM)
3. Reboot, and hit ESC/DEL repeatedly to break into the PMON prompt.
4. Type set, and write down any critical settings such as al and karg
5. At the PMON prompt, enter the following command (adjust:path as appropriate)
   load -r -f bfc00000 /dev/fs/ext2@wd0/pmon.bin
6. Restore the settings you wrote down using set arg value.
7. Type reboot to reset the system.

If at step 5, the load fails, DO NOT REBOOT OR POWER OFF! Hit the up-arrow on your keyboard, double check the command, then press ENTER to execute it again.

I’d like to thank the members of the Lemote Forum community who provided the necessary infromation.

Just a small note that compiz-0.7.8 has landed on a tree close to you.

After it was added on 2008-09-26 to the desktop-effects overlay, compiz-0.7.8 has now been committed to the tree. The 0.7.8 release is currently hard masked pending a final review, but should be unmasked in the next couple of days.

This version uses EAPI-2, so it will require a PM that supports EAPI-2 (currently that means a testing version from one of the 3 PMs). It's possible (preferred) to install compiz-fusion by grabbing the compiz-fusion set from the desktop-effects overlay sets dir.

package failures w/ gcc-4.4 on a barebones headless system:

gcc version 4.4.0-pre9999 built 20081025 (Gentoo SVN ebuild) rev. 141361 ()

dev-lang/perl-5.8.8-r5
dev-libs/cyrus-sasl-2.1.22-r2
dev-libs/glib-2.18.1
dev-python/dbus-python-0.83.0
dev-python/pygobject-2.14.2
dev-util/pkgconfig-0.23
net-misc/curl-7.18.2
sys-apps/busybox-1.12.0
sys-apps/coreutils-6.12-r2
sys-apps/dbus-1.2.3-r1
sys-apps/hal-0.5.11-r3
sys-devel/automake-1.9.6-r2
sys-devel/flex-2.5.35
sys-devel/gdb-6.8-r1

some of these may be testsuites that fail even with other versions (i'm looking at you coreutils and automake). i haven't looked at all of them yet but most i have are segfaults. only one (flex) is a bug, which i've already poked upstream about.

much less work than 4.3 so far. :D

When I wrote Ruby-Elf was mostly looking forward to learn about the ELF format itself and thus be able to understand more deeply the performance issues related to that. The choice of Ruby was so I could gloss over most of the tricks related to C programming, like memory management and error detection.

Over time, especially with the creation of cowstats first and missingstatic after, I thought that Ruby was a suboptimal language for what I’ve been doing; the ELF format was designed with C in mind, and indeed would map pretty well to C processing: you map the file in memory and access it as a single byte array. Pretty nice, but I couldn’t do it (easily) with Ruby. The way Ruby-Elf works is not by saving memory at all, instead it uses lots of memory, parsing and saving in memory all the information read from the ELF file. This has some disadvantages, but also some advantages.

In particular I was reminded of this today, after launching a scanelf process to look for some symbols in all the libraries of the system, I had it crash in front of me while trying to scan the debug files for libstdc++. It was trying to access an out of bound memory area since the file is actually partial (and has to be taken in consideration together with the other half in the stripped file; the fix has been committed to CVS and will be in the next pax-utils release.

But the point here is that with Ruby, such a problem wouldn’t have stopped me during my task, requiring me to put it on hold, start a new one (fixing scanelf) and then coming back to that. If something is broken in ruby-elf itself, most of the times the result is that an exception is raised, which can be rescued in the loop over the files to analyse, so that an error can be outputted to the user, and the processing resumes with the next file.

This is why I originally thought about learning Ada and converting my ELF analysis tools to that: it is compiled, so it should be faster than Ruby, but it’s also very well protected and will raise exceptions when problems are found. Unfortunately I haven’t had the time to learn it yet, which is very unfortunate since I’d really like to use it. For now I’ll have to keep working with Ruby and C, I guess.

One thing that I’m considering, though, is writing a C Ruby extension for byteswapping arrays; the reason for this is that it seems like the most time-consuming task in there is the byteswapping of data read from the ELF file itself.

I also have to consider the idea of implementing the ability of read compressed ELF files, but the fact that neither Zlib nor Bzlib2 have seeking functionalities makes it kinda hard (right now the code first reads through the file the offsets of the sections and then reads them as needed to avoid processing data that’s not going to be used, and to be able to properly identify sections by name when deciding the type.

At any rate, I might just decide to try out a basic scanelf reimplementation using Ruby-Elf for when I need stuff and I can’t wait to fix scanelf…

In my post about glib byte swapping functions I pointed out the inconsistent behaviour of glib’s macros for byteswapping, when it comes down to argument evaluation. If you look at the comments in that post, you can see that Paul points out that a very useful way to do the same thing without the problem of inconsistencies is simply to use inline functions rather than macro. I agree with him that it’s a much more useful thing to do.

Indeed, static inline functions, when the compiler supports them properly (which means, not with Sun Studio compiler), are quite better than macros: their arguments are evaluated just once, always, consistently, they have their own scope for variable names so that you can’t introduce a mystic error in your code by using the same name as a local variable in a macro, they leave the compiler free to decide what the best course of action is for them, for instance, in a loop, and so on. Additionally, they make debug a little easier than macros; when I fixed my problem with scanelf I had a segmentation fault inside a macro call for a 17 lines macro. Not exactly the nicest thing to debug (and actually made me quite wary of scanelf, I start not to like it too much, considered that complexity of the code), as you might guess.

So at the end I decided to go for it, and I submitted a patch to glib that replaces all the byteswapping macros with static inline functions; the code emitted is the same with GCC 4.3 but they are in my opinion more readable and they have more chances to work with non-GNU compilers (the previous implementation for them used the __extension__ keyword that as you might guess is a GNU extension, while static inline is a standard C99 feature).

Hopefully the patch will be merged soon, and at least the newer versions of glib will have a behaviour much more consistent with other libraries too. Now, if I can get to actually benchmark base64 encoding and decoding, and digesting through MD5 and SHA1, comparing glib with libavutil, I’d know what to look at for improvement.

Have you ever been thinking about how you could contribute to Gentoo? Here's a quick and easy way. If you are using stable, take a look at your package.keywords file and file stable request bugs for all the entries there that satisfy the requirements for being marked stable. Meaning there are no open regressions in http://bugs.gentoo.org and the ebuild has been in the tree for at least a month. Even better is if you make filing these bugs a regular habit. I would imagine that most developers are running ~arch so packages that are not that actively maintained might start to fall behind in stable.

I just released a new gentoo-sources 2.6.27 which includes linux patches 2.6.27.1, 2.6.27.2 and 2.6.27.3.

So….

Sync, emerge, make, install, reboot, wash, rinse, repeat.

As always, file bugs to http://bugs.gentoo.org

Hum, 2 blog posts in a week, this is highly unusual for me

Anyhow, back to the point.

About a week ago, I added the old i810 drivers (1.6.5 and 1.7.4) to package.mask. Since then, a few people have opened bugs and have sent me emails asking me to take them out of p.mask. I guess I owe an explanation to all who care about Intel drivers.

The situation is quite simple :

1. The old 1.x drivers are no longer maintained. Period. Upstream no longer cares about them and other distros (at least Fedora and Ubuntu) have started dropping the old drivers from their repositories.
2. Most importantly, starting with xorg-server 1.5, only 2.4.0 and up build correctly. So all drivers older than 2.3.2 do not work with xorg-server 1.5. I hope I made this statement clear enough.

I know that changing drivers can be a big pain, but there are only 2 good reasons for sticking with 1.x, I'll list them here because if you don't care about either, then you should move to 2.x.

• Old Xinerama support. XRandR is a very good extension but in some cases, the old driver was better. Especially with pre-915 chips where the framebuffer is limited to 2048 pixels in width.
• Unsupported chips. This one is very uncommon. In fact, I would say Gilles (eva) is the only one that has an unsupported DAC chip on his 830 tablet.

The rest of you, please try 2.x as soon as possible. If you still have issues, here's what you can do:

• Remove all HorizSync and VertRefresh from your xorg.conf
• Remove all "optimizations" from the Device section (such as forcing OffscreenPixmaps and what not)

If that still doesn't work, please open a bug and we'll try to sort it out.

Thanks

PS, I finally took care of the pkgmove. So please update VIDEO_CARDS in your make.conf to use "intel" instead of "i810".

Update: s/xorg.conf/make.conf/ ... thanks Donnie

A while ago I talked about piping all of my bash commands to twitter.com. I've kind of stopped doing that now, after I maxed out at over 14000 updates in about 2 weeks, but it was fun while it lasted.

But in order to do this kind of thing nicely, I ended up writing a command line program to make it easier. Some people have noticed it at times, by poking around in my kernel.org home directory, so I might as well announce the thing publicly.

So, consider this an announcement of the tool, bti. It allows you to send tweets to twitter.com or identi.ca directly from the command line from any Linux machine. It probably works on other systems as well, but you will have to tweak the Makefile yourself.

The latest version can always be found here.

The development for the tool is done in git, and the tree can be found on the ever-awesome github.com in this repository.

A long long time ago I voiced about the need for a wiki in the Gentoo project. In those days Gentoo-Wiki was starting up.
For some reason or other people inside the project felt that having the users producing documentation was a bad idea. For some other reasons that I never understood the gentoo-wiki.com becamed a banned issue, and Gentoo developers were advised not to mention, and not to link to him. I wrote an extensive article about Gentoo on the Efika board that got some raised eyebrows because it was written on the Wiki.

Now Gentoo Wiki has been down for a few days. And according to the backup page it does not seem a fix is going to happen soon.

If we had taken this project under an umbrella a long time ago our users would not be missing on this very important resource.

here's a fun trap. if you're going to be changing major compiler versions often, you'll want to build lzma-utils with the nocxx flag enabled so you don't find yourself unable to unpack certain patch tarballs when you switch back.

i still don't understand why we even bother with lzma...

Although I started writing some entries trying to uncover the most common mistakes with autotools, I’m afraid it’s going to be difficult for me to cover the mistake sand to actually make them useful. But since I’d rather spend my time helping people with autotools rather than having to fight with crazy buildsystems when I need a new software that is not in portage, I figured out that ther eis one thing I can do to improve the situation: accept requests!

As I did write before, I already take care of fixing some common autotools mistakes when I do my checklist routine so it’s not worse to accept requests to look after some particular software’s buildsystem to help autotolizing it or to fix the autotools, or parallel make failures and stuff like that. For this reason I decided to open a channel on OFTC: #autotools-mythbuster, where you can drop in and ask questions, or request for a buildsystem to be reviewed. If you allow me, I’ll also write about the common problems found in that buildsystem if I think it might be useful for others to know.

If you don’t want to drop by in the channel, you can also write me to flameeyes+atmb@gmail.com and I’ll see to answer and check out the buildsystem. I’m tempted to open a mailing list on Google Groups or something so that eventual comments might be useful to others too, but I’m not sure how much time this will take me so I don’t want to take a bigger responsibility that I can actually handle.

I’m doing this volunteering, for free, to show the way so that I don’t have to deal with more custom build systems that just don’t work (the only non-autotools build system that I find quite good to deal with is FFmpeg, and even that I had to tweak more than a couple of times, and still does not work 100% properly). As such I don’t guarantee results, I might not be able to look after your code right away (and to begin with, when this entry will appear on Planet I’ll probably be busy and/or sleeping, since I’m writing this from my bed on the laptop). I’ll be happy to help you, and if I can get your buildsystem up to standard, that’ll be enough of a result for me (I’m happy to receive gifts though).

I’ll wait for you on #autotools-mythbuster @ OFTC then!

As some of you may have noticed, I started slacking lots and lots over the summer… Basically, I originally intended to take a month-long hiatus, but for some reason, found it hard to get back into Gentoo development again, and have also been putting it off due to lost GPG and SSH keys, and other niggly things like that…

I’ve now decided to actively get back into development again, and have got a new GPG key, and got my SSH key sorted out, and made a couple of commits (minor bump and a small bugfix) to get started again.

I’m planning to get a new computer (Intel Core 2 Quad - will post more details when I get further into the process of aquiring the computer), which will hopefully allow me to run more virtual machines for the various areas of development within Gentoo which I’m involved in.

Hopefully you’ll be seeing a lot more activity from me again, especially as my first year at Aberystwyth looks although it’ll be relatively relaxed and straightforward

so with midterms looming, i did the sensible thing and began gcc-4.4 testing. so far a couple bugs in @system - flex needs a header addition, perl ICEs, and some testsuite failures I have to look at. worlds apart from when 4.3 was at the same stage.

speaking of which, i'm looking at the god-awful job stabilizing 4.3 is going to be and involuntarily gagging. maybe if we wait another year enough 4.3 fixes will trickle down to stable on their own and we can avoid b.g.o imploding under the mass of another 500-bug gcc tracker.

i should also have a couple new (haha) mips boxes on the way soon, an octane and an octane2, to heat the apartment this winter. oh and maybe even keyword some things.

*sigh* I should have written this post a long time ago, but I didn't. My bad...

And just yesterday, Sune was rightfully complaining about the situation. Now it's my turn to blog and to let you in on all the secrets I've been withholding

Quick xorg-server 1.5 Input How To:

If you've built xorg-server with the USE=hal, you might have weird issues with your synaptics touchpad or weird keyboard layouts.

There are currently 2 ways of configuring input in Xorg :

1. Disabling HAL in Xorg: it basically tells Xorg not to look at HAL for input devices and it'll only read your xorg.conf for configured devices. If you don't want to muck around with HAL yet, it's probably a good option. Just stick this piece in your xorg.conf and you'll be fine.

   Section "ServerFlags" Option "AutoAddDevices" "false" EndSection

Migrate to HAL: this is not exactly trivial and might require a lot of tweaking. But once you wrap your head around it, it's not that complicated.

The idea is to completely remove all the InputDevice sections from your xorg.conf (or even to completely remove your xorg.conf) and let Xorg request input devices from HAL. But we can modify HAL to return configuration values to Xorg.

For some examples of this method, I suggest reading this sample file which contains almost all the needed documentation.

Don't forget to read /var/log/Xorg.0.log towards the end, that's where input handling prints warnings and errors.

Intel graphics driver with xorg-server 1.5

For some reason, the server crashes if your xorg.conf file tries to load the i810 driver instead of the intel driver. This is indeed really weird as the former has been a symlink to the latter ever since 2.0.0 came out. I'm guessing the migration to libpciaccess broke some assumptions about driver names.

A lot of people have been bit by this, including me, but I of course do intend to properly fix this. First I need to do the pkgmove, and then I'll just remove all references to "i810" from installed files (mostly the symlink to the driver and the duplicate man page). Finally, I'll make the driver print out elog messages if you still have the old driver name in your xorg.conf

GEM

Although I first believed otherwise, a lot of users were actually using TTM with xorg 1.4. Since TTM has been dropped from Mesa and the supporting bits have been removed from the Intel driver, a lot of people are anxiously waiting for GEM support to arrive.

First the good news, I'm actually working on that. I'm tracking branches and building code.

The bad news... it doesn't work, at least not yet. Intel developers are busy adding support for G4x chipsets and older ones such as my 855GM are not the immediate priority. I've asked for help on the various mailing lists but I'm still waiting. To be honest, I'm not even sure I've built the various components with the right configure options...

My plan is to wait a little bit for the kernel bits to settle (right now, devs are hacking up 5~10 patches per day for the 2.6.28-rc1 merge window!) before asking again.

Watch this space in the coming weeks if you are interested in Intel graphics on a Gentoo system near you

Cheers

A few months ago I’ve written about DEPEND and RDEPEND as Josh noticed in the comments, I’ve outright ignored PDEPEND in that instance, since I didn’t really want to open a can of worms relating to that. Now I think it would be a nice time to open that can of worms.

Portage already started blurring the separation between RDEPEND and PDEPEND; PDEPEND may be brought in before the package it’s reported in, to help breaking dependencies; which is, after all, what PDEPEND was born for, as both Petteri (in that post) and I think Brian (some time ago) repeated. I think this would be a nice starting point for trying to blurr and finally remove the separation between RDEPEND and PDEPEND.

I got htis idea while doing my tree-build for testing, the idea is that -B should work; but it really doesn’t a lot of times, since developers try to see if their software builds in general; rarely they test if it builds on a clean slate chroot; even more rarely they check it builds without its RDEPEND installed. I’ve been fixing a few of these problems in the tree, without even asking to be honest, as this usually comes down to bitrot that predates EAPI ideas (empty DEPEND meant “use RDEPEND” in the past), or to typos (REDEPEND or DEPEND=$DEPEND), so they are very trivial to fix. But this is far from optimal since I’m testing one package after the other and it’s not really so easy.

An option I proposed to Zac was to make portage have a developers-only option that installed packages treating RDEPEND as PDEPEND, so that the build of the package is triggered without having the runtime dependency installed. This was what made me think about it.

If every package was stating DEPEND and RDEPEND properly, PDEPEND wouldn’t be needed at all; the package manager would be allowed to treat packages in RDEPEND only so that installing them would be indifferent before or after the package that brought them in. Now of course this has a bit of a problem: if a dependency failed to install and was installed after the package you’d be having a non-working installed package, so I guess it’ll have to be evaluated quite more deeply, but it at least seems an idea to think about.

Of course making this change will require a new EAPI, so the proposal should be prepared as soon as possible so that it will fill in the tracks for EAPI=3, but that’s beside the point right now, I just wanted to put in writing an option that I think would be very nice indeed to simplify ebuild writing (dropping a whole class of dependencies!) and at the same time allow for proper dependency cycles breaking.

Now of course, before this can be even considered, it’d be nice if the tree was checked properly for dependencies…