AppPkg... An improved RoxApp or AppDir.

[seaside]

sunburnt,

What can I say?

This would be absolutely terrific to be able to use established packages like Ubuntu's delivered right to the doghouse.

Some things to think about might be the differences between where Ubuntu looks for binaries and libs vs puppy. Many are ok with Lucid but perhaps not all.

I think of all this as I do sfs files - many will work just fine as is, but many will also need some individualized help to work.

Regards,
s
(Did you find a place to upload your latest prototype?)

[sunburnt]

Hi seaside; Good to hear from you.! I`ve seen SFS files that work without a union...
There`s not much difference between them really. RoxApp types just need more setup.
But I really like the idea of apps. that work in any Linux setup: Full, Sq. File, Union or not.

Q; How important is it to CLI run the apps.? All apps. are GUI, so not so critical I think...
To CLI run them a link`s needed in the path. Just another leftover mess to clean up.

Seaside, I don`t have a place to host anything, and I`m told Puppy`s size limit is 2 MB.
# I have a few AppPkg apps. in the new setup, and more in older formats for sharing.
# I`ve got the AppPkg Builder working, it needs more refinement to be fully workable.
... It has to be able to build an AppPkg complete from most Ubuntu packages.

I like the idea of using binary files, compiling is more troublesome and distro. specific.
By the looks of it, Ubuntu Universe packages are good for nearly all the Ubuntu distros.
So if a Linux distro. is made with Ubuntu compatible files ( kernel, libs., etc.), harmony!
Puppy Lucid and the new Puppy Precise should both work with the same Universe files.

The exec. and lib. paths are set, and a link is made in /usr/share for deps. (if needed).
The /usr/share link is the only one needed, desktop and icon links are for a system menu.
This works on all I`ve tried, I saw /etc in the Xfe pkg. but Xfe seems to work without it.
/etc and /var are 2 items I haven`t addressed, but /var is kinda system stuff related.
A well written app. should generate it`s files in /etc and /var. If not then auto. link it.
I haven`t seen any app. yet that uses /usr/etc or /usr/local/etc ( weird ).

# Someone who has built a lot of apps. could help me out on this.
# What else needs to be taken care of to make most apps. work?
# I think I`ve got most of the important stuff taken care of. But...

I intend for AppPkg to be for general user apps., not damons, servers, services, etc.
As it matures these items can be added, a Samba + NFS AppPkg could be made now.
The ambiguity of Linux apps. is a problem in itself, so odd ones are probably common.
Things like icons and what`s in the desktop files can`t be relied upon, and other stuff.
The big apps. like the Offices will be interesting. Browsers don`t appear to be difficult.

[seaside]

Q; How important is it to CLI run the apps.? All apps. are GUI, so not so critical I think...
To CLI run them a link`s needed in the path. Just another leftover mess to clean up.

I like the idea of using binary files, compiling is more troublesome and distro. specific.
By the looks of it, Ubuntu Universe packages are good for nearly all the Ubuntu distros.
So if a Linux distro. is made with Ubuntu compatible files ( kernel, libs., etc.), harmony!
Puppy Lucid and the new Puppy Precise should both work with the same Universe files.

sunburnt,

Not sure what you meant by "How important is it to CLI run the apps.?" Were you referring to the ability of a user to start programs with extra parameters? If so, perhaps that would vary by the program- items like Mplayer, VLC and imaging programs come to mind as likely candidates.

I've never looked at the filesystem structure of Ubuntu and wonder if it's exactly the same as Puppy Lucid in a way that guarantees that if it runs on Ubuntu - it runs on Puppy Lucid.

Of course, even if say, maybe 70% would run with no problem, that would be great, if they represented mostly the important programs that users want.

It seems attractive to have a directory where a script sets the environment to find binaries, libs and config files, and then starts the exec, all wrapped up in a package by automatic means and without customization (if I understand correctly)

I'm glad that you asked about ldconfig in another thread, because it always seemed to be an addon program to manage a faster access to libs and always begged the question "if it's in the lib path environment - why does ldconfig need to be run? Is there an important difference in loading time with the speed of todays computers?

Thanks for your efforts and I hope you can find somewhere to put the prototype.

Regards,
s

[sunburnt]

seaside; Yes arguments, and just how important to be able to run in rxvt. As for run arguments to the app., a script or desktop link can do that also.
I`m thinking it`ll be okay to leave out having the execs. in the $PATH. The apps. env. path is set in the run script so the app. will find it`s exec. deps.

The SFS setup I made got complex as it matured and was not very simple or portable anymore, lots of infrastructure to install to the target O.S.
So I looked at RoxApps and saw the value of the dir. to hold menu files and a menu exec., and the script to mount/unmount, set paths, make links.
So now it`s completely portable, no infrastructure to install at all except a menu handler. Cost is adding 300 KB outside the Squash file to do it.

I like the idea of a simple "add-on menu" app. as it doesn`t mess with the system menu (so many different types), and it will be an AppPkg!
I have a nice small popup/down menu that`s a clock, click it and it pops out. So it can be placed in a corner of the screen and opened when needed.

Ubuntu pkgs. are pretty much the same as Debian as far as I can see (.deb). I`ve used Debian pkgs. in Puppy for years, with some hiccups of course.

ldconfi precedence is set behind LD_LIB`_PATH , so it`s slower in that regard. The ld.so.conf lib. file list is no different than a path, so is it better?

[seaside]

ldconfi precedence is set behind LD_LIB`_PATH , so it`s slower in that regard. The ld.so.conf lib. file list is no different than a path, so is it better?

sunburnt,

I think you're right, as far as I can tell, if some package has something like "/opt/someprog/somelib.so" in it, nothing automatically recognizes this and updates either the lib_path or ld.so.conf. So it must be specifically done for that package. Maybe an automated search could be done on every package for libs outside the normal structure and then exceptionally set at run-time. (Unfortunately, adding more processing)

Regards,
s
(By the way, I really applaud your decision not to compile source code on the fly for this project )

[sunburnt]

seaside; That`s what I just did last night!

