[Synce-devel] usb-rndis-ng-9999 ebuild

[Dmitry Zamaruev]

As I could see in SVN - usb-rndis-ng ebuild was copied from
usb-rndis-lite and changed somehow. But it fails on install :)
I attached new usb-rndis-ng-9999 ebuild that correctly installs 'ng'
driver. It could be easily modified to use 0.10.0 SVN release, because
usb-rndis-ng is missing 0.10.0 ebuild at all.

Also I have some related questions:
1. Is there any need in --enable-hal option in usb-rndis-ng? Without HAL
ng driver makes no sense to odccm, and without odccm all this system
makes no sense :) May be it is better to make hard depend on HAL?
2. All 0.10.0 ebuilds are using SVN branch, while there tar.gz files on
SF.net - as 'release' files available all ebuilds must use given files.
It would be more suitable for 'common' users trying to install
synce-0.10.0. While I'm using *9999 ebuilds I could convert\check all
0.10.0 ebuilds to use tar.gz from SF mirrors (if no one else doing this :).

[Richard Alimi]

Post by Dmitry Zamaruev
As I could see in SVN - usb-rndis-ng ebuild was copied from
usb-rndis-lite and changed somehow. But it fails on install :)
I attached new usb-rndis-ng-9999 ebuild that correctly installs 'ng'
driver. It could be easily modified to use 0.10.0 SVN release, because
usb-rndis-ng is missing 0.10.0 ebuild at all.

I've added your ebuilds to the overlay for both the SVN and 0.10 release
versions. Thanks!

Post by Dmitry Zamaruev
1. Is there any need in --enable-hal option in usb-rndis-ng? Without HAL
ng driver makes no sense to odccm, and without odccm all this system
makes no sense :) May be it is better to make hard depend on HAL?

This makes sense to me. Can someone more familiar with usb-rndis-ng comment
on whether usb-rndis-ng has any use without HAL? If there is indeed no use
without HAL, then I think we should go a step further than Dmitry's
suggestion and just require HAL in the ./configure script (and raise an error
if it isn't found).

Post by Dmitry Zamaruev
2. All 0.10.0 ebuilds are using SVN branch, while there tar.gz files on
SF.net - as 'release' files available all ebuilds must use given files.
It would be more suitable for 'common' users trying to install
synce-0.10.0. While I'm using *9999 ebuilds I could convert\check all
0.10.0 ebuilds to use tar.gz from SF mirrors (if no one else doing this :).

I have everything building from SVN for ease of maintenance. Keeping them all
as similar as possible (all that needs to change typically is the repository
URI) makes them just a little bit easier to keep track of.

The only problem that I've come across with building everything out of SVN is
the one mentioned in the Wiki page for the ebuilds. This only occurs when
you switch between emerging the 0.10.0 release and the SVN trunk versions.
Unfortunately, this problem will also surface when we make another release
and people emerge the new ebuilds. If there is a simple change in the
ebuilds to get around this problem while still building out of SVN, I'd like
that (Dmitry -- do you know of a way?). If not, then perhaps building from
the Sourceforge tarballs is best.

[Dmitry Zamaruev]

Post by Richard Alimi
I have everything building from SVN for ease of maintenance. Keeping them all
as similar as possible (all that needs to change typically is the repository
URI) makes them just a little bit easier to keep track of.

Ease of maintenance is a good thing for developer :)
But as common user I don't want to wait while emerge will compile
subversion and all of it's deps. And don't want to even know about
subversion. Also SVN repository could be unaccessible while SF.net
mirrors are managed in Portage system and will try to fetch from all
over the world. Also with tar.gz files it is more chances that synce
0.10.0 will make its way into Gentoo portage tree and distfiles mirrors.

Post by Richard Alimi
The only problem that I've come across with building everything out of SVN is
the one mentioned in the Wiki page for the ebuilds. This only occurs when
you switch between emerging the 0.10.0 release and the SVN trunk versions.
Unfortunately, this problem will also surface when we make another release
and people emerge the new ebuilds. If there is a simple change in the
ebuilds to get around this problem while still building out of SVN, I'd like
that (Dmitry -- do you know of a way?). If not, then perhaps building from
the Sourceforge tarballs is best.

To avoid this problem 'subversion' eclass provides variable
ESVN_PROJECT, that is defaults to ebuild name (usb-rndis-ng for example).
In ebuild you need to put:
ESV_PROJECT=${PF}
that will change project directory to full ebuild name
(usb-rndis-ng-0.10.0 for example) and the distfiles structure will be:
svn-src/usb-rndis-ng-0.10.0
svn-src/usb-rndis-ng-9999
So different versions will not overlap. But this could not save from
moving SVN repository inside one version.

May be I could join your team and help somehow?