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 Fri 19 Dec 2014, 23: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 7 of 15 [222 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, ..., 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: 543

PostPosted: Sat 18 Feb 2012, 16:15    Post subject:  

sunburnt: That list is very interesting. I never knew so many libraries were used that little.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2291

PostPosted: Sat 18 Feb 2012, 17:50    Post subject:  

It doesn't really matter that they are used just a few times. The thing is that *some* program *is* gonna need it -when it needs it. and what do you mean by used? That it actually linked and used by running a program, or that it is a run-time dependency of one, a few or many other progs/libs?

I read your proposal for a package format -Sorry, I don't think it's any better thoought-out than the current one. BTW, the current pet format is already 'pet2' -there was something possibly even more brain-dead in place before... and before that there were *.pup thingies.
Back to top
View user's profile Send private message 
noryb009

Joined: 20 Mar 2010
Posts: 543

PostPosted: Sat 18 Feb 2012, 18:37    Post subject:  

Quote:
I read your proposal for a package format -Sorry, I don't think it's any better thoought-out than the current one.

Would you like to share what you think is a good package format, or how the proposal can be improved?

Quote:
BTW, the current pet format is already 'pet2'

I'm pretty sure the current format is only "pet". The only change to the format I know of was the name of the specs file (pkgname-pkgver.specs -> pet.specs), which did not increase the package version.
Back to top
View user's profile Send private message 
sunburnt


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

PostPosted: Sat 18 Feb 2012, 22:26    Post subject:  

If you`re contemplating statically compiling them, common use is important.
Otherwise it doesn`t mean squat...
It doesn`t provide any solution to the package problem, just insight.

# Package problems:
Different library versions can`t coexist, no version control.
Libraries overwriting or overshadowing other libraries.
Tracking and removal of loose files.
( Any others that I missed? )
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2291

PostPosted: Sun 19 Feb 2012, 04:42    Post subject:  

I don't mean that the current format is called 'pet2', but, as you say, the name of the specs file has changed -and the format of the contents. It's a small change, but even a small change which breaks the 'API' can be significant. src2pkg can create either old-style or new-style pets and of course, that means two separate routines for *that part* of the package-creation code. If ppm (or whatever tool) allows for backward-compatibility, then that is to its' credit -it must have been done deliberately or would not be so.

( Any others that I missed? ) Uh, lots still, but your thinking is certainly much further along than some other folks here.

Sorry, but I'm not really gonna hold any hands here -I've been studying hard for 10 years and it will take anyone else just as long. I won't hold myself back just so that others can catch up. Study other systems and try to figure it all out. Of course debian has the oldest and most elaborate system. It's very hard to beat, but still has a couple of drawbacks. We could all just use someone else's format and tools excpet for the perceived drawbacks. For me, the show-stopper for debian packages/packaging is the reliance on perl and the need for human-intervention in order to create *any* package. the show-stopper for rpm packages is the binary format which means you are alway stuck using some of their tools for installation and creation -even src2pkg uses 'rpmbuild' when creating rpm packages. The rpm 'API' has changed over the years, which just makes the problem worse.
Back to top
View user's profile Send private message 
disciple

Joined: 20 May 2006
Posts: 6464
Location: Auckland, New Zealand

PostPosted: Sun 19 Feb 2012, 06:29    Post subject:  

amigo wrote:
Of course debian has the oldest and most elaborate system. It's very hard to beat

What do you think of the pacman system?

I think the real complaint about it from Q5sys earlier was this:
Quote:
Those things listed above I wouldnt really consider issues with a package. They are from changes to the core system which require special action above and beyond normal updates. However a user has no idea about them until he gets a failed upgrade... or suddenly finds his system will not load properly after an upgrade. Sometimes I wish pacman had a feature where major changes like that would alert the user before installing.

I guess in theory pacman could have a feature that did that somehow, but I it wouldn't really be the 'Arch way'. And the point is that you are expected to read the mailing list to know about major changes that require user intervention or whatever.

==================
There were a lot of interesting thoughts in this thread, especially at the beginning. But I can't help thinking:

1) If you're building a distro from scratch, there is no point in reinventing the packaging wheel. A lot of smart people have spent a lot of time solving all the problems of a packaging system. Surely there is at least one mature package management system that pretty much meets your needs. Use it.
Or am I wrong? What is Debian's equivalent for dealing with things like "pacnew" files? Maybe no normal package manager is as "user friendly" for system upgrades as a Puppy live CD or frugal install, which automatically cleans up anything that would mess with the new version...

2) If you're building a distro from another distro's packages (woof) surely it is crazy not to use the other distro's package management system.

3) As Jemimah (I think) said earlier, the package format is not the real problem - the repository is. If this forum is the de facto package manager that is not sustainable. If only one person can put packages in the repository that is not sustainable. I'm not very familiar with the woof based puppies - how do they interact with the repositories of the "parent" distro? Can you just fire up the package manager and install something from them? That's what I thought was the intent, but I couldn't see how to when I had a quick look...

