On Monday 05 November 2012 14:45:23 Jannis Achstetter wrote: > Am 05.11.2012 13:20, schrieb Gavin Pryke: > > 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! > > No offence taken here :) > I just remembered s.o. mentioning in a mail that space (was it webspace > or space for the repository?) was getting sparse on tuxfamily.
I wondered this too but here http://faq.tuxfamily.org/Downloads/En states that hopefully we have 1024MB for static files available, the contents of which are at: http://download.tuxfamily.org/proaudio/ > > 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. > > This is where I see it getting more difficult for ebuild > writers/maintainers. > > A live-ebuild can be written, tested and submitted easily since everyone > here has internet-access and can checkout any repository. Snapshots > (tar-archives in this case) must be created, stored and uploaded (except > for some few that are small enough to be attached to an email but I > wouldn't want to send such an mail to the mailing list). > > Without haveing direct SVN write access, it's quite some work to > "submit" a snapshot-based ebuild. > > Another way would be to specify ESVN_REVISION or EGIT_COMMIT as > mentioned by Dominique. That would be some kind of "snapshot" but w/o > tar-archive but from the official repository. I don't have a problem > submitting ebuilds that way but I personally prefer real "live" (aka > HEAD/trunk) ebuilds. Also hybrid ebuilds are possible that check the > version number of the ebuild's filename and do a trunk-checkout if > version is "9999" and a specific (tested) revision/commit otherwise. Sure, live ebuilds have their uses but for something I would want to commit to the overlay I'd rather snapshot it because at that point in time the 9999 should work anyway, converting to a snapshot is only a few more commands to create the tarball and a change of SRC_URI to point to the snapshot. For that small amount of work it can save a lot of people complaining about failing 9999's all the time when no dev is around to fix it. Now I see tuxfamily has that space available I will start using it. I really have no objections to live ebuilds, like you say it's more convenient to send to the list. I have very many live ebuilds in local overlays but I still prefer creating snapshots even for local use as I find it's less work in the long run when I need something to stay working. I'm not saying stop sending live ebuilds to the list it's just that I think it seems friendlier and less error prone as a user trying to emerge a snapshot rather than a live ebuild. Most of the packages in overlay have released tarballs available so it's a non-issue, it's only the nice software that have no tarballs (postfish, non etc) that I would want to snapshot, it also saves the hassle of a having all manner of VCS installed on my DAW too. WBR Gavin
