Page 1 of 12
Posted: Sun 29 Jan 2012, 00:34
by noryb009
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.
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.
Posted: Sun 29 Jan 2012, 02:40
by sunburnt
.
I have repeated many times... Stop making Pets and make SFS files instead.
There`s not nearly as many problems and the ones SFS`s do have are small.
But they must be built and labeled for the Puppy version they`re intended.
The SFS manager should ID the SFS files by this, so that way no problems.
I have tried sooo many pets that don`t work, that I won`t install them now.
SFS files don`t install, so nothing to remove, and they don`t use Save file.
A new install of Puppy, choose the Web Browser and it takes up Save space!
My vote... Just use SFS files for Puppy`s standard file package format.
.
Posted: Sun 29 Jan 2012, 08:28
by Lobster
Puppy is a pint-sized and very finicky OS. Trying to use packages from other repos is asking for trouble.
Sardines! [Lobsterian cussing]
Jemimah is right. However that is exactly what we are doing with Woof2
and BarryK is right too. Oh boy . . .
With P-ARM (Puppy on ARM)
http://puppylinux.org/wikka/PARM
the first thing that will be available is the devx.sfs
What will come next?
A Quickpet/Slickpet?
PPM?
or perhaps a wiki page of available software as used in Slacko?
http://puppylinux.org/wikka/SlackoNews
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
Puppy2012
You ain't seen nothing yet . . .
Posted: Sun 29 Jan 2012, 14:13
by noryb009
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.
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).
Posted: Sun 29 Jan 2012, 17:16
by jemimah
noryb009 wrote: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.
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.
Posted: Sun 29 Jan 2012, 19:34
by sunburnt
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!
Posted: Sun 29 Jan 2012, 21:20
by noryb009
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.
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.
Posted: Sun 29 Jan 2012, 23:10
by jemimah
noryb009 wrote: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.
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.
Posted: Mon 30 Jan 2012, 18:36
by sunburnt
They don't, but you need a save file to mount them - you can't mount them when on a live-cd
noryb009; The Save is only needed if the app. has config. files to be written to.
But this can easily be worked around. And there`s no reason a CD shouldn`t work.
To make "mount but no union" Squash files solves it also, and many other things.
jemimah; How about a GUI for .deb to SFS, it`d kinda solve all of this.
.
Posted: Mon 30 Jan 2012, 18:56
by Aitch
How about a GUI for .deb to SFS, it`d kinda solve all of this
PPM again....
Guy/gposil tried with Apt, but I think concluded it broke things
big_bass always said - use standard linux tools, and had great success with txz_pup
I never had a dependency/install/uninstall problem ......
This really does need bugsquashing !
Aitch
![Smile :)](./images/smilies/icon_smile.gif)
Posted: Mon 30 Jan 2012, 19:12
by sunburnt
Aitch; Yes Debian has a real off-handed way of doing things.
Such a shame as they have the best repository probably.
Perhaps there`s another repository that would be better to use?
Posted: Mon 30 Jan 2012, 20:10
by Aitch
Well, I dunno, but slackware has been good so far
.....and Arch seems to have the best package management/update process I've come across....
http://www.linuxforums.org/forum/applic ... itory.html
The missing ingredient from puppy's package management seems to be a database
http://en.wikipedia.org/wiki/Package_management_system
Has Fedora/Yum been tried, or gentoo/portage?
/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
Aitch
![Smile :)](./images/smilies/icon_smile.gif)
Posted: Mon 30 Jan 2012, 20:22
by gcmartin
jemimah wrote: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.
Posted: Mon 30 Jan 2012, 21:49
by jemimah
Aitch wrote:
/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
There's a link to the kernel source on the first post.
Posted: Mon 30 Jan 2012, 22:00
by jemimah
gcmartin wrote:
Looking forward to a src2pkg approach that perhaps you and Amigo can suggest.
Src2pkg will eventually make it's way into the saluki devx, just like it was in fluppy. It's just a matter of when I get around to it. Src2pkg produces regular pets - changing the ppm is not required.
Posted: Mon 30 Jan 2012, 22:25
by noryb009
noryb009; The Save is only needed if the app. has config. files to be written to.
But this can easily be worked around. And there`s no reason a CD shouldn`t work.
I know the save file isn't needed, but Puppy won't currently let you use SFS files while you don't have a save file. As you say, this can be implemented, though.
jemimah; How about a GUI for .deb to SFS, it`d kinda solve all of this.
...
Well, I dunno, but slackware has been good so far
.....and Arch seems to have the best package management/update process I've come across....
...
Has Fedora/Yum been tried, or gentoo/portage?
This is leading back to what we have now: a fragmented package management system taken from different distributions. We have tried it with ubuntu, debian, slackware, etc. With every new version, an entire old system is thrown away.
Puppy needs to stop using other package management systems, and start using it's own, compiled specially for puppy.
Posted: Mon 30 Jan 2012, 22:52
by Aitch
Has Fedora/Yum been tried, or gentoo/portage?
noryb009, that WAS tongue in cheek....
English humour, sorry....
I'm with Jemimah
The problem isn't the ppm, it's the repos.....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.
That seems simple enough...? - though I don't compile/develop.....
thanks devs!
Aitch
![Smile :)](./images/smilies/icon_smile.gif)
Posted: Mon 30 Jan 2012, 22:53
by scsijon
noryb009 wrote:This is leading back to what we have now: a fragmented package management system taken from different distributions. We have tried it with ubuntu, debian, slackware, etc. With every new version, an entire old system is thrown away.
Puppy needs to stop using other package management systems, and start using it's own, compiled specially for puppy.
No, what we need to do is either, do away with the whole built distribution idea and work directly from source as Iguleder is working on, then we would not have the problem; or create a multi-source distribution systems re-packager (and deal with that whole problems that would bring).
and
I don't have any problems with new2dir for building new pets, simple to use, try it with a build.
Posted: Tue 31 Jan 2012, 02:36
by harii4
big_bass always said - use standard linux tools, and had great success with txz_pup
I never had a dependency/install/uninstall problem ......
TXZ_pup only used slackware's pkgtools - so simple yet so powerful.
Big_Bass wanted to follow linux standards that way - he kept the puppy ppm for us noobs
Looking forward to a src2pkg approach that perhaps you and Amigo can suggest.
+1 for that
![Cool 8)](./images/smilies/icon_cool.gif)
Posted: Tue 31 Jan 2012, 03:16
by noryb009
No, what we need to do is either, do away with the whole built distribution idea and work directly from source as Iguleder is working on, then we would not have the problem; or create a multi-source distribution systems re-packager (and deal with that whole problems that would bring).
The entire point of this thread is to look at the possibility of the first part. We are currently using the second part through woof and the PPM, but it isn't working. As jemimah said:
jemimah wrote:If J. Random User picks some random package from the Ubuntu repo, downloads 300MB worth of deps overwriting system files in the process, what do you think is going to happen?
I don't have any problems with new2dir for building new pets, simple to use, try it with a build.
new2dir and dir2pet are good for quickly creating PET files, but they aren't good for recompiling a PET, as it doesn't save any settings, patches, etc. A script based packager would solve this.