The State of Package Management

What features/apps/bugfixes needed in a future Puppy

Should Puppy's package format be changed?

Yes, without backwards compatibility.
11
28%
Yes, with backwards compatibility.
10
26%
No, but the PET format should be standardized/stricter.
8
21%
No, the PET format works fine.
10
26%
 
Total votes: 39

Message
Author
User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#181 Post by sunburnt »

amigo; A possible clarification to your post:
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.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#182 Post by amigo »

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 :D 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.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#183 Post by sunburnt »

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.

gcmartin

#184 Post by gcmartin »

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

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#185 Post by disciple »

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

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.
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#186 Post by amigo »

"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.

User avatar
Moose On The Loose
Posts: 965
Joined: Thu 24 Feb 2011, 14:54

#187 Post by Moose On The Loose »

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.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#188 Post by sunburnt »

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.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#189 Post by jpeps »

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.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#190 Post by sunburnt »

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!

User avatar
Moose On The Loose
Posts: 965
Joined: Thu 24 Feb 2011, 14:54

#191 Post by Moose On The Loose »

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.

Atle
Posts: 596
Joined: Wed 19 Nov 2008, 12:38
Location: Oslo, Norway
Contact:

#192 Post by Atle »

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

User avatar
Moose On The Loose
Posts: 965
Joined: Thu 24 Feb 2011, 14:54

#193 Post by Moose On The Loose »

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.

Atle
Posts: 596
Joined: Wed 19 Nov 2008, 12:38
Location: Oslo, Norway
Contact:

#194 Post by Atle »

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

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#195 Post by sunburnt »

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.
Last edited by sunburnt on Sun 11 Mar 2012, 19:48, edited 1 time in total.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#196 Post by jpeps »

sunburnt wrote: It has a nice set of dependency tree files that make it work well.
It doesn't work "well" at all. That's why they're presently considering a whole new system, which most likely won't help much.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#197 Post by sunburnt »

Well compared to Puppy`s method of dependency tracking. I think it`s left up to the package builder.
Since when don`t dependency tree files work well? Is there a better way to include all the files needed?
Well... There`s always static building of apps. I guess, but it isn`t a favored method for obvious reasons.

Tiny Core is a modified legacy setup, but that was the easiest way to make use of the existing packages.
To really fix Linux small changes or even bigger ones have proven insufficient. Real change is needed.
I`ll have to take a look and see if there`s an ongoing discussion about directions that Tiny Core might take.

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#198 Post by disciple »

To really fix Linux small changes or even bigger ones have proven insufficient.
Linux is broken? News to me...
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

anewuser
Posts: 93
Joined: Sun 05 Feb 2012, 20:00

edit (blank msg initially)

#199 Post by anewuser »

OT

Long interesting thread. Have any conclusions been made? And decisions from this thread will be made?

Currently end users have no way to tell if a pet will/would/could work on their puppies due to the vast ammount of versatility puppies provide (basically a toy to play with) and most likely yes, with modifications/upgrades or even regresions.

In order for a pet to work it's needing to be based off bary's branches without tweaks/modifications/tunning (almost the most basic set up) though when he upgrades key stuff on his setup, all pets depending on his upgrades break, as shown by posts/experience.

reference
http://bkhome.org/blog/?viewDetailed=02595
http://bkhome.org/blog/?viewDetailed=02594
http://bkhome.org/blog/?viewDetailed=02490
http://bkhome.org/blog/?viewDetailed=02456 (#2 gtk upgrade, key puppy component eg)
and so on...puppy isn't for the casual end users but for people willing to try their hand at fixing.

Key components of the system updated leads to broken/needing to upgrade apps/pets depending on those key components. Dependencies here and there (normal in any OS, not what's being discussed anyway [let's not get into that either]) but my point was that pets work if made with the main branches in mind, without tweaks or modifications, for the basic lines distributed (barry's).

..Now I get why he call his distros puppies...he's the top dog of the pack :D

if it were a team decision I'd change my "No, but the PET format should be standardized/stricter." to "Yes, without backwards compatibility." but's it's up to barry's actually as far as his puppies are concerned.

my two cents
Aaaaaaaaitch ty! (tags) :D
PS: I'd love to have this thread as a txt/htm/pdf or all the post in a single page view for offline reading. Great ideas in here.
Last edited by anewuser on Mon 12 Mar 2012, 21:27, edited 4 times in total.

User avatar
Aitch
Posts: 6518
Joined: Wed 04 Apr 2007, 15:57
Location: Chatham, Kent, UK

Re: edit (blank msg initially)

#200 Post by Aitch »

anewuser wrote:OT

Long interesting thread. Have any conclusions been made? And decisions from this thread will be made?

Currently end users have no way to tell if a pet will/would/could work on their pets due to the vast ammount of versatility puppies provide (basically a toy to play with) and most likely yes, with modifications/upgrades or even regresions.

In order for a pet to work it's needing to be based off bary's branches without tweaks/modifications/tunning (almost the most basic set up) though when he upgrades key stuff on his setup, all pets depending on his upgrades break, as shown by posts/experience.

reference
http://bkhome.org/blog/?viewDetailed=02595
http://bkhome.org/blog/?viewDetailed=02594
http://bkhome.org/blog/?viewDetailed=02490
http://bkhome.org/blog/?viewDetailed=02456 (#2 gtk upgrade, key puppy component eg)

Key components of the system updated leads to broken/needing to upgrade apps/pets depending on those key components. Dependencies here and there (normal in any OS, not what's being discussed anyway [let's not get into that either]) but my point was that pets work if made with the main branches in mind, without tweaks or modifications, for the basic lines distributed (barry's).

..Now I get why he call his distros puppies...he's the top dog of the pack :D
if it were a team decision I'd change my "No, but the PET format should be standardized/stricter." to "Yes, without backwards compatibility." but's it's up to barry's actually as far as his puppies are concerned.

my two cents
url tags sorted, caused blank post

Aitch :)

Post Reply