Pdaxrom Contrib?

[Meanie]

how will you distinguish whether a package will work with a particular revision of pdaXrom, ie beta1 and beta3, beta4 and r121, all, ..., or is the plan to have the contrib feed for latest pdaXrom version only?

[ZDevil]

Actually i do all my packages under Beta3 and for versions before Beta4/r121. (r121 is not stable enough for me to use it yet.)
I suppose a more detail list of major changes/differences between previous versions and Beta4/r121 is needed.
For example, it seems r121 comes with much more recent gnome and gtk2 stuff. So some ports of new sources making use of these work under r121, but perhaps not for the older Betas. Correct me if i am wrong.

ps. Thanks Meanie for your tip. To be honest I've never used du -hs (maybe du -s is more suitable for packaging?). I haven't seen anything about the specification of the size in the notes on ipkg and packaging online. Or is there a pointer to some good source?

[Chero]

Hi,

Don't know how uploading/adding packages will be done, but if you ask the user (uploader) in this interface for which version the package was created, you would be able to make different feeds (pre-beta1, beta1, beta2, beta3, beta4-r121). I don't think people are still using pre-rc3 or pre-rc5 versions.
Or we could add the pdaX-version somewhere in the filename or the control file. I know this creates problem with existing packages, but I'm quite sure they would be solved soon enough, this is a living community.

I'm in favour of putting them in one feed (per version). Maybe a cron-job (only once a day would be nice) could do this as somebody already suggested. (Packages could be made available for simple download immediatly after uploading).

Have Fun,
Chero.
(off to vote now ...)

[daniel3000]

Hi,

I like the idea of a new feed system, because I have now entered all feeds which could hold compatible packages into my ipkg.conf, and many packages are listed about four times under "Available".

A new feed system could avoid duplicate packages in the feeds.

Now we have about one feed per pdaXrom version plus the contribs.

A package is usually thrown in only one of  the pdaXrom feeds, although it is probably compatible with more than one pdaXrom versions.
Hence the need to have more than one feed (plus the contribs) in the package manager.

It would be nice to have indeed one feed per pdaXrom version, the contributed packages should go into THAT feed also, but each package should go into all the feeds of the pdaXrom versions it is compatbile with.

So one would only need ONE feed in the package manager.

If the author of a package does not know about compatiblity with other pdaXrom versions than that he used it on, he could first put it into one feed and let others test the package on other pdaXrom versions. FOr each version it has been successfully tested on, it could be copied into the respective feed, too.

Or even more advanced:
Each pdaXrom version could have one stable and one experimental feed.
Use the experimental feed for those packages which have been developed for another pdaXrom version and still have to be approved to work on this version.

The upload interface (probably a web page with a file choose dialog) could have checkmarks, for which pdaXrom versions the package has been tested, and for which ones it should still be tested, because it should be compatible (maybe with automatic preselection based on the "tested on" value: a package tested on beta3 should be preselected to go into the pdaXii13 experimental feed for example...

With such a system, the feeds would grow much larger in size than they are now, I guess.
So, in order to conveniently browse them with a browser, not only the index.html should be generated from the Packages file, but also a hierarchical (tree-like) structure, based on the categories, should be built.

Maybe it even makes sense to write a new graphical package manager as a replacement for qpkg, which is able to display packages in groups, choose the destination more conveniently (e.g. displaying the destination NAME instead of the mount point) etc.etc.

I hope I described clearly enough what I mean.
Looking forward to a new feed system!  

daniel

[Meanie]

Hi,

Don't know how uploading/adding packages will be done, but if you ask the user (uploader) in this interface for which version the package was created, you would be able to make different feeds (pre-beta1, beta1, beta2, beta3, beta4-r121). I don't think people are still using pre-rc3 or pre-rc5 versions.
Or we could add the pdaX-version somewhere in the filename or the control file. I know this creates problem with existing packages, but I'm quite sure they would be solved soon enough, this is a living community.

I'm in favour of putting them in one feed (per version). Maybe a cron-job (only once a day would be nice) could do this as somebody already suggested. (Packages could be made available for simple download immediatly after uploading).

Have Fun,
Chero.
(off to vote now ...)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=152076\"][{POST_SNAPBACK}][/a][/div]

rather than a cron job, a regenerate button would probably be a better idea. only users who have an active account and submitted packages can click that regenerate button, and if the regeneration is in process, it will be restarted by clicking the button....

[robyinno]

Hi,

I like the idea of a new feed system, because I have now entered all feeds which could hold compatible packages into my ipkg.conf, and many packages are listed about four times under "Available".

A new feed system could avoid duplicate packages in the feeds.

Maybe it even makes sense to write a new graphical package manager as a replacement for qpkg, which is able to display packages in groups, choose the destination more conveniently (e.g. displaying the destination NAME instead of the mount point) etc.etc.

daniel
[div align=\"right\"][a href=\"index.php?act=findpost&pid=152083\"][{POST_SNAPBACK}][/a][/div]

For example I have SL-6000 and the more recent installable version is 1.1Beta1 so at this moment I don't know which contrib feed are working for me. So Is good a new system of organize feeds for contrib.

Si many times I'm thinking to modify gipkg becouse I need to search a package not only to have the list, and is good to know every package from which feed come.


Roberto

[daniel3000]

For example I have SL-6000 and the more recent installable version is 1.1Beta1 so at this moment I don't know which contrib feed are working for me. So Is good a new system of organize feeds for contrib.

Si many times I'm thinking to modify gipkg becouse I need to search a package not only to have the list, and is good to know every package from which feed come.


Roberto
[div align=\"right\"][a href=\"index.php?act=findpost&pid=152200\"][{POST_SNAPBACK}][/a][/div]

If I need to know from what feed a specific package (which is only listed once in the package manager) comes from, I do a

Code: [Select]

grep "packagename" /usr/lib/ipkg/lists/*
However, there is still the problem of choosing from which feed I want to install a package which is listed two or more times in qpkg.

One more column in qpkg ("feed name") would be enough...

daniel