|
Bugzilla – Full Text Bug Listing |
| Summary: | YaST: do not download (as default) all architectures metadata | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Azerion Fagonda <azerion> |
| Component: | libzypp | Assignee: | Duncan Mac-Vicar <dmacvicar> |
| Status: | RESOLVED FEATURE | QA Contact: | Klaus Kämpf <kkaempf> |
| Severity: | Enhancement | ||
| Priority: | P5 - None | CC: | adrian.schroeter, andreas.hanke, bart.otten85, coolo, crrodriguez, dmacvicar, ro, schubi |
| Version: | Alpha 2 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| See Also: | https://fate.suse.com/302354 | ||
| Whiteboard: | |||
| Found By: | Beta-Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Patches are coming from autobuild as 'noarch', only the patch dependencies reveal (eventual) architecture restrictions. Usually, fixes to SLE10 are applied to the source code which is recompiled for all architectures. Splitting it up into separate architectures probably doesn't gain us much. Maybe Harald can comment I don't talk about patches but about YaST sw-single. Sorry for not saying that. That patches are noarch I can understand. But sw_single does download all .pat while I only will use i386/i586. Exactly. This bug is about Patterns, not Patches, and the patterns are not 'noarch'. The bug is about all of these files http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/suse/setup/descr/base-10.2-39.i586.pat http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/suse/setup/descr/base-10.2-39.ppc.pat http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/suse/setup/descr/base-10.2-39.x86_64.pat http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/suse/setup/descr/base-32bit-10.2-39.x86_64.pat http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/suse/setup/descr/base-64bit-10.2-39.ppc.pat being downloaded while only the first one of them would be needed on i586 systems, only the third and fourth on x86_64 systems etc. Thank you Andres for making my posts much understandable. :D. That is exacly what I mean. However, I see now that those files are really small and I guess I had a super-slow repo cause I could read all those urls while it was downloading thos little kb's. - nice and clean: detection and only 1 file download - fast: just let it stay this way and focus on other bugs :D Patterns are installation/software management related. I expect Stano could drive this *** Bug 207602 has been marked as a duplicate of this bug. *** I'm not sure if splitting (the relatively small) pattern files by arch is worth it. *** Bug 250451 has been marked as a duplicate of this bug. *** In response to Comment#8, it makes a world of a difference! For me, each pattern file takes 3-5 seconds (at least) to download. And considering how many new pattern files we're currently creating, this should be considered! Will be fixed in future versions We are living in the future since this (sort of) bug was reported on 2006-09-27 :-S. As YAST has the name of being slow I guess every little tweak is a step in the right direction...... Revisit in preparation of Code11 Dropping bi- (resp. tri-) arch repositories is planned for the future. CCing Adrian (for buildservice) and Duncan (for libzypp) Reassign to release manager. Please stop using multi-arch repositories in the future. I think multi-arch repos is not the problem. multi-arch meta files are. So I first want a standard defined how we can have multiple products/architectures in one repo, before we go ahead here. I agree with comment #17, multi arch repos is not the problem. Same with main, non-OSS, debuginfo. You don't need to have them in different repos but to sort them in modules and allow the user to subscribe different modules. debian does it since ages. Then we should do it similarly Pattern filter at download is in 10.3 We should additionally split package metadata per architecture (and why not per module) and download only the needed one. Relevant information in this bugreport was added to feature #302354. Closing this bugreport. mass reopening of later+remind bugs of 11.0 "Relevant information in this bugreport was added to feature #302354. Closing this bugreport." So I do again after mass re-opening. then it had the wrong resolution, should have been FEATURE |
> Seeing what YaST is doing, I was confused. It starts with downloading > many .pat-files. For each platform! Not only i386/i586 but also x64 and > pcc. I will never use those things I guess on an i586-system so why are the > downloaded? I guess there is a good reason for cause the ZEN/YaST-stuff has > been many times under the microscope. But could somebody explain it to me? Azerion ============================= ZYPP is creating a full cache of all metadata available to be able working without the network connection afterwards. Optimizing this behavior might be a good idea. Stano ============================== Only thing that this behavior is usefull: - if you replace your processor with a new type (and so probably your whole motherboard) - and you do not have an network connection. For all those other situations (read: 99.99%) I think it is a bloat. Azerion