Re: Small request regarding the 0.5.0 release.
- From: Walther Maldonado <walther.md@xxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Fri, 14 Nov 2008 13:54:13 +0100
On Fri, 14 Nov 2008 12:17:26 +0100
"Liviu Andronic" <landronimirc@xxxxxxxxx> wrote:
> On 11/14/08, Walther Maldonado <walther.md@xxxxxxxxx> wrote:
> > It was easy to work around, that is true. I just suggested that the package
> > version convention would be accepted to make for a smoother integration
> > into Portage. if this small mistake is not going to be corrected, very
> > well, I will suggest the modified ebuild to support this inconsistency
> > anyway.
> >
> Could you please post a link to the ebuild you'd like to propose? Or,
> if bug report already submitted, the link to the bug? I feel the
> Portage ebuild supports too few USE flags, and that it would be
> relatively easy for the ebuild to support many more.
> Liviu
>
The ebuild is pretty much identical to the previous version, since I was in a
rush and was not interested in trying to optimise it. The previous ebuild can
be seen here:
http://gentoo-portage.com/app-misc/emelfm2
The only difference is that the file would be named emelfm2-0.5.ebuild, and the
SRC_URI changed to:
SRC_URI="http://${PN}.net/rel/${P}.0.tar.bz2";
Naming the file emelfm2-0.5.ebuild is kinda ugly, but it was the easiest work
around without having to change S (the default ebuild would fail on the unpack
function, where it does:
cd "${S}"
I can't find now the related Gentoo doc, but if memory serves right, S is one
of those variables that should be read-only according to the guidelines.
I don't really know why emelfm2's ebuild is not more clean (like most standard
ebuilds), maybe with the 0.5.0 release some of the extra code from the ebuild
can be cleaned... I just haven't looked into it.
Walther.
--
Users can unsubscribe from the list by sending email to
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by
logging into the web interface.
Other related posts:
