Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 20 Aug 2014, 06:43
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Suggestions
The State of Package Management
Moderators: Flash, Ian, JohnMurga
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 13 of 15 Posts_count   Goto page: Previous 1, 2, 3, ..., 11, 12, 13, 14, 15 Next

Should Puppy's package format be changed?
Yes, without backwards compatibility.
28%
 28%  [ 11 ]
Yes, with backwards compatibility.
25%
 25%  [ 10 ]
No, but the PET format should be standardized/stricter.
20%
 20%  [ 8 ]
No, the PET format works fine.
25%
 25%  [ 10 ]
Total_votes : 39

Author Message
sunburnt


Joined: 08 Jun 2005
Posts: 5016
Location: Arizona, U.S.A.

PostPosted: Tue 28 Feb 2012, 03:51    Post_subject:  

amigo; A possible clarification to your post:
Quote:
Libs should nearly always be put in the standard locations

I think you mean: " shared libs. ". If the lib. is rarely used, then why share it? Statically compile it and it`s conflicting with other libs. problem is solved.

I looked at ROXapps and didn`t see that they were any better than an SFS. I don`t know the structure of a AppDir, just the app.`s files all in a dir. I guess.
Obviously having all of an apps. files isolated has advantages. But shared libs. and a good O.S. API go a long way toward the reusable software model.
Back to top
View user's profile Send_private_message 
amigo

Joined: 02 Apr 2007
Posts: 2232

PostPosted: Tue 28 Feb 2012, 04:43    Post_subject:  

Q5sys, "curious about your thoughts" -Boy is something going wrong here... I thought I had commented on the /opt thread. I'll maybe waste some time there a little later...

sunburnt, of course I meant shared libs. The static/shared question has several aspects that should be taken inti account. Usually, when a library is very small, devs who want to use it in their application simply add it to their sources and include it statically, unless it is already a commonly-used and commonly-available shared library.

The problem comes with trying to judge how 'rarely' the libs might be used. Sometimes it is hard to tell, but sometimes it is obvious. Linking statically usually takes extra work, so I don't practice it much -I have so much nicer things to be doing with my time Very Happy If binary compatibility with other OS versions is the prime issue, then, of course, linking statically can be a great help. And, if you like compressing your binaries, then linking statically can help you achieve smaller bins. That sounds backwards, but the thing is that you can't really compress *shared* libs, while executable binaries you can. So, often a statically-linked binary can be compressed to a smaller size than having a dynamically-linked binary of a smaller size and then compressed, plus the size of the un-compressable shared library.

I think that usually trying to achieve really tiny binaries is a waste of time and ruins the general outcome when practised often. You either use limited versions of the program, hack out portions of a working program and remove things that you don't use -thinking that nobody else will want them either -often a wrong assumption. Then, you compress everything as much as possible -even when it is tiny to start with. Running compressed binaries is actually wasteful because it requires extra time to uncompress them and extra RAM in which to do that.

About AppDirs. The concept of software 'bundles' is old. Lots of early UNIX software was meant to be used from within a single directory -usually right fom inside the sources. Any shared data or config files would all be located in the same dir. As used by ROX, AppDirs become special by being executable directories -just click on them and they run. At the same time, you can cd into the dir and './AppRun' and get the same thing. Or, you can link the AppRun anywhere you like. All of this fits exactly with what /opt was designed for.

Interestingly, SFS's as used by Puppy and others, share a couple of aspects with AppDirs. They both contain everything under one dir. Even if you union the squashfs, the original mount of it is under one dir. And, they are both extensions of the idea of 'uninstalled' software which can be added or deleted dynamically.

Most of the 'original' AppDirs actually contain their uncompiled sources. 'Installing' them simply means un-packing the archive -basically anywhere you like or have rights to write and execute. Then, clicking on the AppDir compiles the sources and runs the program. Succeeding runs of course do not re-compile the app. Pretty slick actually, but it can get messy just like with uninstalled sfs files -or any other kind of FS-image. There is a project which lets you use a type of AppDir where the AppRun is actually a binary instead of a script and the other AppDir contents are an *.iso image. Running the app mounts the image. The same thing could be done with sfs's or any other FS image -ext2, iso or whatever.
Back to top
View user's profile Send_private_message 
sunburnt


