Puppy is a pint-sized and very finicky OS. Trying to use packages from other repos is asking for trouble.

I completely agree. The only reason why Puppy uses other repos is because we can't organize a package system of our own that works.

Quote:

The only way any of this works at all is if puppy developers compile and test the packages, and specify the dependencies correctly, and if the users stick to installing stuff from the tested repositories only.

Like you say, the PET format works in theory, but it is bad in reality. We could change the way things are packaged, but the backwards compatibility requirement would cause packages to not hold architecture info, have XZ (or similar) compression and wouldn't allow packages to be named depending on what it is (firefox from git should be called "firefox-git", but it wouldn't be seen if a package needs "firefox"). A new package format would give packagers a new start with a modern package specification.

My inclination is to have a firefox.ap (as an example)
conservative format

What would .ap be?
Basically a pet compiled on ARM (Arm Pet) with Puppy
that could be used in the PPM.

What would be the difference?
The name change moves us into the world of apps
(which is very easy for end users)
More efficient compression would be possible
Would the .ap be similar to an SFS (contain any dependencies and therefore be safe to remove)?
. . . up to developers

I have repeated many times... Stop making Pets and make SFS files instead.

SFS files do have many advantages over other package formats, including not having to decompress them and including dependencies.

Quote:

There`s not nearly as many problems and the ones SFS do have are small.

However, SFS files do have problems. These include having to have a save file to install them (maybe not anymore, there at least 1 project trying to fix this), you can't uninstall them in a full install, and having a limited number that you can install.
The biggest problem is the limited number you can install. People have tried to avoid this in the past by creating theme SFSes, like graphics and multimedia. This lowers the amount of SFSes you need for your needed programs, but gives you a lot of unneeded programs.

I think SFS files could be useful if we allow users to make their own. This allows users to include what they want (without extra programs that they will never use), and makes it for their puppy version (which can be hard to find online).

Puppy is a pint-sized and very finicky OS. Trying to use packages from other repos is asking for trouble.

I completely agree. The only reason why Puppy uses other repos is because we can't organize a package system of our own that works.

Quote:

The only way any of this works at all is if puppy developers compile and test the packages, and specify the dependencies correctly, and if the users stick to installing stuff from the tested repositories only.

Like you say, the PET format works in theory, but it is bad in reality. We could change the way things are packaged, but the backwards compatibility requirement would cause packages to not hold architecture info, have XZ (or similar) compression and wouldn't allow packages to be named depending on what it is (firefox from git should be called "firefox-git", but it wouldn't be seen if a package needs "firefox"). A new package format would give packagers a new start with a modern package specification.

The developers that work on Puppy are here because we find simplicity attractive. Puppy is, in every aspect, 'the simplest thing that could possibly work.' Developers who like systems that are complex and robust have sensibly moved on to support "real" distros. The ones who love the beauty of simplicity remain.

When you dig a little, nearly every single feature of puppy is too simplistic to be reliable enough, flexible enough, or secure enough for all but the most basic use cases. That simplicity is Puppy's only endearing feature. Complicate it, and you just have another yet another sucky os that doesn't stand out.

The problem isn't the pet format (though xz could probably be added by changing only like 3 lines of code). The problem is, as you say, that "we can't organize". You can count the number of active puppy developers on two hands, and the ones who are real artists with a compiler can probably be counted on one. Brains cannot be replaced with code.

What we have now with woof is the best it gets if you attempt to automate away the developers job. Complicating it, will only steepen the learning curve. Increase the workload of the existing devs, and less will get done, not more.

I've attempted to design Saluki in such a way that it facilitates developer cooperation as much as possible. When it's ready, I will open up the repo to multiple maintainers and hopefully we can maintain a high standard of quality for packages. I do believe this is the only practical way forward.

noryb009; No... SFS files do not take up Save space.
And... SFS files have been used "unioned" in full installs.
And... There is no limit to the number of unions aufs can do.
It`s Puppy`s SFS manager made by Barry I believe that limits the number.

Making Squash files that work non-unioned is the best solution...

jemimah; Compared to what can be done, Puppy is actually quite complex.
You`re right in that lot of Puppy`s systems and utilities are rather shallow.

.tar.gz is the "near" original package format... Time to change the concept?

It takes Barry to make any "real" changes, that slows things down considerably.

I`ve seen a lot of good ideas come and go in my 5 years here at Puppy...
But continuing to use the basic .tar.gz format for packages is not good!

