-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Volker Kuhlmann wrote: >> as the development team of the smart package manager is getting ready to >> release smart 0.42 shortly, I would like to ask everyone who is using >> smart on SUSE Linux to help testing. > > I'm afraid I'm running out of time to spend on this. See my previous > comments on this list for starters. Then add: > > * The handling of repository types and repository locations is not > independent. Some types can only be fetched from some locations.
Not correct. The handling of URLs and protocols is independent of each repository type. What do you mean with "some types can only be fetched from some locations" ? Obviously, the "a directory with RPM files without metadata" repository type only works with local filesystem. There's not really an alternative to that, because it requires file discovery on the directory + reading every RPM file to load the RPM headers (for metadata) + there's no possibility to cache a "smart update" on that. You wouldn't want that behavior on remote URLs ;) That's the only "limitation" I can see - if it's something else, please give some details ;) > * Auto-detection of repository type is lousy, with output of what it is > expected to find too short. Also, type "bunch of rpm files" should > always work as a fallback. It doesn't. There is no autodetection of repository type at all, period. Where have you seen that feature mentioned ? You must always explicitly tell smart that it's a rpm-md, apt-rpm, yast2, ... type of channel you're creating. And it's not even a goal either, for similar reasons as above. While it _could_ be implemented for FTP or local filesystem, file discovery is not possible with HTTP (parsing Apache mod_autoindex is not really an option). The alternative would be to ask every repository backend to try to fetch its specific files and see if some of them reply "ok" + some sort of repository type preference handling, because one location can contain several metadata types (e.g. yast2 and rpm-md). Could be done, in theory, but that's not really a goal as of now, and I'm not sure whether it's really needed either. You must know the repository URL anyway, it's not like it was some magic one-click discovery of all SUSE repositories. Also, you can just ship a .channel file that contains all information (name, type, URL) and you can even embed mirror information with the patch I've added to my smart RPMs. This is e.g. what is done in the Build Service (even if they're called ".repo" files in there, they work with smart), e.g.: smart channel --add \ http://software.opensuse.org/download/Java:/jpackage-1.7/SUSE_Linux_10.1/Java:jpackage-1.7.repo I'd really like to see that in YaST2/zypp BTW. > * The main smart window and its pop-up window sometimes look stone dead, > no input accepted. Confusing, until one finds that clicking the main > smart window to the foreground brings the pop-up on top, but leaves the > second-level pop-up right at the bottom of the pile of desktop windows. Sounds like a bug and/or a place for improvements. Could you file a bug and provide as much details as possible ? http://tracker.labix.org/[EMAIL PROTECTED]&project=smart > * I can see no way to tell it to only install X, and Y of the currently > available updates, but not the other 20. I prefer to be in control when > I want to. smart upgrade foo And for the GUI, I don't see what you mean... View -> Hide non-upgrades View -> Hide installed and you get a list of upgrade candidates. There, as with YaST2, you can right click a package and select "Install" (or just double-click the package). Could you give some more details here ? > * There is no obvious "tell me what you're gonna do" if I click on > something potentialy desastrous, like the "go for it" button. Hmm.. you get a change summary for every action, you have a Summary Window that shows you the currently selected actions, and finally there's a "Execute changes" button and menu option to actually perform the transaction. When you trigger "Execute changes", you see the summary again, where it shows what operations it will perform, also showing what packages will be upgraded, what will be uninstalled, what will be installed, etc... You also get that information from the shell and CLI interfaces. When you run "smart upgrade" from the CLI, there's an additional "--explain" switch that will give you more details about the decision tree. What else would you like to see ? > * It needs to handle patch and delta rpms. Ok. I wonder if there's some form of specification for that. Also, would need to see whether it's doable in a clean way from Python, as it's totally not integrated with rpm itself (i.e. it's not in librpm). > * Log windows can extend way below the bottom of the screen, no scroll > bar, and resizing is disabled. At least the "X"-off button at the > top-right window corner still works... Ok. What windows exactly ? (the "operation progress" window is resizable) > * A quick-launch icon-status thing for the KDE panel along the lines of > susewatcher is essential. If 0.42 has it, make sure it works ;) Erm... there is already ;) Install the "smart-ksmarttray" package and start "ksmarttray". > * Personal preference, but I don't like the gnome look. That's hardly a feature or flaw ;) > * The package list needs to be optionally separate for packages from > other repositories. Specifically, when I'm interested in vendor updates, > I don't need to see the gazillion things already installed. For a quick > updater prog, I like to see: the updates currently available for > packages I have installed, and all the updates available, including > those not applicable and those already installed, suitably marked. You want to see the updates that are already installed ? oO You mean exactly like YaST2 Online Update ? "the updates currently available for packages I have installed": View -> Hide non-upgrades > I stay with my earlier opinion that if smart wants to deserve its name, > it needs to get rather better than it is now. It's better than a > proof-of-concept, but doesn't reach "SUSE standard". Mind you, SUSE > doesn't currently reach its own standard either *vbg* Wow, I can hardly agree with you here, that sounds a lot like cheap bashing rather than constructive criticism. Smart is way more than a proof-of-concept. Actually, it's saving the day for SUSE 10.1 for quite a lot of people. And as far as the "SUSE standard" for package management is concerned, let me say this (and I really love SUSE Linux, been using it since 5.0): - - the "old" YaST2 package manager is/was awfully dumb, you had to do a lot of stuff manually - smart is lightyears ahead and has the smartest resolver of all package management frontends (I didn't say it's perfect, but it's really damn good) - - the current YaST2/zypp/... - well, we'll see once it's finished ;) My opinion is that smart sets the bar pretty high for the yast2/zypp package management. 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) iD8DBQFEkQU6r3NMWliFcXcRAtAtAKCRosH1GvgDm9G78xfUa+9Q4ZpAIgCbBg+m k7vCS3N2FdGJoiHG53qNqx4= =GBvu -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
