Re: [application] pyPianobar (with pianobar)
 

The problem is related to the fact that pianobar in the new version changed location. So the front end tries to start it and its not where it should be.

Re: [application] pyPianobar (with pianobar)
 

The latest pianobar was done with the autobuilder instead of me doing it by hand. /usr/local is where pianobar installs itself normally if you were to build it from sources... it's all optified though... if you look in /usr/local you should just see links to pianobar into /opt/ somewhere.

I had thought that when upgrading it would have removed the other one since it was tied to the old package.. I'll have to check it out. For the old one just use the one that is in testing instead of devel.

Re: [application] pyPianobar (with pianobar)
 

I don't put a path into the code for pianobar I don't think.. so this would surprise me... if it's in both locations.. which I gathered from you saying it "doubled up"... then it should still work from either binary - one is just unnecessary. If it's only in the one place in /opt/usr/local then that's where it's supposed to be..?

Now I'm confused.

Re: [application] pyPianobar (with pianobar)
 

Ok I just updated my scratchbox from the old version to the new and it *did* remove the link in /usr/bin/pianobar like it was supposed to and it's now in /usr/local/bin/pianobar which is where it normally *should* be.

It didn't clean up /etc/pianobar though which is a little annoying.. since the config location moved to /usr/local/etc/pianobar..

So if you've upgraded you can remove /etc/pianobar directory completely.

It still runs for me though.. after the upgrade:
So can someone run from the command line and see if it still works? Bratag - did you hard code /usr/bin/pianobar into qtPianobar? With python I was able to just "popen("pianobar")" and it pulled it out of the path instead of hard coding it.

ETA: Oh, because /etc/pianobar is a "config" file it won't remove it unless you "purge" pianobar first.. I see. I might have to put that into a postrm or something.

Re: [application] pyPianobar (with pianobar)
 

I actually did hard code it, I was never sure if the path would include the location of the app. That being said I hate hard coding stuff.

Re: [application] pyPianobar (with pianobar)
 

My fault.. it didn't occur to me it break the front-ends - I should have sent you a warning first when I realized the location was going to move having it auto-build instead of having me do it.

The only thing I don't like about the new one is the config location.. I would prefer it to stay in /etc/pianobar... I don't know of any app that uses /usr/local/etc for anything.. but pianobar doesn't come with an example config so I had to add it to the CMakeList files myself and evidently I am not fulling understanding the proper way to do it.

I'm not sure what to do at this point.. having auto-builder do it is the "proper" way to build the app.. do I leave it as is and you fix qtPianobar.. or do I find some way to pass an environment variable or something to auto-builder so that it builds in /usr/ instead of /usr/local ??

Re: [application] pyPianobar (with pianobar)
 

Well ultimately I would like to see nothing in the /usr tree at all and certainly no configs in /etc. All apps should go into /opt as per optification rules to avoid using rootfs space. No configs should go into /etc that are not daemons or system level software. I much prefer the config in the user space.

Re: [application] pyPianobar (with pianobar)
 

Well wait.. you and I are crossing here.

Pianobar is optified by maemo-optify. /opt is not a normal area and thus not usually added to $PATH because /opt can contain several different ideas:

/opt/package
/opt/maemo/package
/opt/maemo/bin
/opt/(insert random character that the developer decided he wanted here)

etc..

It's not consistent. So what you do is you create the directory tree.. just the directories (we're talking taking up a single inode here on the rootfs).. in the rootfs for like /usr/local/bin.

Then you link the application from the optified location, to the rootfs location.. so you get:

So, the app itself is taking up space in /opt/maemo/usr/local/bin .. and something like 3 INODE's, and then a link to the other filesystem, is being taken up in Rootfs.

No real, noticeable, space is being taken on rootfs at all.

Re: [application] pyPianobar (with pianobar)
 

Yeah thats perfect. Sorry think we had crossed wires there :)

Re: [application] pyPianobar (with pianobar)
 

Yeah.. the nice thing about maemo-optify in my rules file is it did all that for me. It however, did *not* appear to do it for my config file.. it's really in /usr/local/etc/pianobar/config.. that's not a link. Not a huge deal as the file itself is like 979 bytes or something.

So what I meant earlier was:

I'm not sure if we want to leave this as is, because this is way pianobar will be built from desktops down to little tablets... or if I should find a way to instead pass the make to /usr.

What this will do effectively, is put the app in /opt/maemo/usr/bin and link it to /usr/bin/ which is where the old version of pianobar I think was.

It'll also move the config file to /usr/etc/pianobar/.. at least unless I statically code the config to go somewhere..

Any suggestions welcome on where this package should reside.