_________________
DEATH TO SPREADSHEETS
- - -
Classic Puppy quotes
- - -
Beware the demented serfers!
Back to top
View user's profile Send private message 
Aitch


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

PostPosted: Sun 19 Feb 2012, 06:38    Post subject:  

amigo

From my perspective you certainly seem the most knowledgeable that I've read, but rather than others proposing ideas which you then say are bad with reasons, couldn't you propose a package management scheme others could maybe implement [or did you, and I missed it?]

Personally, if it improves or modifies Puppy into a better distro, [or even forks like iguleder/sickgut are doing] I would forego backwards compatibility, if it meant packages from some standard repository could be used....or is this just a step too far to still be puppy development...?

At least this discussion seems to be drawing package management too a focus, so that, at least must be good, as long as agreement is reached on not doing things that are causing problems, right?

Aitch Smile
Back to top
View user's profile Send private message 
Q5sys


Joined: 11 Dec 2008
Posts: 1074

PostPosted: Sun 19 Feb 2012, 13:35    Post subject:  

disciple wrote:

What do you think of the pacman system?

I think the real complaint about it from Q5sys earlier was this:
Quote:
Those things listed above I wouldnt really consider issues with a package. They are from changes to the core system which require special action above and beyond normal updates. However a user has no idea about them until he gets a failed upgrade... or suddenly finds his system will not load properly after an upgrade. Sometimes I wish pacman had a feature where major changes like that would alert the user before installing.

I guess in theory pacman could have a feature that did that somehow, but I it wouldn't really be the 'Arch way'. And the point is that you are expected to read the mailing list to know about major changes that require user intervention or whatever.


Dont get me wrong I love the pacman system... it is just annoying to have to check the mailing lists for issues before i do an upgrade. And yes, those things only happen during core upgrades. However, since we dont seem to care about doing core upgrades though a package system in puppy (a wise move in my book), that shouldnt be an issue.

disciple wrote:
3) As Jemimah (I think) said earlier, the package format is not the real problem - the repository is. If this forum is the de facto package manager that is not sustainable. If only one person can put packages in the repository that is not sustainable. I'm not very familiar with the woof based puppies - how do they interact with the repositories of the "parent" distro? Can you just fire up the package manager and install something from them? That's what I thought was the intent, but I couldn't see how to when I had a quick look...


Thats something thats been discussed before. And the issue with that is simply that most of the core devs in the puppylinux community are all working on their own pupplet versions. Asside from whoever is developing the offical release, everyone is off doing their work. Sure everyone helps on the offical releases, but the rest of the time time energy and effort are spent elsewhere. They are building their systems for their goals. This divergant focus is where our problem lies. Since each pupplet is remarkably different than another... compatibility of packages is in question.

To quote from here
jemimah wrote:
Q5sys wrote:
jemimah wrote:
Ideally, we could just patch the existing ppm. I'm almost ready to work on something like this.

The hosting part should be fairly simple - just ftp access the way smokey01 has his site setup.

The difficult part is finding reliable people to be repo maintainers.


Well cant we start small and only increase in size as we have people on board to assist? We've got a pretty solid core group of developers. Each could work on their own little sliver, that way its not outsourced to random people who really dont care about the work. I dont really want to give them more work... but if they just simply approve or veto stuff... Im sure myself or some other maintainer can do the necessary tweaks here and there.


The problem is, nearly every one of our core devs has their own puplet. So we're all compiling the same packages, and they're generally not compatible.

For instance, in Saluki, I'm trying really hard to categorize things in a way that makes sense (to me anyway). So for each pet, I have to modify the .desktop file to make sure the categories are consistent, it has a full size icon, the name, comment, and generic name are set correctly. So even for stuff where the binaries are fine - I have to rebuilt the pet.

What would be most useful to the users, obviously, is if we could all agree on some sort of standard and have a central repo with packages that work on all puplets (at least the recent ones). This is quite possible for Racy/Wary but if you throw Slacko, Lupu, and Dpup into the mix, I don't think it'll succeed.

I think to start, we really need to figure out who is interested in being a repo maintainer and under what conditions they would be interested contributing.

If we can solve the social problem - I'm sure I can make the PPM support our solution.


So with that in mind I suggested we only work to build one for the official release. But again we come to the problem of who's going to do the work. With each of the core devs doing their own thing... are they going to be expected to build packages for the official release?
Read through that thread to get the jist of the discussion there. No reason for me to quote it all here. While that thread started off about a package site... it gets in the issue of package management a little.

_________________



Back to top
View user's profile Send private message Visit poster's website 
sunburnt


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

PostPosted: Sun 19 Feb 2012, 14:53    Post subject:  

Diagnosing incompatibilities in new package builds can be a real pain.
Just statically compile anything that`s incompatible, conflicts are solved.
Not a perfect solution, but there`s few options with the current setup.

No matter how good Barry makes Puppy, one build can`t fit all needs.

But if a mostly complete set of dependency tree files could be had...
Then anyone trying to compile apps. would have a much easier time.
It`s a fairly easy thing to do ( time consuming ), and gives statistics.
And of course they would require updating as dependencies changed.

Q: Does anyone know how Slackware does tree files or handles deps.?
Back to top
View user's profile Send private message 
noryb009

Joined: 20 Mar 2010
Posts: 543

PostPosted: Sun 19 Feb 2012, 15:37    Post subject:  

Quote:
So with that in mind I suggested we only work to build one for the official release. But again we come to the problem of who's going to do the work. With each of the core devs doing their own thing... are they going to be expected to build packages for the official release?

That is one of the problems with Puppy's structure - everybody works on their own project alone, and doesn't share anything. I've created Ppkg to try to unite some the package creation process, but it still doesn't solve the high number of unmaintained puplets.

Quote:
Diagnosing incompatibilities in new package builds can be a real pain.
Just statically compile anything that`s incompatible, conflicts are solved.
Not a perfect solution, but there`s few options with the current setup.

The "current setup" can be changed to something better - which is a topic of this thread.
Back to top
View user's profile Send private message 
jemimah


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

PostPosted: Sun 19 Feb 2012, 16:25    Post subject:  

noryb009 wrote:

That is one of the problems with Puppy's structure - everybody works on their own project alone, and doesn't share anything. I've created Ppkg to try to unite some the package creation process, but it still doesn't solve the high number of unmaintained puplets.


How does creating a new package format not create further fragmentation?
Back to top
View user's profile Send private message Visit poster's website 
noryb009

Joined: 20 Mar 2010
Posts: 543

PostPosted: Sun 19 Feb 2012, 16:47    Post subject:  

Quote:
How does creating a new package format not create further fragmentation?

Fragmentation - "The process or state of breaking or being broken into small or separate parts."

Doing anything new creates fragmentation - but some new things are good. Puppy wouldn't be here today without IBM making their own computer, Linus making his own operating system, or Barry making his own distribution. A new package format would be good for Puppy, if it is made by, and supported by, the developers in the community. If everyone supports it (or at least likes it better then the PET format), then people will use it, and there would only be a short period of fragmentation.
Back to top
View user's profile Send private message 
2byte

Joined: 09 Oct 2006
Posts: 357

PostPosted: Sun 19 Feb 2012, 22:00    Post subject: Package management  

My thoughts on the matter:
For a package management system to really work it will have to be adopted by Mr. Kauler and incorporated into woof. Period full stop.

For example, take Lucidpup 5.1 and look in /root/.packages/builtin_files. Each builtin package has a file listing each file of that package. 433 packages in all. That is OK but we still have no idea how those packages were compiled or what the ownership and permissions were when installed, among other things.

The current packages listed in the ppm 'database' with file information are the builtin files and the user installed packages. What is not listed and (to me) the killer for implementing decent puppy package management is the database info on the 990 packages listed in woof-installed-packages. There isn't any info at all for the files those packages provide. We cannot even know how many of the builtin files were over written by the woof installed packages, if any. The true package info in the as delivered puppy is unknown and unknowable, and will remain so until decent package management is built into woof, with every package and it's files accounted for, including woof-installed-files. Then management could be continued with the ppm. It will never be truly good management as long as compiled packages from various other distros are plugged into puppy, but at least package and related file info could be provided for everything.

So, creating a new pet.spec or adding or changing fields to the pet.spec alone is not going to allow sensible package management. Even a better ppm will not get the job done until it is implemented at the root, in woof. Until then the best we can do is improve the handling of the user installed packages.

_________________

Back to top
View user's profile Send private message 
noryb009

Joined: 20 Mar 2010
Posts: 543

PostPosted: Sun 19 Feb 2012, 23:30    Post subject:  

Quote:
For a package management system to really work it will have to be adopted by Mr. Kauler and incorporated into woof.

This is the only way, unless you fork puppy. I would much rather have a format specification in place before it is brought to Barry, however.

Quote:
Then management could be continued with the ppm.

Anything but the current PPM. It doesn't do any dependency resolution (outside of the official repositories) and doesn't even handle package upgrades or file conflicts.

Quote:
So, creating a new pet.spec or adding or changing fields to the pet.spec alone is not going to allow sensible package management. Even a better ppm will not get the job done until it is implemented at the root, in woof. Until then the best we can do is improve the handling of the user installed packages.

Without changing woof, the changes get put into a puplet made by one person which will eventually become unmaintained. This is why I am strongly suggesting the new format be made by the packagers who will be using it, as there is not only a much better chance that Barry will accept it into woof, but a much better chance that the format would be used by packagers.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2291

PostPosted: Mon 20 Feb 2012, 02:34    Post subject:  

2byte gets it! Very well put, fellow.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 7 of 15 [222 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, ..., 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.1272s ][ Queries: 14 (0.0088s) ][ GZIP on ]