Package Manager major changes for Beta4 and FACTORY Tree
We're replacing our package manager resolver library with a new version called "libzypp". This integration is more complex than estimated and therefore we decided: * to have beta4 available a day later than planned * to have an additional beta5 next week * the package manager in beta4 will only have reduced functionality We're still working on the integration of "libzypp" into our tree and hope to have both update and new installation working. Together with libzypp, we get the zmd daemon, the rug command line interface, the zen-updater, zen-remover, zen-installer packages. They all handle YUM sources and additionally Zenworks servers as installation sources. Note that I'm not sure whether YaST sources will still be supported - or only YUM sources. I'll try to figure this out now. IMPORTANT: The current factory tree contains the first of these changes and I advise to not update the yast components from it! Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Tue, 7 Feb 2006, Andreas Jaeger wrote:
* the package manager in beta4 will only have reduced functionality
Can you elaborate? Will "yast2 sw_single" be able to add and remove packages and resolve dependencies?
We're still working on the integration of "libzypp" into our tree and hope to have both update and new installation working.
Together with libzypp, we get the zmd daemon, the rug command line interface, the zen-updater, zen-remover, zen-installer packages. They all handle YUM sources and additionally Zenworks servers as installation sources.
Is there some documentation that explains zen-updater and what to use instead of susewatcher? - and how to ;-)
-- Andreas Vetter Tel: +49 (0)931 888-5890 Fakultaet fuer Physik und Astronomie Fax: +49 (0)931 888-5508 Universitaet Wuerzburg
Andreas Vetter <vetter@physik.uni-wuerzburg.de> writes:
On Tue, 7 Feb 2006, Andreas Jaeger wrote:
* the package manager in beta4 will only have reduced functionality
Can you elaborate? Will "yast2 sw_single" be able to add and remove packages and resolve dependencies?
If it does not, I'm not shipping beta4 ;-) It will allow adding and removing of single packages but maybe not adding of a complete "selection". Most of the "filters" you have on the left will not work in beta4 - they will only work again with beta5. Resolving has to work.
We're still working on the integration of "libzypp" into our tree and hope to have both update and new installation working.
Together with libzypp, we get the zmd daemon, the rug command line interface, the zen-updater, zen-remover, zen-installer packages. They all handle YUM sources and additionally Zenworks servers as installation sources.
Is there some documentation that explains zen-updater and what to use instead of susewatcher? - and how to ;-)
We'll add infos and pointers to the release notes. If you have anything to add or need, please file a bugreport against the component "Release Notes" of SUSE Linux 10.1, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Hello, Am Dienstag, 7. Februar 2006 21:36 schrieb Andreas Jaeger:
Andreas Vetter <vetter@physik.uni-wuerzburg.de> writes: [...]
Is there some documentation that explains zen-updater and what to use instead of susewatcher? - and how to ;-)
We'll add infos and pointers to the release notes. If you have anything to add or need, please file a bugreport against the component "Release Notes" of SUSE Linux 10.1,
Could you please post this information (or where we can find it) here? It doesn't need to be a perfect text for now, but it would help to get "familar" with the new applications. I guess there will be several questions about this in the suse-* mailinglists when 10.1 final is out - it would be very useful if some people already know what has changed and how it works so that they can explain it if somebody asks ;-) Regards, Christian Boltz -- I read the BOFH texts long time ago and remember them, but this attitude is unfortunately not really called for business Linux versions ;) "In the new SUSE Linux release we are now standardizing on the 'netcat' browser. It is fully costumable to your viewing experience." ;) [Marcus Meissner in suse-security]
On Tue, Feb 07, 2006 at 10:51:28PM +0100, Christian Boltz wrote:
Could you please post this information (or where we can find it) here? It doesn't need to be a perfect text for now, but it would help to get "familar" with the new applications.
I guess there will be several questions about this in the suse-* mailinglists when 10.1 final is out - it would be very useful if some people already know what has changed and how it works so that they can explain it if somebody asks ;-)
If there are large changes, I think it might be a good idea to have this information available. Not only for the email list, but also for Usenet forums and any other medium. houghi -- "The voters have spoken, the bastards ..."
Hi, On Wed, 8 Feb 2006, houghi wrote:
On Tue, Feb 07, 2006 at 10:51:28PM +0100, Christian Boltz wrote:
Could you please post this information (or where we can find it) here? It doesn't need to be a perfect text for now, but it would help to get "familar" with the new applications.
I guess there will be several questions about this in the suse-* mailinglists when 10.1 final is out - it would be very useful if some people already know what has changed and how it works so that they can explain it if somebody asks ;-)
If there are large changes, I think it might be a good idea to have this information available. Not only for the email list, but also for Usenet forums and any other medium.
You should not expect this - as you are not a newbie here. It is a "good" (bad, but solid) tradition at SUSE to create a solid gap between "old" and "new". We have seen that with apt4rpm, we are currently experiencing it with kernel-nongpl (which is forcing a total drop of some beta testers, f.e. me), and It would be no wonder for me if the new concept/documentation again comes too late. Cheers -e -- Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)
On Wednesday 08 February 2006 04:18, Eberhard Moenkeberg wrote:
new concept/documentation again comes too late.
Maybe because it's not ready, they don't have it. As I understand they're in the process of working out the new functionality. Cannot document it if it's a moving target.
On Wed, 8 Feb 2006, Silviu Marin-Caea wrote:
On Wednesday 08 February 2006 04:18, Eberhard Moenkeberg wrote:
new concept/documentation again comes too late.
Maybe because it's not ready, they don't have it. As I understand they're in the process of working out the new functionality. Cannot document it if it's a moving target.
If its not ready, why does it get 'productive'? Greetings, Michael -- I love deadlines, especially the sound they make as they go whooshing by.
Am Mittwoch, 8. Februar 2006 08:28 schrieb Michael 'buk' Scherer:
On Wed, 8 Feb 2006, Silviu Marin-Caea wrote:
On Wednesday 08 February 2006 04:18, Eberhard Moenkeberg wrote:
new concept/documentation again comes too late.
Maybe because it's not ready, they don't have it. As I understand they're in the process of working out the new functionality. Cannot document it if it's a moving target.
If its not ready, why does it get 'productive'? You seem to misunderstand the phrases Beta and FACTORY. If you don't want to take part in testing and reviewing early development phases, I guess you're subscribed to the wrong mailing list.
Greetings, Stephan
On Wed, Feb 08, 2006 at 09:26:41AM +0100, Stephan Kulow wrote:
You seem to misunderstand the phrases Beta and FACTORY. If you don't want to take part in testing and reviewing early development phases, I guess you're subscribed to the wrong mailing list.
Stephan, I think you are partially right here but partially wrong as well. It is correct that one has to expect things breaking in development or test releases. But nobody explained why this breakage has to be provided intentionally by removing the old method before the new method was in-place at all. Even when there is a reason for that it should be explained. The problem here was as well that this problem was known to responsible people (they even confessed that it was intentional) but not announced. Instead all people testing from outside SUSE hat to find themselves that the mechanism was broken. Giving no information about such problems or giving the information very slowly provides the public with a very bad impression on what is going on. Typically I adhere to the saying: "Never attribute to malice what can be adequately explained by stupidity." --- If you don't want people think you are doing stupid things you should give them the chance to understand decissions that are not obviously correct and thus could be considered stupid. So the whole story here is not about expecting or not expecting bugs in software but about not communicating known bugs and doing questionable decissions without explaining the reasons for the decissions. If you had reasons for the decissions and communicated them at least for the smart people it is likely that they accept them. If you didn't have reasons for the decission but there are known reasons against it the decission was obviously wrong and there is no point in blaming other people not having understood something completely unrelated. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Wed, 8 Feb 2006, Robert Schiele wrote:
On Wed, Feb 08, 2006 at 09:26:41AM +0100, Stephan Kulow wrote:
You seem to misunderstand the phrases Beta and FACTORY. If you don't want to take part in testing and reviewing early development phases, I guess you're subscribed to the wrong mailing list.
Stephan, I think you are partially right here but partially wrong as well. It is correct that one has to expect things breaking in development or test releases. But nobody explained why this breakage has to be provided intentionally by removing the old method before the new method was in-place at all.
And it is astonishing, that such a change is made after 3 betas. I would expect such a change in beta1 or in the alpha releases. It is always said, that a version update of this and that program can't be done, because it _could_ break other things. On the other side the package manager is changed at that late stage and it is known, that it _will_ break things. Bye, -- Andreas Klein Andreas.C.Klein@physik.uni-wuerzburg.de
On 8 Feb 2006 at 12:26, Andreas Klein wrote: [...]
And it is astonishing, that such a change is made after 3 betas. I would expect such a change in beta1 or in the alpha releases. It is always said, that a version update of this and that program can't be done, because it _could_ break other things. On the other side the package manager is changed at that late stage and it is known, that it _will_ break things.
(applause)
Bye,
-- Andreas Klein Andreas.C.Klein@physik.uni-wuerzburg.de
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Am Mittwoch, 8. Februar 2006 11:16 schrieb Robert Schiele:
On Wed, Feb 08, 2006 at 09:26:41AM +0100, Stephan Kulow wrote:
You seem to misunderstand the phrases Beta and FACTORY. If you don't want to take part in testing and reviewing early development phases, I guess you're subscribed to the wrong mailing list.
Stephan, I think you are partially right here but partially wrong as well. It is correct that one has to expect things breaking in development or test releases. But nobody explained why this breakage has to be provided intentionally by removing the old method before the new method was in-place at all. Even when there is a reason for that it should be explained. The problem here was as well that this problem was known to responsible people (they even confessed that it was intentional) but not announced. Instead all people testing from outside SUSE hat to find themselves that the mechanism was broken.
Giving no information about such problems or giving the information very slowly provides the public with a very bad impression on what is going on. Typically I adhere to the saying: "Never attribute to malice what can be adequately explained by stupidity." --- If you don't want people think you are doing stupid things you should give them the chance to understand decissions that are not obviously correct and thus could be considered stupid.
So the whole story here is not about expecting or not expecting bugs in software but about not communicating known bugs and doing questionable decissions without explaining the reasons for the decissions. If you had reasons for the decissions and communicated them at least for the smart people it is likely that they accept them. If you didn't have reasons for the decission but there are known reasons against it the decission was obviously wrong and there is no point in blaming other people not having understood something completely unrelated.
Robert
Agreed, the whole point of a Beta test is to test the product is stable enough for release, so the users who join the Beta program should be searching through the program for areas which don't work properly so they can be tidied up before release... Therefore, they need to know what is new and what is know to have problems, without this information they are wasting their time. OK, Public Beta testing isn't like System Testing or User Testing for a custom application, so the beta testers aren't usually working from a test script to test specific areas, but they need to know what areas to give a specific look at. Also putting something new in late in the beta phase is not usually a smart thing to do. At this point in the development cycle we should be looking at a system which is relatively stable and the differences between the Beta releases should be bug fixes for what is already there. Major new functionality should be waiting for the internal development and first alpha releases... David
Also putting something new in late in the beta phase is not usually a smart thing to do.
Let me just summarize. We all know that it is a very bad idea to do it this late. We just have to do it due to new SLES 10 requirements. Ciao, Marcus
On Wed, 8 Feb 2006, Marcus Meissner wrote:
We just have to do it due to new SLES 10 requirements.
That's obvious, and that makes it even worse. Having trust in nld/sles which is based on a distribution with such changes is not easy. Bye, -- Andreas Klein Andreas.C.Klein@physik.uni-wuerzburg.de
On Wednesday 08 February 2006 13:41, Andreas Klein wrote:
On Wed, 8 Feb 2006, Marcus Meissner wrote:
We just have to do it due to new SLES 10 requirements.
That's obvious, and that makes it even worse. Having trust in nld/sles which is based on a distribution with such changes is not easy.
Then we would just be so very much more helpful if we don't bitch but rather download the beta4,5,rc1 and test them really well + reports the bugs. I myself will do just that.
i think there would be much less bitching if major changes such as this were explained ahead of time instead of after the fact. for example: We are removing subfs because its no longer maintainable and we are replacing it with X, Y, and Z. Please test these replacement subsystems. just my nickels worth :-\ -- michael On Wed, Feb 08, 2006 at 01:48:21PM +0200, Silviu Marin-Caea wrote:
On Wednesday 08 February 2006 13:41, Andreas Klein wrote:
On Wed, 8 Feb 2006, Marcus Meissner wrote:
We just have to do it due to new SLES 10 requirements.
That's obvious, and that makes it even worse. Having trust in nld/sles which is based on a distribution with such changes is not easy.
Then we would just be so very much more helpful if we don't bitch but rather download the beta4,5,rc1 and test them really well + reports the bugs.
I myself will do just that.
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Michael Galloway <mgx@ornl.gov> writes:
i think there would be much less bitching if major changes such as this were explained ahead of time instead of after the fact. for example:
We are removing subfs because its no longer maintainable and we are replacing it with X, Y, and Z. Please test these replacement subsystems.
Yes, we failed to communicate some of these changes *before* even if I know about them. I'd like to say sorry for that and will try to improve communications here, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Wed, Feb 08, 2006 at 12:28:54PM +0100, David Wright wrote:
Also putting something new in late in the beta phase is not usually a smart thing to do. At this point in the development cycle we should be looking at a system which is relatively stable and the differences between the Beta releases should be bug fixes for what is already there. Major new functionality should be waiting for the internal development and first alpha releases...
Well, for all we know, SUSE might have changed everything in the past up untill the RC 27 or whatever. It is just that now we see it. It would however be nice if we could get some more insight as to why it has been done. I say: if it means improvement, bring it on. I don't see a release date after RC 1 and testing, so I am not sure what preasure there is timewise. Also what has changes could be explained better (perhaps with a HTML file on the Alpha/Beta CD's or some other form) so people know where to look and where NOT to look. OTOH not having any information will let people wander around and the absence of a guideline could bring up bugs that a more structured testing would not show. houghi -- If a 6600 used paper tape instead of core memory, it would use up tape at about 30 miles/second. -- Grishman, Assembly Language Programming
houghi <houghi@houghi.org> writes:
Well, for all we know, SUSE might have changed everything in the past up untill the RC 27 or whatever. It is just that now we see it. It would however be nice if we could get some more insight as to why it has been done.
;-) In reality, we did not change that much as we did this time - 10.1 is really a bad exception.
I say: if it means improvement, bring it on. I don't see a release date after RC 1 and testing, so I am not sure what preasure there is timewise.
It means improvement, I'll try to write up some more explanation for those points that I mentioned yesterday in the IRC session and send it later around.
Also what has changes could be explained better (perhaps with a HTML file on the Alpha/Beta CD's or some other form) so people know where to look and where NOT to look.
There's the factory NEWS which contains some information (too little), the CDs contain a Changelog with all information (too far to read by anybody) - and so the middle in between is missing.
OTOH not having any information will let people wander around and the absence of a guideline could bring up bugs that a more structured testing would not show.
;-) I cannot expect a structured testing but will try to get this done better - both in the short term and in the long run, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
David Wright <david.wright@wright-is.com> writes:
[...] Also putting something new in late in the beta phase is not usually a smart thing to do. At this point in the development cycle we should be looking at a system which is relatively stable and the differences between the Beta releases should be bug fixes for what is already there. Major new functionality should be waiting for the internal development and first alpha releases...
Yes, I agree completely to your paragraph - but the package manager did not make the deadline and we really wanted to have it in 10.1, so decided to get it in really late (planned for beta3 but that schedule was not met). I do hope that this kind of major functionality change will not happen in future releases again, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Am Mittwoch, 8. Februar 2006 14:49 schrieb Andreas Jaeger:
David Wright <david.wright@wright-is.com> writes:
[...] Also putting something new in late in the beta phase is not usually a smart thing to do. At this point in the development cycle we should be looking at a system which is relatively stable and the differences between the Beta releases should be bug fixes for what is already there. Major new functionality should be waiting for the internal development and first alpha releases...
Yes, I agree completely to your paragraph - but the package manager did not make the deadline and we really wanted to have it in 10.1, so decided to get it in really late (planned for beta3 but that schedule was not met). I do hope that this kind of major functionality change will not happen in future releases again,
Andreas
Thanks for the explanation Andreas. It is a shame that such an exception had to come so early in the life of openSUSE. Let's hope it all goes well... Dave
Hi, On Wed, 8 Feb 2006, Silviu Marin-Caea wrote:
On Wednesday 08 February 2006 04:18, Eberhard Moenkeberg wrote:
new concept/documentation again comes too late.
Maybe because it's not ready, they don't have it. As I understand they're in the process of working out the new functionality. Cannot document it if it's a moving target.
It seems you did not understand my critics. Cheers -e -- Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)
On Wednesday 08 February 2006 10:07, Eberhard Moenkeberg wrote:
It seems you did not understand my critics.
Actually I do, but I'm in favour of [latest bits] versus [older bits+documentation]. There's NLD and SLES for that. :-)
Andreas Jaeger wrote:
We're replacing our package manager resolver library with a new version called "libzypp". This integration is more complex than estimated and therefore we decided:
* to have beta4 available a day later than planned
* to have an additional beta5 next week
* the package manager in beta4 will only have reduced functionality
We're still working on the integration of "libzypp" into our tree and hope to have both update and new installation working.
Together with libzypp, we get the zmd daemon, the rug command line interface, the zen-updater, zen-remover, zen-installer packages. They all handle YUM sources and additionally Zenworks servers as installation sources.
Note that I'm not sure whether YaST sources will still be supported - or only YUM sources. I'll try to figure this out now.
IMPORTANT: The current factory tree contains the first of these changes and I advise to not update the yast components from it!
Andreas
Andreas: Where I can found information about this tools? and the **technical** reasons,advantages..and why this stuff was changed ?
Cristian Rodriguez <judas_iscariote@imapmail.org> writes:
Andreas Jaeger wrote:
We're replacing our package manager resolver library with a new version called "libzypp". This integration is more complex than estimated and therefore we decided:
* to have beta4 available a day later than planned
* to have an additional beta5 next week
* the package manager in beta4 will only have reduced functionality
We're still working on the integration of "libzypp" into our tree and hope to have both update and new installation working.
Together with libzypp, we get the zmd daemon, the rug command line interface, the zen-updater, zen-remover, zen-installer packages. They all handle YUM sources and additionally Zenworks servers as installation sources.
Note that I'm not sure whether YaST sources will still be supported - or only YUM sources. I'll try to figure this out now.
IMPORTANT: The current factory tree contains the first of these changes and I advise to not update the yast components from it!
Andreas
Andreas:
Where I can found information about this tools? and the **technical** reasons,advantages..and why this stuff was changed ?
rug comes with it's own man page - and the other graphical software should be rather intuitive. About the reasons, I'm writing up something right now and will sent it tomorrow, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Am Dienstag, 7. Februar 2006 20:51 schrieb Andreas Jaeger:
We're replacing our package manager resolver library with a new version called "libzypp". This integration is more complex than estimated and therefore we decided: [...] Together with libzypp, we get the zmd daemon, the rug command line interface, the zen-updater, zen-remover, zen-installer packages. They all handle YUM sources and additionally Zenworks servers as installation sources. What I don't understand: Why do you want to support YUM now and wanted to drop APT? Everybody I know uses APT instead of YUM, because YUM is very slow, when refreshing package lists e.g. Even most Red Hat/ Fedora users are fed up with YUM...
Was this just a political decision or a technical one? If you have to integrate Zenworks-Server-Support, can't it be done without breaking existing things? What about the highly praised Smart and adding Zenworks-Support to Smart? Consider also, that many people switched to apt with 10.0. Is much faster than YaST. Do you want them to switch to Zen-whatever? Will Zen-Updateer be as fast and easy as APT? I do not need an answer. But you should have one for the release notes ;-) -- Mit freundlichen Grüßen, Marcel Hilzinger Linux New Media AG Süskindstr. 4 D-81929 München Tel: +49 (89) 99 34 11 0 Fax: +49 (89) 99 34 11 99
On Wed, 8 Feb 2006, Marcel Hilzinger wrote:
What I don't understand: Why do you want to support YUM now and wanted to drop APT? Everybody I know uses APT instead of YUM, because YUM is very slow, when refreshing package lists e.g. Even most Red Hat/ Fedora users are fed up with YUM...
We are not using YUM -- we are using the metadata format that YUM uses as well. Calling those installation repors "YUM sources" might be a bit misleading. Actually they should be called "RPM Metadata" or RepoMD or something like that... Regards Christoph
Op woensdag 8 februari 2006 21:45, schreef Christoph Thiel:
We are not using YUM -- we are using the metadata format that YUM uses as well. Calling those installation repors "YUM sources" might be a bit misleading. Actually they should be called "RPM Metadata" or RepoMD or something like that...
I would vote for repomd as it is metadata for an rpm repository. It is not metadata for an rpm package. -- Richard Bos Without a home the journey is endless
Am Mittwoch, 8. Februar 2006 20:43 schrieb Marcel Hilzinger:
What I don't understand: Why do you want to support YUM now and wanted to drop APT? Everybody I know uses APT instead of YUM, because YUM is very slow, when refreshing package lists e.g. Even most Red Hat/ Fedora users are fed up with YUM...
Do you believe, what you writeh here? Do YOU measured it, or derives your knowledge from others using ancient yum stuff? Anybody really measured the speed of yum versus apt? I bet, it's approx. en par. After that, please compare the nr. of source code lines ;-)
Consider also, that many people switched to apt with 10.0. Is much faster than YaST. Do you want them to switch to Zen-whatever? Will Zen-Updateer be as fast and easy as APT?
Sure, yum is much faster than YaST/YOU here, too, but flexibility in repo mgmt (including self maintained ones), and ease of root strapping are even more valuable in my book.. Pete
On Thu, 9 Feb 2006, Hans-Peter Jansen wrote:
What I don't understand: Why do you want to support YUM now and wanted to drop APT? Everybody I know uses APT instead of YUM, because YUM is very slow, when refreshing package lists e.g. Even most Red Hat/ Fedora users are fed up with YUM...
Do you believe, what you writeh here? Do YOU measured it, or derives your knowledge from others using ancient yum stuff?
Anybody really measured the speed of yum versus apt? I bet, it's approx. en par. After that, please compare the nr. of source code lines ;-)
Consider also, that many people switched to apt with 10.0. Is much faster than YaST. Do you want them to switch to Zen-whatever? Will Zen-Updateer be as fast and easy as APT?
Sure, yum is much faster than YaST/YOU here, too, but flexibility in repo mgmt (including self maintained ones), and ease of root strapping are even more valuable in my book..
... but again, we are _not_ using YUM (the tool), but our own implementation to access the same repository format that YUM uses* ;) Regards Christoph *) http://linux.duke.edu/projects/metadata/, with some SUSE-specific extensions.
participants (19)
-
Andreas Jaeger -
Andreas Klein -
Andreas Vetter -
Christian Boltz -
Christoph Thiel -
Cristian Rodriguez -
David Wright -
Eberhard Moenkeberg -
Hans-Peter Jansen -
houghi -
Marcel Hilzinger -
Marcus Meissner -
Michael 'buk' Scherer -
Michael Galloway -
Richard Bos -
Robert Schiele -
Silviu Marin-Caea -
Stephan Kulow -
Ulrich Windl