On Monday 05 November 2012 08:59:22 Jannis Achstetter wrote: > Am 05.11.2012 02:33, schrieb Dominique Michel: > > The problem with snapshots is that they are taking a lot of space on > > the server. Anyway, this must be possible. But we can make > > snapshot-like live ebuilds: As example, the subversion eclass provide > > ESVN_REVISION. The doc claim that it should never be used into an > > ebuild, but I already used it, and it worked just fine. > > If you need webspace to host source tarballs I'm happy to put them onto > my server. > > > # ls /var/tmp/portage/media-sound > > [...] > > I'm personally interested in these: > ambdec > patchage > qmmp > zita-rev1 > jack-capture > > and since all of them seem to work here: can you please post the > build.log files somewhere so I can take a look at them to get them fixed? > > Thanks :) > > Jannis
Hi and apologies in advance for this burbling email, it is my thoughts on trying to maintain this overlay and the trouble we face. I ran an emerge like this on an arm machine some time ago tinderbox style, tons of packages are broken and we don't have enough resources to cope. We have enough problem with ebuilds not working gotten from tarballs let alone the amount of packages in tree that download from source repository that are mostly always broken after upstream change layout or build system soon after a commit. At least a tarball snapshot should stay working unless some major upgrade like gcc or library dependency upgrade breaks it. With a live ebuild the smallest trivial change upstream can break the package and render it unusable at the worst possible moment, likely when one really have a use for whatever package is failing and one doesn't have time to dig into the ebuild/source to fix it. If one wants to gauge how much needs looking at just take a look at repoman output after running it in the root of the pro-audio tree, it really is a mess! I am in no way saying my ebuilds are perfect, because nothing could be further from the truth; I have dumped my fair share of crap in the tree and I have made many mistakes since my journey into packaging on Gentoo. The sad thing is though lots of these errors could have been caught by running a simple repoman check before committing. I'm also not saying repoman can fix dodgy ebuilds, because it can't. It can however point out trivial errors (LICENSE, bad DEPEND's etc) even if the ebuild does "work". I have space on my server with enough bandwidth for hosting snapshots too but I thought it would be better to have everything on tuxfamily rather than scattered around on different servers. No offense Jannis because this really is much appreciated! I say this because have already changed or removed quite a few ebuilds where SRI_URI points to files that have been moved or deleted or a tarball that has been modified compared to official source, that's what patches are for! Snapshots for our overlay really wouldn't take that much space I think if the unreferenced files are cleaned out regularly. I'm getting really tired of trying to maintain live ebuilds now purely because I don't have time for fiddling with source layout changes when I want software to just work. At least with a snapshot one can come to it and update as time permits. It would be different if there were dedicated maintainers for every package watching for changes but how many of the ~15 devs with commit access to this overlay are active at any one time? Not many when we have ~374 packages! For me snapshots are the only way forward. I'd rather compile a source checkout manually because it's easier than fiddling with live ebuilds that are broken often. In contrast I am happy to commit any ebuild that references a tarball in SRC_URI because less time is spent digging through source trying to find what changed. I hope I have not offended anyone writing all this because I really do appreciate everyone's effort put into this overlay. It's just hard to keep coming back to this overlay when so much stuff keeps getting broken when it doesn't have to be like this. We need more help. WBR Gavin
