Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 21 Oct 2014, 01:51
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Suggestions
The State of Package Management
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 15 [222 Posts]   Goto page: Previous 1, 2, 3, 4, ..., 13, 14, 15 Next

Should Puppy's package format be changed?
Yes, without backwards compatibility.
28%
 28%  [ 11 ]
Yes, with backwards compatibility.
25%
 25%  [ 10 ]
No, but the PET format should be standardized/stricter.
20%
 20%  [ 8 ]
No, the PET format works fine.
25%
 25%  [ 10 ]
Total Votes : 39

Author Message
noryb009

Joined: 20 Mar 2010
Posts: 539

PostPosted: Sat 28 Jan 2012, 20:34    Post subject:  

Quote:
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.
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Sat 28 Jan 2012, 22:40    Post subject:  

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

Last edited by sunburnt on Sun 29 Jan 2012, 15:21; edited 1 time in total
Back to top
View user's profile Send private message 
Lobster
Official Crustacean


Joined: 04 May 2005
Posts: 15117
Location: Paradox Realm

PostPosted: Sun 29 Jan 2012, 04:28    Post subject:  

Quote:
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 . . . Confused

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 Smile

Puppy2012
You ain't seen nothing yet . . .

_________________
Puppy WIKI

Last edited by Lobster on Sun 29 Jan 2012, 10:25; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
noryb009

Joined: 20 Mar 2010
Posts: 539

PostPosted: Sun 29 Jan 2012, 10:13    Post subject:  

Quote:
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).
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Sun 29 Jan 2012, 13:16    Post subject:  

noryb009 wrote:
Quote:
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.
Back to top
View user's profile Send private message Visit poster's website 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Sun 29 Jan 2012, 15:34    Post subject:  

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!
Back to top
View user's profile Send private message 
noryb009

Joined: 20 Mar 2010
Posts: 539

PostPosted: Sun 29 Jan 2012, 17:20    Post subject:  

Quote:
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.
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Sun 29 Jan 2012, 19:10    Post subject:  

noryb009 wrote:
Quote:
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.
Back to top
View user's profile Send private message Visit poster's website 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Mon 30 Jan 2012, 14:36    Post subject:  

Quote:
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, 15:13; edited 1 time in total
Back to top
View user's profile Send private message 
Aitch


Joined: 04 Apr 2007
Posts: 6825
Location: Chatham, Kent, UK

PostPosted: Mon 30 Jan 2012, 14:56    Post subject:  

Quote:
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
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Mon 30 Jan 2012, 15:12    Post subject:  

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?
Back to top
View user's profile Send private message 
Aitch


Joined: 04 Apr 2007
Posts: 6825
Location: Chatham, Kent, UK

PostPosted: Mon 30 Jan 2012, 16:10    Post subject:  

Well, I dunno, but slackware has been good so far Very Happy
.....and Arch seems to have the best package management/update process I've come across....

http://www.linuxforums.org/forum/applications/172247-there-best-repository.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? Laughing Laughing

/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
Back to top
View user's profile Send private message 
gcmartin

Joined: 14 Oct 2005
Posts: 4354
Location: Earth

PostPosted: Mon 30 Jan 2012, 16:22    Post subject:  

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.

_________________
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 Engine or use DogPile
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Mon 30 Jan 2012, 17:49    Post subject:  

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.
Back to top
View user's profile Send private message Visit poster's website 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Mon 30 Jan 2012, 18:00    Post subject:  

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.
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 2 of 15 [222 Posts]   Goto page: Previous 1, 2, 3, 4, ..., 13, 14, 15 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Suggestions
Jump to:  

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


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1152s ][ Queries: 15 (0.0066s) ][ GZIP on ]