Complicating it, will only steepen the learning curve. Increase the workload of the existing devs, and less will get done, not more.

Making a new package standard won't complicate things, it would define how things should be.
PET files are hard to make, as you have to include needed dependencies to allow at least one puplet to use it, but not enough to create a conflict and break something else. The alternative is to define which dependencies are needed, but petget doesn't try to find the dependencies unless the package is from a repository (I think).

A script based packager will save the most time, allowing a lot of other stuff to get done. It would allow packagers to compile new versions while preserving patches and hacks, and allow puplet developers to make packages for their puplet faster and easier.

Quote:

No... SFS files do not take up Save space.

They don't, but you need a save file to mount them - you can't mount them when on a live-cd (without manually mounting it and copying the files).

I now see the benefit of mounting SFS files over extracting packages, as you only have 1 copy of each program, which is compressed, and doesn't raise the size of the save file. However, it would need a lot of work if it would be the only package format for Puppy.

Complicating it, will only steepen the learning curve. Increase the workload of the existing devs, and less will get done, not more.

Making a new package standard won't complicate things, it would define how things should be.
PET files are hard to make, as you have to include needed dependencies to allow at least one puplet to use it, but not enough to create a conflict and break something else. The alternative is to define which dependencies are needed, but petget doesn't try to find the dependencies unless the package is from a repository (I think).

A script based packager will save the most time, allowing a lot of other stuff to get done. It would allow packagers to compile new versions while preserving patches and hacks, and allow puplet developers to make packages for their puplet faster and easier.

Quote:

No... SFS files do not take up Save space.

They don't, but you need a save file to mount them - you can't mount them when on a live-cd (without manually mounting it and copying the files).

I now see the benefit of mounting SFS files over extracting packages, as you only have 1 copy of each program, which is compressed, and doesn't raise the size of the save file. However, it would need a lot of work if it would be the only package format for Puppy.

We already have an excellent script-based packager - Amigo's src2pkg. The reason nobody uses it: Learning Curve. It takes 10 times longer to figure out why the build system is borking things up than just running dir2pet. Hacking up a customized version of src2pkg has been on my todo list for years...

Figuring out what the dependencies are is not the hard part of packaging. When you have a problem is when the packager does not know how to compile, and throws together bins from random sources or the packager doesn't understand which parts of Puppy can be upgraded and which cannot without breakage. There's no script on earth that can turn a n00b into a dev - only practice.

/aside
jemimah, can I ask for kernel headers.sfs and or kernel source to be made available for saluki - people are still having compile problems occasionally, and these were omitted from both Lupu and Slacko, AFAIK

We already have an excellent script-based packager - Amigo's src2pkg. The reason nobody uses it: Learning Curve. It takes 10 times longer to figure out why the build system is borking things up than just running dir2pet. Hacking up a customized version of src2pkg has been on my todo list for years...

Figuring out what the dependencies are is not the hard part of packaging. When you have a problem is when the packager does not know how to compile, and throws together bins from random sources or the packager doesn't understand which parts of Puppy can be upgraded and which cannot without breakage. There's no script on earth that can turn a n00b into a dev - only practice.

I, for one, am looking forward to what you can provide in this area.

Looking forward to a src2pkg approach that perhaps you and Amigo can suggest.

Thanks in advance._________________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 Enginesor use DogPile

/aside
jemimah, can I ask for kernel headers.sfs and or kernel source to be made available for saluki - people are still having compile problems occasionally, and these were omitted from both Lupu and Slacko, AFAIK

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum