Puppy Package Site - Planning Stages

News, happenings
Message
Author
User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#21 Post by technosaurus »

If only I could find a way to use my Droid as a server...
Like this:http://www.appbrain.com/app/kws-android ... ndroid.kws
Has anyone tried one for a non-rooted phone.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

#22 Post by Q5sys »

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.

stu90

#23 Post by stu90 »

Q5sys wrote:Ive wanted to do this for a while now. but ive had another idea...
I originally was thinking of doing this through a webgui as you can see in the thread. But I'm ok if we can script out the whole thing and make a program that'll run like Pacman in Arch linux or apt-get, etc. Just do pull a file from the site with the file list, grep the file you want... then download the link. etc.
Im sure you get where im going with this. a GTK interface could be made at a later point in time if everything works.
Depending ob what kind of text file would you be using -
If it is a repo file like the other puppy repositories then it would be very easy to add to ppack package manager.
Image

If it is just a text file with a simple list of packages in the repository then it should be straight forward enough to adapt this little gui i have for downloading Bodhi linux .bod packages (search is not implemented yet but all other options work)
Image

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

#24 Post by jemimah »

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.

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

#25 Post by Q5sys »

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.
I understand what you are saying. Each one of the core devs has their own sort of methodology, which tends to make things less than seamless with other puplets. When I meant 'start small', I was being quite literal. Start with only 1 puplet either Racy/Wary or Slacko per haps. And work forward. While it would be great to go back and make every current puplet work... maybe this is something we should just start working towards in the future, and deal with the current mess as status quo with all current puplets.
I dont think Mick would have to much objection to it, but I cant speak for him. I'll drop him a line and see if he'll chime in on it since slacko is the most current 'offical'. Hopefully if we can get something solid and working, it can then be utilitized for any future 'offical' releases. If he does have an issue with it (I doubt), then we can make a simple go at using Racy/Wary.

You're right the Social problem is the hard part. I'd hope that if we make a strong case for a standard (through a working system as an example), everyone would slowly adopt it. Yea I know, I can be sort of a dreamer. lol.
In any case... I've got puppy-packages.org registered (been about a year or so now). I'm willing to offer it up for the greater good.

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

#26 Post by jemimah »

