One user report from Korea: I got help from spec.in files in trunk while porting efl libraries to Tizen.
Daniel Juyung Seo (SeoZ) On Wed, Dec 12, 2012 at 8:19 AM, Lucas De Marchi < [email protected]> wrote: > On Tue, Dec 11, 2012 at 6:58 PM, Rui Miguel Silva Seabra <[email protected]> > wrote: > > On Mon, 26 Nov 2012 11:57:49 -0200 > > Lucas De Marchi <[email protected]> wrote: > > > >> > Now tell me which distros would include a weekly (or so) updated > >> > EFL+e17? > >> > > >> >> IMO it's better maintained by people that care > >> >> about it > >> > > >> > I care about it, as probably do care other who build svn into rpms, > >> > and it doesn't hurt you. Following your advice would maybe make you > >> > happy, but hurt me. > >> > > >> > Is a neutral-win situation so undesirable you'd rather win an > >> > argument and make me loose more integration? > >> > >> yep, that's why I just sent an email instead of reverting the patch. > >> Even if I don't like it. Also this is in edbus, not E. > > > > It's irrelevant, I'd need the dependencies built as RPMs and it's much > > better to have them built from the resulting make dist. > > > >> >> , i.e. package maintainers. > >> > > >> > Since I don't have enough time to contribute with C code, at least I > >> > can contribute with a generic rpm spec that a released package can > >> > carry. > >> > >> Arch and gentoo have their own way to build *packages* from svn/git, > >> without requiring you to change the build script. Doesn't RPM have > >> such a thing? > > > > If one wants to have *more* work, not less, one can maintain it > > seperately. Doesn't seem smart, to me. > > > >> What really bothers me is distributing a .spec. This demonstrates > >> intent to support rpm, but not the others. > > > > No, it doesn't. What it shows is that there's an rpm user who cared > > about it. It's absolutely no statement on the others. > > > >> And if it's not an intent, > >> people start submitting patches to have their PKGBUILD, ebuild, > >> whatever-build-their-distros to upstream projects. Also this rpm works > >> in your distro, but not in another-random-distro-using-rpm. So > >> *distributing* the spec may not hurt me, but it will for other people. > > > > I try to have it as agnostic as possible, also, I've seen no > > complaints, so there is no need for scarecrows. > > > >> So, since you are building from unreleased svn/git, would it hurt you > >> to at least not distribute the .spec? > > > > Why do you insist on wanting to make it useless? > > > > It doesn't hurt you, but all you propose hurts me (anything taking time > > away from me hurts me, including this surreal talk). > > ahn? Removing from EXTRA_DIST hurts you? It's useless for me and this > type of thing is avoided in several projects I work with. But I won't > argue anymore.... Keep it if you want. > > > Lucas De Marchi > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
