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.

#21 Post 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!

noryb009
Posts: 634
Joined: Sat 20 Mar 2010, 22:28

#22 Post 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.

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#23 Post 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.

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

#24 Post 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.
.
Last edited by sunburnt on Mon 30 Jan 2012, 19:13, edited 1 time in total.

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

#25 Post 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 :)

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

#26 Post 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?

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

#27 Post by Aitch »

Well, I dunno, but slackware has been good so far :D
.....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? :lol: :lol:

/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 :)

gcmartin

#28 Post 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.

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#29 Post 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.

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#30 Post 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.

noryb009
Posts: 634
Joined: Sat 20 Mar 2010, 22:28

#31 Post 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.

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

#32 Post by Aitch »

Has Fedora/Yum been tried, or gentoo/portage?
noryb009, that WAS tongue in cheek.... :wink:

English humour, sorry.... :lol:

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

Aitch :)

scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

#33 Post 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.

User avatar
harii4
Posts: 448
Joined: Fri 30 Jan 2009, 04:08
Location: La Porte City, IA , U.S.A.
Contact:

#34 Post 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 8)
3.01 Fat Free / Fire Hydrant featherweight/ TXZ_pup / 431JP2012
----------------------------------------------------------------------------------------
Peace and Justice are two sides of the same coin.

noryb009
Posts: 634
Joined: Sat 20 Mar 2010, 22:28

#35 Post 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.

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

#36 Post by Aitch »

A script based packager would solve this.
If you build it, we'd no doubt use it...

Even if you made a start, it could be developed...whereas now, we just have real estate on a forum

Aitch :)

stu90

#37 Post by stu90 »

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.
As it stands now package selection for puppy is sparse at best and that is with source compiled, package conversion and dir2pet.
With the lack on man power and knowledge to do it (i include myself in that category) i would hazard a guess compiling everything specifically for puppy would cut down an already sparse package selection quite drastically.

Really though the state of package management is part of a wider question regarding the state or puppy as a whole - what is puppy, where is it going and along what path.

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#38 Post by jemimah »

My position is, if we do things right, and don't try to take shortcuts that decrease quality, pay more attention to look and feel, and have a coherent community structure, we're more likely to attract and keep developers.

We do have one problem that makes it difficult to have a community repo. How do we handle concurrent editing of the Packages file? The only way I can think of is to have one person manage the file and all the other maintainers need to talk to him/her to get packages added. It's not exactly ideal.

User avatar
sickgut
Posts: 1156
Joined: Tue 23 Mar 2010, 19:11
Location: Tasmania, Australia in the mountains.
Contact:

#39 Post by sickgut »

The only reason Puppy cant run other distros packages well is because of the extremely stripped down kernel. As soon as you try to install a package that relies on stuff that should really be in a linux kernel that puppy doesnt have then it wont work.

And the reason there is this sloppy "hey we can run ubuntu packages too!.."
functionality in the PPM that lets you try to install from Ubuntu or other repos (even if they dont actually work) , is because its an attempt to ease the pressure on devs who are overworked trying to compile and maintain a repo of current applications that work with the newest puppy. There is obviously a problem here, as its a huge workload to compile and keep current a puppy repo that is comprehensive enough that newbies dont have to move to other OSes to run their specific programs. The time spent on making packages for Puppy is wasted time as that time would be better spent on the OS itself.

The only clear answer as i have discovered is to start with a more compatible base. There is no point in trying to retro fit another OSes packages on top of Puppy.

it doesnt matter if you have fitted apt-get or synaptic or whatever to puppy, the package manager isnt the issue the issue is that the puppy base itself isnt compatible with the packages you will wish to install.

you can have the same speed/ size and other characteristics of puppy and the compatibility with other major distros repositories by starting with the smallest possible debian base (or ubuntu or slackware or whatever, i chose debian) then proceed to add everything you need, the same rox filer, jwm, xorg desktop and most the same applications as puppy and after manually slimming down you will have something the same size and with similar performance but also the ability to simply apt-get install <packagename> or use synaptic or whatever is the prefered method of the base you chose to install stuff.

If you want to supply slimmed packages? dont. Supply instead a script that apt-get installs what program you need, then removes all the unwanted junk files. Release a script instead of the package.

it is possible to make an OS in this way and also make it look and work in the same way (from the users point of view) as puppy. I have created pussy linux:

http://www.thepussycatforest.info

http://www.murga-linux.com/puppy/viewtopic.php?t=69475

Something like this can be made to seem to be more puppy like if there is a small group of puppy devs interested in doing so. This will solve the package management problems.

noryb009
Posts: 634
Joined: Sat 20 Mar 2010, 22:28

#40 Post by noryb009 »

If you build it, we'd no doubt use it...

Even if you made a start, it could be developed...whereas now, we just have real estate on a forum
Linky. It's a small script based on arch's makepkg. It makes PET packages right now, but it's designed to make another package format easily.
With the lack on man power and knowledge to do it (i include myself in that category) i would hazard a guess compiling everything specifically for puppy would cut down an already sparse package selection quite drastically.
It's not lack of man power and knowledge. We have many puppy devs, but they are all reinventing the wheel. It seems like everyone is working on a different puplet, not working together.
We do have one problem that makes it difficult to have a community repo. How do we handle concurrent editing of the Packages file? The only way I can think of is to have one person manage the file and all the other maintainers need to talk to him/her to get packages added. It's not exactly ideal.
A version control system like GIT would work great for a repository of scripts. It would allow there to be one copy of each script, and people can commit to that. There could be multiple maintainers, and it would record changes to scripts.

sickgut: Using another distribution as a base is one way to solve this problem, but this thread is about the other solution: using our own packages. Your project looks interesting, though. I'll have to try it out some time.

Post Reply