[packman] packman future

[Marc Schiffbauer]

* Ralf Corsepius schrieb am 10.01.03 um 10:42 Uhr:
> Am Don, 2003-01-09 um 19.10 schrieb Waldemar Brodkorb:
> > 
> > We could use some special comments in the header of the spec-file,
> > (SuSE itself use such mechanism) every maintainer make some more
> > tags on every package:
> > #Packman-Depends: xine-lib xine-ui 
> > #Packman-Info-de: asfsaf
> > #Packman-Info-en: adasf
> This kind of meta-language in spec-files can work for linux vendors,
> because they live a closed universe of rpms (all rpms are provided by
> them). 
> 
> The packman situation is different: We have to consider vendors and
> other parties to replace packages we provided at one point in time, i.e.
> we don't live in such kind of closed universe, vendors live in.
> 
> Hypothetical example:
> 
> We provide a lyx-1.2.3 package for SuSE, which depends on libforms-1.0
> packages also provided by us. 
> 
> * Now, supposed, some time in future, SuSE releases a libforms-1.0
> package, but doesn't update their lyx.
> 
> I.e. at one point in time we'd have to have a "Packman-Depends:
> libforms" in lyx's rpm-spec, at a later point in time, this would not
> apply anymore. If this info is inside of the spec-file, so we'd have to
> rebuild the package.
> 

Yes.

> * Consider supporting several vendors, eg. providing lyx and libforms
> for RH/SuSE and may-be other vendors. If all packman-meta-info had to be
> contained inside of the rpm-specs, this would prevent us from writing
> vendor-independent rpm-specs.
> 
> 

Or imagine debian packages. Originally Packman was not intended to
only support SuSE Packages. I have written the frontends with the
intension to support RedHat or Debian packages as well for example.

> Another technical issue: Internationalized package descriptions. Two
> problems with it: 
> 
> * There doesn't exist any standardized approach to deal with them in
> rpm-specs (RH uses specspo (an external package-description database),
> Conectiva uses i18n-ed rpm-tags; Don't know what SuSE does.)
> 
> * The package description as to be seen on packman's end-user web-form
> doesn't necessarily have to match with a package's %description.
> 

ACK

> 
> > The spec file is always the most important part of the
> > RPM build, maintainers would edit this file always.
> Another point: Though some of the info in such a "meta-file" would
> overlap with the actual spec file or the info contained inside of an
> rpm, this info would by far not be identical.
> 
> Actually it would only contain the infomation required to put it into
> the appropriate place of on the server and to fill out the entries for
> the database.
> 
> Furthermore, some of the info for the web-form and installing the
> packages on the server can be extracted from rpm's directly 
> (rpm -q --queryformat "%{ARCH}" <pkg>.rpm), but these

would be rpm -qa ... but ACK ;)

> "Packman-meta-tags" can not be extracted from the rpm. I.e. this would
> require to unpack the corresponding src.rpm and to parse the spec-file.
> To cite Jeff Johnson: A true PITA, my friend ;-)

Not? Then thats the show stopper. Forget about un'cpio'ing every
Package...

> 
> To summarize: IMO, trying to encode Packman meta-info into the spec-file
> is too unflexible and probably will fail (may even be impossible) to
> implement.
> 
> Anyway, let's stay realistic, I don't see this to happen any time soon,
> unless somebody actually wants to invest time into this.
>


I suggest to use every information that can be queried easily from a
package to pre-fill and to improve the currect webinterface. I
always told that the webinterface is not very comfortable. But it it
much improvable so that we can reduce typos and time to spend on it.

Advantages:
 - the currect system will be improved, but not totally replaced.
   -> no need to get used to something else, less work
 - we have this kind of QA henne mentioned. Means: every packman can
   check and propably update detected values.
 - packmans can write a german translation of the pachage
   description to be put into the database beside the autoextracted
   english description (rpm -qp --queryformat "%{DESCRIPTION}")
 - flexibility: can easily be extended to extract such information
   from .deb's as well
 - ...?

Disadvantage:
 - a bit more time consuming than a full automated version. but:
   much less time consuming than the current system.
 

I think Packman should stay an interactive service. It should not be
only a download place in some kind of way...

-Marc
-- 
BUGS My programs  never  have  bugs.  They  just  develop  random
     features.  If you discover such a feature and you want it to
     be removed: please send an email to bug at links2linux.de