Joined: 08 Jun 2005
Posts: 5016
Location: Arizona, U.S.A.

PostPosted: Tue 28 Feb 2012, 17:31    Post_subject:  

I think a ROXapp is also essentially what you`re describing. It has a script and a Squash file inside, I didn`t see it as an improvement over an SFS.

I hadn`t considered source code in a AppDir, for small apps. maybe okay, but big ones would be cumbersome and slow to run, but more portable...

Yes, a good statistical analysis of lib. common usage would be difficult to compile, but well worth the effort in organizing Linux package management.

I agree... Trying to compress anything to the Nth is pointless most of the time. It costs too much and storage space just isn`t that critical anymore.

I didn`t know that static compiling libs. was such a pain, maybe it could be improved somewhat? The real pain seems to be just getting the right lib.
Back to top
View user's profile Send_private_message 
gcmartin

Joined: 14 Oct 2005
Posts: 4211
Location: Earth

PostPosted: Tue 28 Feb 2012, 17:56    Post_subject:  

Here, here!
amigo wrote:
... I think that usually trying to achieve really tiny binaries is a waste of time and ruins the ...
Well spoken. Hope many are clear on what you accurately share.

Hope this helps

_________________
Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engine or use DogPile
Back to top
View user's profile Send_private_message 
disciple

Joined: 20 May 2006
Posts: 6427
Location: Auckland, New Zealand

PostPosted: Wed 29 Feb 2012, 04:22    Post_subject:  

Ooh - I'm surprised the static lib / tiny binary enthusiasts haven't turned up yet after that post Wink

On Roxapps and squashfiles: if you just chuck an AppRun (and a .DirIcon or whatever else you want) in the top level of a squashfile it would contain an AppDir. Just mount the squashfile and there you have it. If I wanted to use a bunch of non-unioned squashfiles, I think that's the way I'd go.

_________________
DEATH TO SPREADSHEETS
- - -
Classic Puppy quotes
- - -
Beware the demented serfers!
Back to top
View user's profile Send_private_message 
amigo

Joined: 02 Apr 2007
Posts: 2232

PostPosted: Wed 29 Feb 2012, 09:19    Post_subject:  

"static lib / tiny binary enthusiasts" They may be getting callouses on their ears by now...

Actually, you could also just throw an sfs inside an AppDir. Create an AppRun which mounts the thing or links it or whatever method you use to make it available -then just clicking the AppDir would do that. Of course I realize that some SFS's are handle at the system level, but for addons at least two different methods are being used by those who produce these things. Since nothing is done withem at the system level, putting them in an AppDir provides an easy way to something with them with just a click.
Back to top
View user's profile Send_private_message 
Moose On The Loose


Joined: 24 Feb 2011
Posts: 513

PostPosted: Wed 29 Feb 2012, 12:03    Post_subject:  

disciple wrote:
Moose On The Loose wrote:
Imagine the case where I have two wildly different computers. They require different drivers for the hardware and the screen's can't be set to the same resolution. If I want to be able to quickly move my work back and forth between these, I need to keep my work and all the settings separate.

Have you actually tried using the same USB stick Puppy install on both? I thought that it already handles this, by creating a separate xorg configuration for each.


I have a desktop machine with a whole collection of hardware in it. I also have an EEPC-701 with a really-really different collection of hardware. The same network drivers and settings can't be used between them. Quite a few things don't work if I copy a save file between them.

The /root/.wine/drive_C/temp needs to be a symbolic link to two different places.

The programs that I have written are in my-applications/bin and my-applications/lib. These need to be the same.

The desktop has the samba server installed and configured but the EEPC doesn't.

my-documents needs to be the same.

I guess I can do all this with a mess of symbolic links and a script that detects which machine and configures as needed but I was kind of hoping for something that took less manual work to set up.
Back to top
View user's profile Send_private_message 
sunburnt


Joined: 08 Jun 2005
Posts: 5016
Location: Arizona, U.S.A.

PostPosted: Wed 29 Feb 2012, 17:41    Post_subject:  

Moose On The Loose; Sounds like you`re looking to sync the two PCs.
I made a Puppy setup script for after the inevitable Save file corruption. Makes links of /root/my-documents, etc. to a Linux partition, and other things.

