| Re: [proaudio] non working ebuilds (was non-things ebuild not builds) |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/proaudio Archives
]
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 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.