-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 houghi wrote: > On Mon, May 29, 2006 at 11:20:21PM +0200, jdd wrote: >> but if you want, we can forget the actual 10.1 tests and >> look only at what we need as a package manager... > > Thank you. bug solving belongs in another thread. > > <snip stuff I agree with> > >> I think that in most situations the version info can be >> retrieved lately, in the background. In most cases, peoples >> needs only the current version. > > What do you mean by 'in the background'?
jdd, please get a clue about how current package repository metadata formats are implemented (e.g. RPM-MD (yum)). The version info cannot be retrieved later, you first have to fetch a complete copy of all the repository metadata of all the repositories (aka channels aka inst-sources) you have configured. Then, and only then, a package manager's engine is able to compute the paths and operations for upgrading, installing dependencies, possibly removing packages because of broken dependencies introduced by upgrades, etc.... >> we need some kind of repository management. It's possible to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ What's the problem with yast2 and rpm-md repositories ? We've had "repository management" since 10 years. If that's not what you meant, be more explicit. >> have the same package on different repositories and we may >> need to use an older package for whatever reason. This is an >> exception from the previous stated system (ignoring the >> version), seldom used and so in cases we can afford to wait >> a little... When the same package is present on different repositories.. that's what package managers are made for, they have algorithms to solve those "issues". Having to downgrade is a valid point though. That should be possible from the YaST2 Package Management screen as well. > How I see this happening is by saving what you download, not so much > things you install from the CD or DVD, and save that in > /usr/src/packages/RPMS/* for the full RPMs and wherever for the > updates. Well, if you're talking about downgrading, it's something that should be supported by the package manager. But it depends on the implementation of the package manager - wouldn't take for granted that zypp/zmd/rug (wherever the decision engine is implemented) is able to compute downgrades properly, it's a pretty different thing than upgrading packages. Smart is able to do that nicely. If the zypp/zmd engine can do that too, it would be useful to be able to downgrade from the GUI. A practical example: we 3rd party repository maintainers provide the very latest version of a lot of packages. Let me just take the example of gimp. Now, a user might want to try out the latest gimp package and upgrades using my repository. But then he either notices and issue (and informs me of that issue, hopefully ;)) or just notices that gimp release has a bug. In such a case, he would want to downgrade to the version that's shipped with SUSE Linux. > For the RPMs you either need to run createrepo or create_package_descr. > Perhaps createrepo might be easier, because smart and the others can use > it as well. For the record: smart can also use yast2 repos (created with create_package_descr), as Mauricio Teixeira implemented that in smart. createrepo is _much_ easier to use than create_package_descr though, because in order to create a valid yast2 repository, there's all kind of black magic to do that's not covered by any tool (at least none that's available to us). > This means signing the packages and adding the directories to the > apropriate places. Signing packages is not mandatory, nor is signing repositories. If you trust the packages and the repository (which is very likely with a copy of RPMs you grabbed from a repository on the internet.. you trust in the first place ;)), just run "createrepo ." on the directory that has the RPM files (or its parent directory) and you're done. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEe3Vcr3NMWliFcXcRAuoFAKC85gH+edi/3q5Qkt0EZ3t9DKc1twCgk8bo Qe0uR4iAWoQz+BPR3LyD1/A= =1ro4 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