How well do the external repos work with slacko/lupu/dpup? (I always compile my own stuff so I haven't played with this a lot).

If it already works pretty well then it makes sense (to me) to concentrate on wary/racy since the repos are small and need the most work.

At least to me it makes little sense to spend a lot of time building a puppy out of other distro's packages if you have to recompile the whole repo anyway. Maybe I am missing something here - feel free to set me straight.

Personally, the concept of building puppy from somebody else's repo always made me feel rather unneeded and like the art of finding, hacking, and compiling small packages is largely unappreciated by the majority of users. My point is, there might be more devs if it seemed like devs were actually wanted/needed.

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

#27 Post by scsijon »

A thought or two:

This won't be the easiest to setup, but I believe it would make later processing and extending easier!

1- Use a format similar to what barry has done with wary/racy.
in other words, a 2/3 character suffix for base/version specific compiled packages and just i386/i486/i586/i686 for common use packages.

Thus:
pheilix-1.2.9-i486 - would be the pheilix package that SHOULD run on any puppy base that can handle a i486 compiled package! Base Maintainers/Developers would require someone to be responsable to check that it is so as part of their create process!
BUT:
pheilix-1.2.9-w5c - would be the pheilix package that was compiled to run on wary522 / racy522. It may run on others, but no guarantee is provided. If it was pheilix-1.2.9-w5 it would only be certified compatable for earlier wary & racy versions, but MAY run on later wary/racy versions.

I would also like to see a source directory for all compiled packages to be supplied by the initial pet creator as a mandatory requirement, so other base maintainers, could if need be, compile for their own bases without totally restarting from scratch, hopefully with a 'compilers readme' added so any problems/fixes/workarrounds are available for later builders. It would also include later package versions as they are created, but with the notes in earlier versions available, hopefully the later builders work is a little easier.

2- I would prefer something within the PPM package for downloading, something like adding a redline through unsuitable pets or colouring them red, so the user knew they are so. They should not be stopped from installing, just warned that they should think again before doing so! However, where the package is a core package, it should only be available for download, not download and auto-install. How this is done, i'm not quite sure, but there is the BuildingBlock item in the type field, maybe that could be used!

Uploading could be a similar process to that talked about where the new pet & source could be dropped into a box with a question or two with a space for a few lines of information. It should initially go to a hidden area to be checked out and certified by 'a responsable person(s)' for the each of the base(s) it's been submitted against before release.

3- There needs to be something simple to upload on suitable 'mirror servers' to automatically handle the mirror processes. It should not be the responsability of the source server to do anything 'other' than starting the remirror process on the mirroring servers, but the Mirroring servers should be able to handle the rest automatically, preferably with a single email to the mirror server's admin that it has happened or a problem has ocurred. There should also be a written process for setting up a new server!

edit: tpyos!
Last edited by scsijon on Thu 19 Jan 2012, 01:15, edited 1 time in total.

User avatar
smokey01
Posts: 2813
Joined: Sat 30 Dec 2006, 23:15
Location: South Australia :-(
Contact:

#28 Post by smokey01 »

I thought iguleder had a good idea with his auto compiling script.

In other words, the repository is just the source. When you select the source it automatically compiles and installs the application.

At least this way the application should always be compatible with your OS.

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

#29 Post by Q5sys »

smokey01 wrote:I thought iguleder had a good idea with his auto compiling script.

In other words, the repository is just the source. When you select the source it automatically compiles and installs the application.

At least this way the application should always be compatible with your OS.
so basically the arch linux pkgbuild concept. which is basically the slackbuild concept just packaged in an auto run script.
That'd work, but then to add any program a user would have to download and enable the devx package. If packages are already build then users can just download pre built binaries and not have to worry about the devx.sfs
That's a bit cumbersome for someone who just wants to add a browser or other small program. To make it simple for the end user we'd have to start adding the compiling enviroment into the base isos, which would drive our sizes up.

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#30 Post by 01micko »

To answer jemimah
How well do the external repos work with slacko/lupu/dpup?
Reasonably well, but still is a work in progress, as anything I guess.

You can get a sane kde4 installation in slacko but do need to tweak it a little for correct operation. Many other packages install without a hitch. I do see your point though about compiling stuff, as some stuff included in slacko which I have compiled is incompatible with some stock slackware stuff. More on that later.

-


Slacko ships with the "ziggy" interface by default, an interface developed by Sigmund. I find it much better on small screens and a bit more intuitive. I really like the "app store" look though as in stu90's screenie.

However, interface is one thing, the underlying engine is the key and dependency checking is the bug bear IMO. This is more the packager's responsibility the way petget is structured at the moment. Maybe dir2pet needs to be more rigorous in checking dependencies and all of them listed in the dependency field.

And what about sfs management? Should it be part of PPM or separate?
Puppy Linux Blog - contact me for access

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

#31 Post by Q5sys »

01micko wrote:However, interface is one thing, the underlying engine is the key and dependency checking is the bug bear IMO. This is more the packager's responsibility the way petget is structured at the moment. Maybe dir2pet needs to be more rigorous in checking dependencies and all of them listed in the dependency field.

And what about sfs management? Should it be part of PPM or separate?
While I do think SFS's should be in the PPM... at the same time I dont. Pets and SFSs are different beasts entirely. Not to complicate things... but I think perhaps SFS's should be in a seperate system. Not only is their use different, but their purpose was to help make puppy somewhat modular. Of course now that we have SFS load on the fly the line between pets and SFS is becoming blurred

I agree that the packager should list dependencies. I guess we need to come up with some agreed convention on how thats should be accomplished. Shouldnt be too hard to have an additional script set in dir2pet or whatever else to run ldd and then sed the output into a txt file (perhaps a .pd for pet dependency)
again... the social problem of getting everyone on board.

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

#32 Post by jemimah »

Dependencies wouldn't be much of a problem if we had a central repo and a proper package maintenance team. All we actually need is someone to test whether or not a given package installs properly and fix it if it doesn't. A complex packaging database scheme is not needed.

It's the proliferation of puppy flavors that largely prevents the devs from teaming up on repo maintenance, leaving each dev with the impossible job of maintaining a repo by him or herself.

What can we do to encourage teamwork rather than forking? The read-only architecture of puppy, the flexibility of woof, the desirability of packages that are custom-compiled, and the ease of remastering all make forking easy and working together difficult.

The only person who commands enough respect around here to unify puppy development is Barry - and that's definitely not his style.

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

#33 Post by scsijon »

jemimah wrote:Dependencies wouldn't be much of a problem if we had a central repo and a proper package maintenance team. All we actually need is someone to test whether or not a given package installs properly and fix it if it doesn't. A complex packaging database scheme is not needed.

It's the proliferation of puppy flavors that largely prevents the devs from teaming up on repo maintenance, leaving each dev with the impossible job of maintaining a repo by him or herself.

What can we do to encourage teamwork rather than forking? The read-only architecture of puppy, the flexibility of woof, the desirability of packages that are custom-compiled, and the ease of remastering all make forking easy and working together difficult.

The only person who commands enough respect around here to unify puppy development is Barry - and that's definitely not his style.
Maybe, what we need is to go back to the basic concept of puppy and change it slightly (as barry did in 2.12, you are doing with saluki, stu and others, including myself, have done from time to time with various builds) and separate the Basic or Core component of Puppy from the User Applications part of Puppy, but now on a Permanent Basis.

It would mean those that were interested in the base/core part, such as BarryK is with the ARM at the moment, could concentrate on that component of Puppy, knowing that others are keeping the User side in hand and up to a reasonable standard.

Those that wanted either a General or Specific User-set Version could concentrate on that component, and even others that wanted puppy for things like firewalls, various server-types, etc., could customise a User component, while knowing the Base/Core Puppy was being looked after by those that knew that part of it.

I 'spoke', some time ago in another topic, of having multiple .sfs files matching the directory structure autoload if they existed. I wonder if, with all the work that has and is happening with sfs access and with the number of sfs's being increased and working properly afterwards, if it's time to consider this again.

It would mean that someone, and we have quite a few music/multimedia members, could form a Team and work on this specific topic with the output being a broad sfs for general release PLUS specific sfs's and Pets to cover specific function sets, such as what a Music Studio or a Band-on-the-road would need. They would be expected as part of their function, to test, update and handle problems with their group of apps, and it could be that for a particular Application, the message was that it wasn't "certified" for a particular Base other than version nnnnnn-xx.xx.x-ippp.pet! Each Package would need / must have an entry in the Additional Software Sections and all versions be in the ONE entry!

The same could be done with the Business world and Games worlds'. Graphics and Documentary are also others that come to mind that would improve greatly by this structure. Internet may be a problem, but it just means the Team would have to be a bit more 'robust' in structure.
Things like Networking, Utility, Desktop, System, Setup and Filesystem I think ?would, ?maybe at least in part, need to stay with the Base/Core Teams. Maybe these need a Single Specialist Team instead, made up of a rep from each 'certified' Puppy in the current dataset!

However on re-reading, i'm not sure if I've got too off-topic in all this, but I believe the basics of it need to be considered, at least in general, if the storage site is not to end up having to be totally re-worked every six-months / year or two and that would loose support in the userbase as you would get 'it's too hard to do anything with the site as it's always changing' messages appearing everywhere!

anyway, another five aussie cents worth

regards to all
scsijon
Afterthought: maybe it will need to 'pseudo' mirror the appropriate forum sections to work properly! OUCH!

User avatar
ecube
Posts: 88
Joined: Fri 11 Jul 2008, 17:00
Location: Västerås, Sweden

Repo maintainer offer

#34 Post by ecube »

jemimah wrote: I think to start, we really need to figure out who is interested in being a repo maintainer
Jemimah,

I have some spare time and I am willing to help.

Available hardware consists of six PCs of varying age and three printers.

How do I proceed?
:D
ecube

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

#35 Post by jemimah »

scsijon wrote: Those that wanted either a General or Specific User-set Version could concentrate on that component, and even others that wanted puppy for things like firewalls, various server-types, etc., could customise a User component, while knowing the Base/Core Puppy was being looked after by those that knew that part of it.
It's pretty difficult to separate the core from the user component as I am finding out. Puppy is very tightly integrated and implemented in a way that makes a lot of assumptions. Getting xfce working smoothly has required dozens of patches to core puppy scripts.

Saluki attempts to separate the base and the applications. It has one sfs - the adrive- that holds all the apps and autoloads if it exists. The adrive can be rebuilt quickly and easily, without woof. This is my attempt to make collaboration more possible.

Currently, there is no facility to tell the ppm what dependencies an installed SFS provides. This will have to be added if the adrive idea is going to work correctly with the ppm.

I don't think it should be split into more sfses than one adrive because a lot of the apps share libraries. Like I can use gstreamer for the browser and all the multimedia apps, the cd burner, the chat client, and the presentation viewer, and a maybe other stuff. However someone else may want to build around mplayer and ffmpeg or xine, so they can just dump the whole adrive and make their own without the big libs that they don't want.

It'll takes some time to see if the concept catches on.

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

Re: Repo maintainer offer

#36 Post by jemimah »

ecube wrote:
jemimah wrote: I think to start, we really need to figure out who is interested in being a repo maintainer
Jemimah,

I have some spare time and I am willing to help.

Available hardware consists of six PCs of varying age and three printers.

How do I proceed?
:D
ecube
I can give you upload access to the saluki repo. However, it's best if you wait until I get the saluki base nailed down first because some changes I make require a lot of things to be repackaged and I don't want anyone to have to redo their work. I'll PM you the password in a couple weeks when it's ready. In the meantime feel free to provide feedback about saluki - I consider feedback from contributors the most useful.

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

#37 Post by Aitch »

Currently, there is no facility to tell the ppm what dependencies an installed SFS provides
Jemimah

I posted a couple of suggestions in the Saluki thread - I don't know if they will fit with your adrive concept?

Good move though... :D

Aitch :)

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

#38 Post by Q5sys »

jemimah wrote:It's pretty difficult to separate the core from the user component as I am finding out. Puppy is very tightly integrated and implemented in a way that makes a lot of assumptions. Getting xfce working smoothly has required dozens of patches to core puppy scripts.

Saluki attempts to separate the base and the applications. It has one sfs - the adrive- that holds all the apps and autoloads if it exists. The adrive can be rebuilt quickly and easily, without woof. This is my attempt to make collaboration more possible.

It'll takes some time to see if the concept catches on.
Amen to that one. I've been beating my head against a wall now for quite a while trying to get gnome3 to run without any problems. Its humbling when you start digging in and you realize how much you dont know about puppy. lol
When you are done with your xfce voyage, will you be posting the road map you used to get things to work? and which core scripts you had to tweak and how (just s simple description). Im sure that would be immensely helpful to a bunch of people.

Back on Package manager though, I was thinking more along the lines of something just for add-on programs at this point,. Sure later down the road it'd be nice to have everything, but I think if we try to do too much at once, the idea will crash and burn. I think if we start small, it may work.
I do not however want to detract anyone from their own work and what they are trying to dev just to work on this idea. We've been going for years without it, however i do hope that we could maybe get something up and running before 2020. lol

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

#39 Post by jemimah »

I've got a tarball of woof patches that I will post once I'm done tweaking them.

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

#40 Post by jemimah »

So I've been running the saluki repo with a few maintainers for a while now and I've been thinking about what would make life easier on the server side. (getting back to the original topic of this thread)

What would be awesome is if the server could maintain the Packages-*-official database. Ideally the the repo maintainers could upload or delete pets, and some process on the server would notice the changes and update the DB.

The second thing would be a way to have multiple accounts access the same repo. Each maintainer would have their own account so they could be cut off easily if the account is compromised. All maintainers could upload to the repo, but I think only one admin account should be able to delete or overwrite other people's uploads.

Post Reply