OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: InSearchOf on January 21, 2007, 10:51:43 am
-
Currently if a new package is built by a community member it is sent to pgas, laze, sashz or myself... it is moved to a folder on the server. Users could add this location to package manager as a feed.
New and improved would be 100% managed by the community members... a member (with the privledges) would log on under the new site, go to the community and upload there own packages, update and delete when they make updates...
But the only "con" would be I may not be able to make proper feeds out of them.
I will still have to look... but vote! and what ever you decide is what is done...
I'm goin to be doing this VERY SOON! so vote now and prolly in 3 or 4 days I'm goin to start moving data...
Late
-
Some quick questions:
How will this new arrangement be different from the existing "contrib" feeds in the current pdaxrom site?
I would very much like to be able to log on and add my packages directly. But I haven't got an account to do so. How can I get one?
And do the contributors have to create a Package list themselves or is there some easy way to generate one?
-
All you have to do it register... but just to let you know the new site it currenty not up and functional... and we will be requiring new user registration when the new site becomes live... due to all the spam account created previously...
the issue is there may not be a "feed" at all... you will go to the site... and browswer the files through a drupal api app... it does look pretty nice... the directory structure will still be the same... just possibly no feed...
Package lists would be created by the user... but I may be able to find an easy way...
Late
-
That sounds good. The current situation is a bit too messy for me as there are too may different package sources and feeds (some are obselete). A more integrated source should be the way to go.
Just wonder how would installation differ w.r.t. ipkg as there will be "no feed".
And will there be space for attaching user notes and screenshots as well?
-
Yep...
Late
-
Just a note... the offical feeds will stay the same... this is only pertaining to the community "contrib" feeds....
Late
-
Still a package list and a filelist for the "contrib" (= cottage?) packages will be very handy, just like the official feeds.
Off topic: And I've had a question but I've always been afraid to ask ... how is the package size in the control file determined? By the package size or by the installation size? If we use the installation size how do i know that in advance before packaging?
-
I would like to see all of the contribs in single feeds by release/version. I miss the ability (even if out of date) to be able to look at a listing of all the contents. If there were a single contrib, there would only be one place (other than the official feeds) to look. I would like to see contrib as a feed rather than have to browse/download, but I would rather have a single contrib that required browse/download than the current where you have to search, add feeds, etc. The mega feed that pdaxii13 uses is nice.
-
I rather like the free form method of the feeds as they are, but seeing that it does take a relatively long time to download and install a package that might not work with your architecture, it would be very nice to have more info somehow: i.e. machine that the package was built on and for There are a lot of duplicates of certain programs floating around, and it's hard to tell which ones work for which models.
Also, I would like to see if the sources were patched during the build, and if so how. Would there be a mechanism to upload the sources to the new site? I would somewhat like to see the APT method for ipkgs: i.e:
apt-get source $PACKAGE_NAME
or
ipkg install build-dep $PACKAGE_NAME
-
I kinda like the idea of putting all contrib packages in one place, so you simply have one official set and one unofficial set. Each package could be still be attributed correctly to the contributor, it would surely be easier to maintain as a feed (also doesn't require users to be constantly adding feeds and searching for packages), and it would avoid some double-ups etc.
-
Off topic: And I've had a question but I've always been afraid to ask ... how is the package size in the control file determined? By the package size or by the installation size? If we use the installation size how do i know that in advance before packaging?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=151930\"][{POST_SNAPBACK}][/a][/div]
I'm fairly sure it's installation size. After #make DESTDIR=/x/y/z intsall and stripping, can't you just check the size of dir /x/y/z?
-
perfect: one centralized feed
better: one centralized but no feed
ok: feeds but not centralized (a.k.a current)
-
Off topic: And I've had a question but I've always been afraid to ask ... how is the package size in the control file determined? By the package size or by the installation size? If we use the installation size how do i know that in advance before packaging?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=151930\"][{POST_SNAPBACK}][/a][/div]
I'm fairly sure it's installation size. After #make DESTDIR=/x/y/z intsall and stripping, can't you just check the size of dir /x/y/z?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=151964\"][{POST_SNAPBACK}][/a][/div]
I see... Another dumb question: how to check the size of a dir (not a tarball) in the shell?
(Sorry for OT again but this bears on contributing packaging )
-
Off topic: And I've had a question but I've always been afraid to ask ... how is the package size in the control file determined? By the package size or by the installation size? If we use the installation size how do i know that in advance before packaging?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=151930\"][{POST_SNAPBACK}][/a][/div]
I'm fairly sure it's installation size. After #make DESTDIR=/x/y/z intsall and stripping, can't you just check the size of dir /x/y/z?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=151964\"][{POST_SNAPBACK}][/a][/div]
I see... Another dumb question: how to check the size of a dir (not a tarball) in the shell?
(Sorry for OT again but this bears on contributing packaging )
[div align=\"right\"][a href=\"index.php?act=findpost&pid=151982\"][{POST_SNAPBACK}][/a][/div]
du -hs directory
-
I agree one centralized contrib feed to which several community members have access is best.
But the only "con" would be I may not be able to make proper feeds out of them.
Why would you not be able to make a proper centralized contrib feed, is there some problem?
Isn't this a normal login shell account in which one can run a shell script (there are several of those floating around) to produce the proper filelist after every update of the packages content?
Can't we schedule a cron job for it as well?
Here is the ipkg-make-index script (http://coder.freeshell.org/zaurus/feed/) I've been using so far for Beta1 (found it somewhere) .
-
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?
-
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?
-
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 ...)
-
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
-
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....
-
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
-
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
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