Listing missing libs. and removing ones found in the Package`s /usr/lib
It took a surprisingly small amount of Bash code to do it.

ldconfig is the only lib. update tool I know of. It seems a silly way to do it, but...
As far as I`ve seen, no Ubuntu packages use /opt., or even /usr/local/lib
So all I`m searching in is the system`s /usr/lib and the package`s /usr/lib
I may have to add the system and package`s /lib to that if They start to appear.

Next I`ll have AppPkg-Build download the missing libs. that are left in the list.
The trick here is that the libs. (and all files) are in packages, so a package search.
I think I have a handle on that from a little web search page technosaurus gave me.

[sunburnt]

I have the AppPkg builder working basically, it has built several working packages.

However as both seaside and I have said, Linux apps. are messy at best.
Many are well made and follow standards, but many others are a disaster.
Some don`t have icons ( not a problem ), but others have no desktop files!
The builder reads the desktop files for app. info. to make the AppPkg.

It may need to repair the apps. as it goes, it already does this a little.
And that`s bull $#!+, if there`s much of a problem, why have a builder?
And that doesn`t even begin to touch libs. in odd places and similar crap.
If libs. can`t be found, the builder will just download another one, simple.

The builder can`t chase dozens of seldom encountered exceptions.
It would double ( at least...) the amount of code and reduce reliability.
Common exceptions should be dealt with, and they`ll become obvious.

Lots more testing and some code writing before it`s a beta release.
As I test build working AppPkgs I`ll post a group of them to try out.

[RSH]

Many are well made and follow standards, but many others are a disaster.
Some don`t have icons ( not a problem ), but others have no desktop files!
The builder reads the desktop files for app. info. to make the AppPkg.

That's exactly what I've complained on various occasions.

The LazY Puppy RunScript Builder also needs the .desktop files to grab the needed information from it.

But the Console-Freaks don't and even won't care about the .desktop files.

Some few moments I was downright angry and got hit for that. Meanwhile I have edited the .desktop files of around 280 .pet and/or sfs files to have a .desktop file, to get it in the menu, to get the icon, to get it run from the menu ---> often one finds a "%F" after the "Exec=" entry that blocks running a program from the menu. I can not tell, how often I had to remove such stuff etc.

This doesn't only make doubled and tripled work ---> every user does this work by himself and for himself alone.

What a waste of power and resources

RSH

[sunburnt]

RHS; And now we know why Linux will never surpass Windows...
Is it possible that Android will morph to the desktop also? It could work!

I`ve been thinking about an app. to repair Linux app. packages.
It`d fix desktop files and an editor, and an icon finder and editor-maker.

In fact I just gave AppPkg-Build a simple desktop file editor, text only.
Now just add an existing icon image editor app. ( Know any good ones? ).

From what you`ve said, the problem is worse than I thought ( or hoped ).
I`m using Ubuntu apps., so it appears even they don`t bother to fix them.
Their diff files must be what corrects the screwy apps.

Perhaps a web repository of fixed apps. and complete dep. files?
And a library file pool, no searching packages, just raw files to download.
Tons of icons grouped in dirs., no more searching web page to web page.
None of the twisted, upsidedown and backwards ways of doing things...

Fortunately not all apps. are relevant, only the good ones matter really.
A selection of good apps. for each group and app. type in that group.
Office, games, multimedia, internet, utilities, servers, etc. ( More? )

[RSH]

Now just add an existing icon image editor app. ( Know any good ones? ).

No, I've had made a request on that long time ago. People told me to use gimp. Sometimes I use IcoFX in Wine.

But this can only save .ico for Win and icons for Mac. So, I do not use it really often because I have to load the wine sfs and to use the gimp after that to save the .ico as .png. It's not a much comfortable solution, so, I'm still interested to have such a program ---> for linux.

A program to fix (really to fix) .desktop files would be really great.
Should have a feature to search the desktop files (not for them) and to inform the user if it finds a file that has something wrong or strange inside.
Should give then option to edit the .desktop file and continuing the job after that.

But there are also .desktop files which seem to include everything needed and do not appear in the menu. I've had this three or four times. These files had name, comment and genericname for almost all languages.

I am currently modifying my private LazY Puppy to have a category for buildingblock actually for .desktop files which contains categories not available in puppy (they are set automatically to buildingblock and will never be found) ---> I call it Unsortet.
Look also here!

A selection of good apps. for each group and app. type in that group.
Office, games, multimedia, internet, utilities, servers, etc. ( More? )

I would add Filesystem. Rox is cool especially for its right-click possibilities but its copy function is really ugly - if you have to copy a huge number of files into a directory containing earlier and therefor existing version of these files.

[sunburnt]

Hi RSH; File browsers, rxvt, etc. I consider to be utilities.

I was looking at gzine, it does have a desktop file... Hidden in it`s /share/gzine dir.!
And what`s more than that, the file`s named: gzine.desktop.in
It`s obvious that they are trying very hard to make it difficult to use.

It also has an /etc dir. in it. So in the setup script I added making a link to /etc/(dir.).

### I`m wondering if /var is important enough to need links in it also.