Re: [Draft] Pear web

Stig Sæther Bakken wrote: > > ["Tomas V.V.Cox" <cox@idecnet.com>] > > Stig Sæther Bakken wrote: > > > > > > For my tests I did a "make create" under pearweb/sql, but the tables > > there, are not the same as the ones at pear.php.net :-? What am I doing > > wrong? > > Probably because the database on pear.php.net is a bit old, I'll do a > round of "make destroy" and "make create". I see you have made the "make create" and met with my problem: Unknown column 'packages.placeholder' in 'field list'. What is that column? > > > > |Download all packages| > > > > > > For downloading more than one package at once, we need a bundling > > > mechanism. Maybe use a different extension, such as .mtz for > > > "multiple tar/gz files", and then the installer can handle the rest. > > > > Very easy to detect, good idea. The format? A simple tar with tgz's? Or > > should we build a meta-data xml file describing its contents also? > > We could define a generic "manifest" (file listing++) XML format for > both the .tgz and .mtz files, since the tar format does not have such > an index. This should wait until the installer uses a built-in tar > implementation though. Vincent, do you need help? I haven't see your commit to experimental yet. > > > > ------------------------------ > > > > > > > > url: pear.php.net/packages/category.php?idcat=X > > > > ------------------------------ > > > > search: |_______| > > > > > > > > NET category > > > > > > > > Packages: > > > > > > > > |*| _Net_CheckIP-1.1_ summary > > > > |Download| |View Doc| |View Source| > > > > |*| _Net_NNTP-1.3_ summary > > > > |Download| |View Doc| |View Source| > > > > |*| _Net_Ping-1.4_ summary > > > > |Download| |View Doc| |View Source| > > > > > > Wouldn't this just be part of the "package space" browser? > > > > When I enter to a site for the first time I click every where, but when > > it's my 100th time I prefer direct access to things. With this and two > > clicks I could check the doc on-line, quick download what I know that > > need or check the source. And why not, we have enought empty space > > there. > > You're right. But we don't need to add the term "category" into > this. No matter, but why not category? What's the appropiate term? > > > > |Download all "Net" packages| |Download selected packages| > > > > > > > > Leyend: > > > > - Red packages means Experimental State > > > > > > Using colors is a good idea, but we need more than just > > > "experimental". At least "stable" releases should be easily > > > visible > > > as such, and I'd like to see "alpha", "beta" and > > > "development" or > > > "snapshot" states too. > > > > Make standar package state flags in the package.xml would help a lot > > (ie. <Package State="">). Or was selected a convention yet? > > Whoops! State is an attribute of a _release_, not of the package > itself. For example, if "DB 2.x" is under development, the 2.0 > pre-releases will be labelled experimental or whatever, while the 1.x > releases are stable. Whoops''! Seems that the package.dtd needs a urgent update. I'll add this to Common. In the other hand want to do with the changelog? In the past I was against of leaving the changelog in the package.xml, but now guess that it will make things easier for us. What about: <Releases> <Release> <Version>1.1</Version> <State>(alpha|beta|devel|stable|cvs)</State> <Date>2002-1-1</Date> <Notes>blah</Notes> </Release> </Releases> The first release of devel/stable found while parsing will be the values to fill in develrelease/stablerelease columns of packages table. As the database seems to support also multiple authors I'll add it to Common also: <Maintainers> <Maintainer> <Initials> <Name> <Email> <Role>('lead', 'developer', 'contributor', 'helper')</Role> <Maintainer> </Maintainers> Sorry but I'll come back with more things :-) Tomas V.V.Cox