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 Sat 30 Aug 2014, 08:48
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 6 of 15 [222 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, ..., 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
sunburnt


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

PostPosted: Sat 11 Feb 2012, 23:29    Post subject:  

01micko; I made a similar utility years back.
It could make dependency tree files that would solve a lot of problems.

It`s not just the needed library, but the exact library that`s needed.
As amigo points out, change critical stuff and you need to redo everything.

# Gentoo Linux builds everything on the spot if I understand correctly.
This solves problems, but eventually you`d probably need to redo it also.
Back to top
View user's profile Send private message 
jpeps

Joined: 31 May 2008
Posts: 3220

PostPosted: Sun 12 Feb 2012, 12:52    Post subject:  

sunburnt wrote:

It`s not just the needed library, but the exact library that`s needed.
As amigo points out, change critical stuff and you need to redo everything.


True, and the app isn't going to run if a dep is altered after it's loaded either. So why go through the hassle of moving to self-contained packages or some other cumbersome process? A good repository of libs would be a plus though (although they're generally fairly easy to find).
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2236

PostPosted: Sun 12 Feb 2012, 13:07    Post subject:  

A central 'dump' of loose files is not very helpful -more often than not you are going to actually need more than one file -for example a 'real' library and the link that points to it. Most dependencies are really gonna need several files to work. A central repo of loose files is absolutely no help to the developer who tries to maintain it either. You need a way to have a system of grouping related things together.
That's why a list of *everything* is also useless -it remains a nightmare for users and for devs. Also, individual filenames don't always tell you anything about the version of that file, and they certainly don't give you any info about compile-options, etc.
No order is always gonna equal chaos.
Back to top
View user's profile Send private message 
sunburnt


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

PostPosted: Sun 12 Feb 2012, 13:59    Post subject:  

# Q:
But if a sfs of common libraries not in Puppy were built for each standard Puppy type,
and then Puppy`s apps. built upon them, they should be reliable and well constructed?

It`s short lived of course, as soon as a Barry makes a new Puppy, a new lib.
But this seems to be the best method of providing a solid base for Puppy?

As I said, I think media would be a big part of the needed libs. ( but not only )
I`ve tried gstreamer apps. with little success. And ffmpeg is a real pain!

Thinking in retrospect, my success with binaries has been with simple apps.
My attempts at media with binary and source files has been mostly failures.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2236

PostPosted: Sun 12 Feb 2012, 14:48    Post subject:  

The best way to have a solid base is to deal with workable units in an orderly way -just what I've been saying all along. Each source triggers a new unit of installable material. They must be compiled in a certain order so that everything works as expected. In order to know which unit a certain dependency belongs to, you need to account for each file.

Creating and using sfs's or other mountable file-system images is fine, for what it is. But, the only rational way to construct them is by using individual packages -you install them into a subdir then make your sfs out of that. That would at least eliminate some of the disorderiness. But having a single sfs install the material from what is really several units starts causing problems of duplication. And what about this:
1. you create an sfs which includes a certain version of a lib.
2. I want to create an sfs which includes a later version of the same lib, or the same version, but compiled with different options included.

How do propose to resolve the conflict? If your sfs gets 'loaded' before mine, then my prog is gonna try to use your libs and will fail. Handling duplicate libs or separate versions of the same lib can be done of course, but involves other tricks besides simply relying on a certain load order.

If you were to create sfs's of each unit needed by the program you want to work, then it would be exactly the same problem as handling 'packages'. You'd still need a way to reolve the dependencies logically and orderly.

Why not simply 'install' packages on-the-fly? Some LiveCD systems used to handle it that way? Well, that's where your sfs's have an advantage because they don't need to use any RAM since they are simply mounted. The problem of which sfs's are needed and in what order they must be loaded remains though. Lists of files included in each 'unit', unit names which include both 'version' and 'build' information -plus architecture info if you are to ever have more than one arch supported. Units are most easily divided along the lines they come as -individual sources. Anything else is a mess.

Why can't you do a real upgrade of Puppy? Simply because the above has not been done. Why can't you easily remove a program or library that you don't need or want? Because the above has not been done. Why can't you 'replace' one program or lib with another which has superceded it? Because the above has not been done.
Back to top
View user's profile Send private message 
jpeps

Joined: 31 May 2008
Posts: 3220

PostPosted: Sun 12 Feb 2012, 15:32    Post subject:  

amigo wrote:


Why can't you do a real upgrade of Puppy? Simply because the above has not been done. Why can't you easily remove a program or library that you don't need or want? Because the above has not been done. Why can't you 'replace' one program or lib with another which has superceded it? Because the above has not been done.


Well, all the above is easily done, but rarely needed. I once wrote a script experimenting with a modular approach that created an "extra.sfs" package that I could transfer files in and out of. Outside of the learning experience, it was generally a waste of time.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2236

PostPosted: Sun 12 Feb 2012, 17:14    Post subject:  

I think not easily done on Puppy. Upgrading is not simply a matter of installing a new version over the old one. Maybe the new package contains different files -what happens to the old ones? -they are orphaned and you have no way of telling whether they belong to a package or not.
Waste of time? I think you had a glimpse of just how much work is needed to create a bit of sanity for your system Will the script you made work on any other version of puppy? I'll bet not, because the needed flexibility and fine-grained control are probably not in there -but that wouldn't be your fault -the base is disorderly so it would be impossible to add some order where none was intended.
Back to top
View user's profile Send private message 
jpeps

Joined: 31 May 2008
Posts: 3220

PostPosted: Sun 12 Feb 2012, 17:46    Post subject:  

I just scripted a kind of remaster-on-the-fly after separating out selected apps into an sfs module....but in the end...so what?
Back to top
View user's profile Send private message 
sunburnt


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

PostPosted: Mon 13 Feb 2012, 04:53    Post subject:  

File duplication conflicts occur because of the Unix legacy file system.
Static compiling solves conflicts for the included files.

But apps. don`t have to be legacy installed.
If apps. are loose files in a dir. or non-unioned image files they won`t
conflict because they don`t share any part of the file system tree.
Simple apps. do this well, complex ones not so much ( browsers & media ).
But Puppy already has problems with it`s browsers and media apps.

The idea... A sizable base of common shared libraries ( stripped Puppy? ).
Other not so common libs. and the small libs. are compiled into the apps.

Trouble begins when you want an app. that uses a different shared lib.
Now the problem starts all over again... Change it and other stuff breaks.
So perhaps the apps. and their libs. go as a set working group.?
This is a near impossibility of course as apps. cross use different libs.

# This makes an argument for static compiled apps., and damn the size.
Static to the point of the real core libs. of course. Linux, C, GTK, etc...
Where to draw the line is a tough decision... The smaller the better.
Back to top
View user's profile Send private message 
jpeps

Joined: 31 May 2008
Posts: 3220

PostPosted: Mon 13 Feb 2012, 12:04    Post subject:  

sunburnt wrote:


# This makes an argument for static compiled apps., and damn the size.
Static to the point of the real core libs. of course. Linux, C, GTK, etc...
Where to draw the line is a tough decision... The smaller the better.


well..for Puppy linux size matters. You spoke of mplayer...well, I just compiled one for exprimo. A static copy wouldn't have helped at all..it didn't work with my cpu, so needed to be compiled on my machine. The resulting binary is two files. ldd lists 54 libs. You want to include them in the package?
(and of course, we'll need to include ffmeg and deps in there as well Smile )

The other issue of course is that unless you're doing constant remasters as described above, there's the issue of all the already existing duplicates. With the existing system, you can run something like PetCheck and simply build a small pet that doesn't duplicate anything. If you're not convinced, the other bonus is that the OS won't fail to boot if there's some dependency issue or typo (like it would in TC).
Back to top
View user's profile Send private message 
sunburnt


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

PostPosted: Mon 13 Feb 2012, 15:54    Post subject:  

jpeps; I`ve noticed what you`re saying about TC.
Loose files and the union fs cause the remaster problem. Conflicting libs. Right?
That`s why I suggested a stripped Puppy with sfs lib. extras, easier to maintain.

Having a given lib. installed can only support the apps. that use it. Correct?
So multiple libs. are needed to support other apps. But how to separate?
If app`s. files and odd libs. are in a dir. or no-union sfs file, they`re separate.
Realistically there has to be some shared libs. Which ones? Statistics...

A media sfs with most libs., ffmpeg, codecs, and some common apps.
Smaller than Puppy`s sfs so easier to remaster. Auto built by the PC.?
Again, small apps. seem to work well, media is a real pain. A good fix?

And yes... My next focus was to be architecture.
Q: How many architectures are common? 386, i64, amd64 ( Is that about it? )
I assume i64 and amd64 are not interchangeable. How about Atom and VIA?

Build browsers and media apps. on the PC, this solves many problems.?
If they`re not part of the legacy fs, then conflicts can be fixed easier?
.
Back to top
View user's profile Send private message 
noryb009

Joined: 20 Mar 2010
Posts: 539

PostPosted: Mon 13 Feb 2012, 18:47    Post subject:  

I've finished my PPkg program (formally makepuppypkg), and I have created a separate thread for it.

sunburnt: I don't think an lib SFS would fix things - it would just add unneeded libraries to a puppy, making it bigger. It also means that a specification needs to be created (which would include a lot of arguing of size vs. if a library is needed aka. it would never be done), or each puplet would create it's own (which means we are back to the present state).

I think the best way to solve the library problem is to have packagers define dependencies, and have a package manager that manages dependencies. Neither of these are currently done, except for some of the packages in the official repository.
Back to top
View user's profile Send private message 
sunburnt


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

PostPosted: Tue 14 Feb 2012, 18:47    Post subject:  

noryb009; I`m sure you agree that shared installed libs. should be very
commonly used ones, if only an app. or two use it compile it with the app.

What about the libs. that Barry put into Puppy? I imagine some are not used.
Why are target groups of small sfs addon libs. any less valuable? ( Devx )

The gstreamer set of libs. are used in a number of media apps. I noticed.
I`m sure there`s other groups also, each sfs file is a dep. for it`s apps.

As I said... Taking satistics on lib. usage and size would be a good start.
Again, most apps. seem to work well, browsers and media are a problem.
Back to top
View user's profile Send private message 
noryb009

Joined: 20 Mar 2010
Posts: 539

PostPosted: Wed 15 Feb 2012, 19:09    Post subject:  

After reading the views in the thread, I've come up with a rough outline of a possible PET2 package format. I've attached it. Any views, ideas, or criticism is welcome.


Quote:
I`m sure you agree that shared installed libs. should be very commonly used ones, if only an app. or two use it compile it with the app.

I agree with you, but I don't know how many libraries are only used a few times. Some stats would be interesting.
PET2_spec_idea.htm.gz
Description 
gz

 Download 
Filename  PET2_spec_idea.htm.gz 
Filesize  2.22 KB 
Downloaded  119 Time(s) 
Back to top
View user's profile Send private message 
sunburnt


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

PostPosted: Wed 15 Feb 2012, 23:48    Post subject:  

Here`s a list I made from Tiny Core Linux`s tree files.
The tree files are the lib. package`s groups of files ( 1 or more files ).
Looking at it, it`s kinda random, but it`s good for getting a ball park idea.
It doesn`t include Tiny Core Linux`s installed libraries.
But T.C.L. has far less than Puppy as it`s very small in size ( 10.5 MB ).
The installed libs. Tiny Core Linux has are undoubtedly very critical.
I`m sure they threw out any libs. not needed to boot bare bones T.C.L.

616 files, 250 files are used 1 time, 521 under 100 times, 590 under 1000.
Highest use is: glib2.tcz at: 70177 times.

What`s needed is the size of the libs. and the number of apps. that use it.
But who cares about seldom used apps.? So choose the app. list first.

Shared libs. = Large size and common use.
Static libs. = Small size and seldom used.

A real statistical analysis would be difficult to get, but well worth it...
deps-tree_count.lst.gz
Description 
gz

 Download 
Filename  deps-tree_count.lst.gz 
Filesize  3.2 KB 
Downloaded  133 Time(s) 
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 6 of 15 [222 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, ..., 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.0982s ][ Queries: 15 (0.0067s) ][ GZIP on ]