Bugzilla Bug 11184

Synchronize Windows CE devices with computers running GNU/Linux, like MS
ActiveSync. 

A little note on this ebuild however. It doest *not* work as is, because this
ebuild will try and download 4-5 files (depending on USE) and compile
and install these. They are all part of the synce package, and they all need
to be installed in order to use the synce package. However, I feel its a
complete waste of space and resources creating 5 separate ebulds for one
program basically.

But as of now, I have a rather huge problem with the ebuild. The ./configure
script for the second file checks if the first file (libsynce) is installed.
However, the libsynce is still located in the sandbox and not merged with /
yet. There is no way to disable the checking for libsynce in the configure
script afaik. But is there a way this can be solved still, without creating
two or more ebuilds? Ive discussed this issue in the forums
(http://forums.gentoo.org/viewtopic.php?t=23223), but havent really found a
good solution yet. I have created separate ebuilds if you really request
that, but I wanted to ask if it really is neccesary or if there is another
way of solving this.

Cheers and thank you!
-Frank

Created an attachment (id=5927) [edit]
synce-0.3.1.ebuild

Ive chosen the version number on this ebuild according to the version number on
the daemon in the program package.

If a developer strongly feels that each file should have its own ebuild, I will
not protest - i can see both positive and negative aspects when doing every
file in one ebuild. However, I just had to ask someone very fluent in writing
ebuilds about their oppinion. Hope this doesnt cause any problems.

Cheers!
-Frank

Created an attachment (id=5928) [edit]
digest-synce-0.3.1

I love what you're doing here.  I'm interested in the package for myself.

I do believe that the ebuild needs to be split up.  We will have a app-pda 
category to prevent clutter elsewhere, so worry not. It's the Right Thing To Do.

I will take care of it this weekend, as part of creating the app-pda category.
I'm looking forward to being able to sync my ipaq for the first time since this
summer. :)

Okay, I've got this emerging successfully as five seperate ebuilds.  I  
had to pull in most of gnome to do it, and I'll have to get gnome working  
on this previously kde exclusive machine before I can test it.  Small game  
delay for me there.  
  
Nevertheless, it looks good and I'm commiting it for testing asap.  Look  
for the ebuilds in your portage mirror soon. :)  
 

These have been committed as ~x86 masked in app-pda.    
  
Please test them and report your results here.  In particular, I have not   
added back the informational message or RDEPENDS (like ppp).  At this point,  
the DEPENDS for each ebuild seems minimal.  
  
I will test them after sleep, but they will remain masked until we get  
good feedback here of actually working syncs. :)  

Great work! Some comments/questions:    - In the description field for each
ebuild, perhaps it should reflect what the   actual ebuild contains, and not
repeat " Synchronize Windows CE devices with  computers running GNU/Linux, like
MS ActiveSync"? That is, when we now do   split them up anyway?    - I didnt
find the program intuitive at all, after installing every tarball   for the
first time I sat there going "Hmmm what now?" Of course, if you've  used the
program before - there's no need for einfo (it just clutters the  screen), but
perhaps new users would find it very usefull that there is indeed  a "How to
get connected" page somewhere out there.    - One thing I havent tested though,
but is this program even useful if you   dont install every tar.gz file?
(except the gnome-part) I was under the   impression you needed them all to do
useful things. If so, perhaps make the  DEPEND variable drag in every ebuild?  
- DEPEND for ppp should definately be there imo. It is required for normal 
operation. Perhaps I misunderstod you as to why ppp shouldnt  be a dependancy
:-)   Also, synce depends on check (I see you've snatched it already ;) but on
last rsync it didnt appear. Probably slow mirror, or perhaps check isnt
commited to CVS yet.  Cheers and thank you for commiting to this "bug"!  -Frank 

Completely off topic, but is there actually any way I can prevent my posts 
from appearing on one line? *grrr* I did press enter after each line, but  
konqueror asked for username and passwd, so I guess a foul-up happened  
somewhere in between... annoying 

Bugzilla has... limitations. :)  Press enter. It sucks.  We live with it
because
it does make our life so much easier despite its quirks.  However, it allows
you
to put short verbatim code or patches and not have to worry about newline
mangling.

Anyway, the split was done because they are seperate packages, and it allows
new
packages to be added without disrupting existing users. For example, I am
interested in helping add a synce-usb package, so adding it in this case is 
much easier than the monolithic approach.

However, I agree with you. The info needs to be put back.  I am looking to add
a
synce ebuild that pulls in all of the packages (and optionally trayicon),
prompting the users, perhaps even running a prompted script to set things up.

Only synce-trayicon has the gnome dependencies, and I'm talking with the 
package maintainer directly now to help determine which packages need which
runtime dependencies.  There's also talk of a new version....

The synce developers release things faster than I change my socks! Well, not  
really but you get the picture... Who is responsible to bump the ebuild once  
a new version is available? If its me, it seems kinda backwards I have to go  
here and post a new comment with new version numbers and md5 checksum. How do  
I become a gentoo developer, so I can for eksample maintain my own ebuilds? Is  
it an exclusive club? :-)  
  
Anyway, these are the latest versions of the synce package:  
  
synce-dccm-0.5.tar.gz c76e2ec3e96e76cd2ad5800de6cfbad8 183076 
synce-librapi2-0.5.tar.gz 4f9143012f55dacb4f93ebd10a853e08 269520 
synce-libsynce-0.5.tar.gz f51745d3a962dc83338fc543d7f8cab1 226937 
synce-serial-0.5.tar.gz 40499748059d6c3039ff77f790fc256e 178010 
synce-trayicon-0.3.tar.gz 5c510ef1cce723689379d3f0d24d8027 223350 
  
Hope you'll update the ebuilds as soon as possible. BTW the existing ones  
works perfectly here. Ive also started looking at porting the synce_kio slave  
to kde3, but I have to finish my exams first. This will be my primary goal for  
this xmas programming. I expect the synce_kio to be a plugin for konqueror,  
and that means we'll also need a trayicon for KDE. Seems like the perfect   
opportunity to start with KDE app development.  

I am responsible for updating the ebuilds, and I will commit the ebuilds for
the
new release very soon.

Then I assing this to you, Zach.

this bug is fixed; newer versions or synce ebuilds are in portage