(OLD) (ARCHIVED) Puppy Linux Discussion Forum

[2byte]

I knew before posting the idea would be rejected out of hand. Amigo is 100% right, although I don’t understand the point of that snide remark in the last sentence.

Jemimah
It might cripple the functionality of the installed software but it would prevent the base system from being crippled by a poorly packaged pet. I am talking about user installed software, not system upgrades. Those things you say we already have, yep. The idea doesn’t do away with those as you pointed out. As for foreign packages, I was referring to installing without fear of overwriting critical system files. Damage from running foreign software is unpreventable.

As long as the PPM blindly installs everything in a pet and blindly executes any pinstall script and then blindly removes every file that was in the pet people are going to continue to fubar their system.

If the Puppy package management isn’t broken, then don’t fix it.

No hard feelings

[jemimah]

If you want to prevent overwriting system files, by far the easiest and most effective way is to mount the save file below the main sfs - as we discovered in a saluki-008 bug.

Perhaps it is better to have the user confirm system file overwrite.

It is important to understand that good package management (in the style of other distros) and read-only filesystems can be rather at odds with each other.

If you want apt-style package management, the only option is the one Sickgut concluded with - you must design the entire distro around it. You must discard Puppy entirely and start over. Anything less is doomed to failure.

[2byte]

Well I'll just say this, then butt out. I have been using this sort of thing as my own package control system since Lucid was first released and it has performed very well.

Best regards to all

[darkcity]

Hi 2byte

It is possible you could upload your system to the forum so other could test it?

[Lobster]

If Sqlite is too complex a flatfile database that creates a text file
is available as a base
http://puppylinux.info/topic/p-data-alpha-flat-file-database

[sunburnt]

amigo; I myself don`t assume SFS and non-union Squash files are new.
However they don`t seem to be used much even though they have many
important improvements over the classic legacy .tar.gz type package.

Tiny Core Linux uses them very effectively, but a little oddly in my opinion.
But the manner of usage is consistent with the way the packages are setup.

To statically compile app. Squash packages by the Linux distro. it`s to be
used on would seem to be in line with what amigo is suggesting.
Static compiling solves nearly all shared library mismatches that might occur.

[amigo]

The problem with statically-linking everything is that you wind up shipping duplicates of libs and making each app much larger than necessary -unless you use binary compression which means each app winds up needing more RAM and cycles than necessary...

Anyway, simply following the natural arrangement of things, developers usually write software in a compartmented way. Just because you are trying to get a certain 'capability' working, doesn't mean you should deliver it as a single-file or single-stop-solution.

From a devs standpoint, it's much easier to maintain, bugfix or add features using a modular approach -despite the use of git, etc. Those guys are still thinking along the lines of 'stable' and experimental code, with stable being for the public consumption and experimental for the devs.

The matter of staying compatible for a useful amount of time also comes into play. If your desired program depends on somebody elses lib, then it makes sense for you to release your code where it is working against a 'release' version of those libs.

[sunburnt]

amigo; Exactly!!!

[jpeps]

[sunburnt]

jpeps; Agreed, adding to the the Devx file may not be the best choice.
Splitting libs. to a few SFS files by usage may be the best approach.
A separate media libs. SFS file, as media is probably the biggest group.

The idea being... Libs. built by Puppy devs. for the main Puppy releases.
Then most of the Puppy variants should have no problems with the libs.
These extra lib. SFS files would make .sfs / .pet package building a snap.

And they would increase the chance of random app. binary files working.
I think some times a Debian app. binary would work, but the Debian lib. fails.

[jpeps]

[scsijon]

If you want a new Package Manager it needs to be able to handle the current format else there will be problems. However there is no reason why it should not have two sections, one that handles the current format and another the new format, but the new format would be need to be flexable enough to be changed/extended, rather than replaced in the future else people will grumble and eventually go elsewhere with complaints like 'it's too hard to add apps'.

What will need doing though if it is to suceed, is either creating a repointing table for those many faithfull old apps that will remain as is, to deal with the extra and changes in structure, ir an orderly update/repackage with only the pet.specs (and maybe the packagename changed to the new format with a ref to show it's part of an old series).

I looked at OpenSuSE's packaging, as I was considering adding OpenSuSE to our available base sets and build a OpenSuSE based Puppy.

In their case they set their dependancies quite differently to most others. Dependancies can be both Packages or/and individual files, including versions.

They also use the xlm format {xlm format url missing}, which is quite an eye-opener on what can be included and what can be in it.

For example, for the opensuse package ConsoleKit-0.4.5-6.2.2.i586.rpm, (in xlm format) the pet.specs is:

[2byte]

There is a lot of discussion about the current ppm. What I would like to know;
Is there anyone willing to band together and create a brand new ppm?
If we did create one, would it be incorporated into Woof-X? What criteria would it have to meet to become 'official'?
Barry, are you willing to comment about this?

[jpeps]

[sunburnt]

Doesn`t anyone see the value of not using loose files in an O.S.?
Squash files can`t get viruses ( I believe...), and don`t corrupt easily.
SFS files require almost no package management, only config. files.
They stay compressed, load to ram, and can be swapped on-the-fly.
And they can be mounted from anywhere, hd, ram, usb, lan, and web.

One of Puppy`s big strengths is it`s main SFS file holding most of the O.S.
And the devx file ( "DEVeloper eXtra", I think...) is it`s second best setup.

I suggest a few more SFS file extentions like medx ( "MEDia eXtra" ).
Having more "shared" libs. available in SFS form is a real good idea.

Have enough extra SFS lib. files covering most of the common libs.
Odd libs. are always needed, so static compile them into the apps.
An app. package builder should check shared libs. and list needed libs.