[opensuse-factory] [Bug 169636] eth devices renamed
Hi, Doing some more regression tests, I was looking at some old problems. What is the purpose of this feature? I mean why should the kernel decide to start renaming eth-devices in the first place? I mean, if you have three (pseudo) ethernet devices, all with UNIQUE-mac address, on what ground is the kernel doing such drastic action... Hans Apr 21 16:02:42 ldap1 kernel: eth0 renamed to eth9 Apr 21 16:02:42 ldap1 kernel: eth1 renamed to eth10 Apr 21 16:02:42 ldap1 kernel: eth2 renamed to eth11 -- pgp-id: 926EBB12 pgp-fingerprint: BE97 1CBF FAC4 236C 4A73 F76E EDFC D032 926E BB12 Registered linux user: 75761 (http://counter.li.org) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Package Management Design and Experience
On Tue, Jun 27, 2006 at 01:41:50PM +0200, Klaus Kaempf wrote: kdebase3-SuSE could be changed to use createrepo instead of genIS_PLAINcache and the installation_sources replacement. Ideally, the installation_sources replacement would be called installation_sources and support the same commandline syntax as the old installation_sources. Was the old tool and its options sufficiently useful ? How do they compare to e.g. rug or smart ? It was usefull. `installation_sources -a ftp://example.com/URL` Perhaps it is that the current chain of command is not clear. There is zen, there is lybzypp, there is rug, there is yast. And I can imagine that it is confusing what to use when. http://en.opensuse.org/Zmd clears a bit things up, but it is not as clear as it used to be. Perhaps somebody with knowledge (e.g. not me) could make a re-write of http://en.opensuse.org/Examples_using_rug and change it into http://en.opensuse.org/Rug or make a generic Rug page that points towards the examples. Something that is more beginner friendly then a manpage. The fact that `rug st` does not say anything about YaST installation sources does not make things easier. A proper GUI for rug would be nice. If that could be YaST, that would be great. And I mean a single point of contact, not seperate programs, like zen-installer, -updater and -remover. -- houghi Please to not toppost http://houghi.org My experience with SUSE You can have my keyboard ... if you can pry it from my dead, cold, stiff fingers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] FSH: mysql tftp
On Tue, Jun 27, 2006 at 11:18:28PM +0200, Pascal Bleser wrote: OTOH, what's the default directory being set by MySQL builds ? At first glance, /srv/mysql would make sense, but if SUSE Linux is the only distribution on the planet that uses /srv/mysql and all the others use /var/lib/mysql (and so do the mysql.com builds), then I'm not sure it would be such a good idea... Would a symlink from /var/lib/mysql to /srv/mysql work? Or would there be issues with some things not working, because it is a symlink? -- houghi Please to not toppost http://houghi.org My experience with SUSE You can have my keyboard ... if you can pry it from my dead, cold, stiff fingers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] FSH: mysql tftp
Hi, houghi schrieb: Would a symlink from /var/lib/mysql to /srv/mysql work? Or would there be issues with some things not working, because it is a symlink? IMHO compatibility symlinks are ugly and should be avoided where possible. Changing the working directory of software packages is a very difficult thing. It has the potential to upset quite a lot of users. What some of you might possibly know that there are many rumours out there that SUSE uses different directory layouts than the rest of the world and moves config files and working directories around all the time. This is really one of the typical things that non-SUSE users frequently say about SUSE. With that in mind, I propose that nothing is changed unless the current solution really *violates* the FHS, which I doubt. Moving things around just because the new solution would comply a little bit better should be avoided if the current solution is also compliant. Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