amigo; Yes, like a ROXapp, but I don`t see the point in a Squash file inside a dir.

disciple; Tiny binary... No. Static libs. if small and seldom used... Yes.
Your description is what I have working ( just a few apps. so far... ). I`m not much for compiling so I`ve tried to automate the AppSq build process.
It`s a Squash file with a very small "hook" run file and an icon in the root.
The hook run file`s about 20kB - 50kB in size so it has a small ram footprint. It runs the app., then upon exit runs the loader handler for Squash unmount.
I made a menu GUI listing all the Squash apps. found, click one and the loader mounts and runs it. So Squash apps. are only mounted when running.
Back to top
View user's profile Send_private_message 
jpeps

Joined: 31 May 2008
Posts: 3220

PostPosted: Mon 05 Mar 2012, 05:56    Post_subject:  

I've been having problems lately with squash apps....libs not being read even though they're listed as installed in a loop. Rebooting, ldconfig...sometimes nothing works other than reinstalling the package as a pet. That works. In one instance, I combined several packages and installed it. The files looked like they were installed when I ran tree on the loop, and yet I couldn't actually find them anywhere even in the loop. There weren't any whiteouts, either.
Back to top
View user's profile Send_private_message 
sunburnt


Joined: 08 Jun 2005
Posts: 5016
Location: Arizona, U.S.A.

PostPosted: Mon 05 Mar 2012, 16:04    Post_subject:  

jpeps; Almost sounds like what amigo`s been saying about Puppy and libs.

I assume that these were standard unioned SFS files you`re talking about, I`ve had an equal amount of trouble with .pet packages, I rarely use them.
In either case if the libs. were static it wouldn`t be a problem. Lib. conflicts...

Non-unioned Sqaush files ( or dirs.) isolate the files in them from the whole. Puppy`s union might cause the problem, but as you said it doesn`t seem so.
Shared libs. will always have this sort of problem, so secure and limit them!
Back to top
View user's profile Send_private_message 
Moose On The Loose


Joined: 24 Feb 2011
Posts: 513

PostPosted: Tue 06 Mar 2012, 12:01    Post_subject:  

sunburnt wrote:
Moose On The Loose; Sounds like you`re looking to sync the two PCs.
I made a Puppy setup script for after the inevitable Save file corruption. Makes links of /root/my-documents, etc. to a Linux partition, and other things.

