Re: [proaudio] non working ebuilds (was non-things ebuild not builds)

[Gavin Pryke <gavinlee303@xxxxxxxxx>]

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