amigo; Yes, like a ROXapp, but I don`t see the point in a Squash file inside a dir.

disciple; Tiny binary... No. Static libs. if small and seldom used... Yes.
Your description is what I have working ( just a few apps. so far... ). I`m not much for compiling so I`ve tried to automate the AppSq build process.
It`s a Squash file with a very small "hook" run file and an icon in the root.
The hook run file`s about 20kB - 50kB in size so it has a small ram footprint. It runs the app., then upon exit runs the loader handler for Squash unmount.
I made a menu GUI listing all the Squash apps. found, click one and the loader mounts and runs it. So Squash apps. are only mounted when running.


I only sort of need to sync. I can carry the same USB hard drive between the machines in question. It is just that I want to have an easy way to have them both work. I think that for now, two save files and lots of symbolic links is the way to go. I can have the USB drive have two partitions. One can be FAT32 and the other EXT4. The EXT4 will allow me to have symbolic links and the like that don't work within a fat32 system.
Back to top
View user's profile Send_private_message 
Atle

Joined: 19 Nov 2008
Posts: 283
Location: Oslo, Norway

PostPosted: Sat 10 Mar 2012, 09:19    Post_subject:  

I see that there is slightly more votes for a non backwards compatible package system...

What if one could simply adapt another standard that exists?

My MAJOR thought is that using "foreign" repo, from more complex distro's, also makes more complex implementation into Puppy, makes less sense than using a repo from a less complex distro...

That points to to places... Slitaz and Tiny Core...

Given I am right, its more likely that a package system, lets say for Puppy 6, built around their standard and repo, would actually make it fun to use it.

If I stick to my own favorite here, the Slitaz repo with a friendly community and more than 3000 packages in their repo, I think it could be a win win situation.

Assuming that one does that, there is already more than 3000 packages ready to use and if one like to make a package, it might benefit both Distro's.

Also... Slitaz you can deal with. There is no way I think that Ubuntu or Slackware would do ANY changes in their repo, to make it more Puppy friendly.

I think if those two brilliant gangs from Slitaz community and the kennel gang her, was to do something, it smells like a big win win to me...

I hope, even if I can not make a simple "symlink" that the logic's behind having a repo from a LESS complex distro, would be like less is more and that is more easy to foresee that ALL packages will work and not some here and there, that is the case with the Puppy's built on larger distro repo.

Speaking for my self, I have virtually given up to use the Ubuntu repo for Lupu and the Slackware repo for Slacko.. Why? To much that does not work and I feel that what does not work, is messing up my Puppy.

I only stick to .pet and .sfs and if I remaster, I might even remove the package manager, and rather create a copy of the repo, and pointing the webbrowser to it. I feel shy to suggest Puppy XXXX and they want a package from a Ubuntu or Slackware repo, and its complex to install and does not work. ITs not fun and its not the future.

That said, both Playdayz and 01Micko have done and are doing a GREAT job. Also all the other contributors.

So the basic idea is to use packages from a foreign repo, whereas the distro is LESS complex than Puppy and not MORE, as seems to be today*s idea...

I hold my breath and await some verbal technical beating here now:-)

More from me on this issue here and here
Back to top
View user's profile Send_private_message Visit_website MSNM 
Moose On The Loose


Joined: 24 Feb 2011
Posts: 513

PostPosted: Sat 10 Mar 2012, 13:32    Post_subject:  

Atle wrote:
I see that there is slightly more votes for a non backwards compatible package system...


I see it the other way around. The majority seems to want either to stay with the current system or to be compatible with that system. A significant minority wants to go with something else even if it is not compatible.

I think that not going to some more complex system in one leap may be the best answer. Migrating to a new system but keeping the compatibility until such time as there are not longer any programs that can only be had in the *.pet format, seems the least likely to leave people behind.
Back to top
View user's profile Send_private_message 
Atle

Joined: 19 Nov 2008
Posts: 283
Location: Oslo, Norway

PostPosted: Sat 10 Mar 2012, 15:08    Post_subject:  

Yes... One can even say as yes please, I take both...

I mean... If I am not wrong, making a .pet, does not mean its for Puppy Linux... Its means its for this and that Puppy Linux...

So by entering a new era, ones need to unite at one standard...

And if that standard was to be something that takes Puppy away from this dependency issue, and built on ONE foreign repo, Its my guess that a smaller distro like Slitaz or Tiny Core is better than Debian, Ubuntu or Slackware, that are BIG distro with all kind off stuff under the hood already... Slitaz and TinyCore are small ones...

Anyone like to test the Slitaz rolling release (lastest of the lastest),

you can add this to your menu.lst and boot straight into it.

# Full installed Linux

title Slitaz Live
kernel (hd0,3)/boot/bzImage rw root=/dev/null vga=normal autologin
initrd (hd0,3)/boot/rootfs.gz

(this is for those that knows what they are doing(unlike me)

A HOWTO on booting Slitaz Rolling Release is HERE
Back to top
View user's profile Send_private_message Visit_website MSNM 
sunburnt


Joined: 08 Jun 2005
Posts: 5016
Location: Arizona, U.S.A.

PostPosted: Sun 11 Mar 2012, 14:47    Post_subject:  

Tiny Core`s package setup is quite unique and rather non-compatible.
It uses Squash files of individual app. and lib. packages of files.
It has a nice set of dependency tree files that make it work well.

Only way to use them would be to mount the Squash files and copy them.
This would take up space in the Save file like a .pet package does ( Ugh...).
And I think Tiny Core and Puppy are just too different for it to work anyway.

Edited_time_total
Back to top
View user's profile Send_private_message 
Display_posts:   Sort by:   
Page 13 of 15 Posts_count   Goto page: Previous 1, 2, 3, ..., 11, 12, 13, 14, 15 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » Taking the Puppy out for a walk » Suggestions
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1195s ][ Queries: 15 (0.0149s) ][ GZIP on ]