[opensuse-factory] distribution meeting - introduction and agenda
We have an internal meeting every few weeks called "dist meeting" that discusses major technical changes in our distribution. Since it's not possible for most of you to attend it, I'd like to try an experiment and share the agenda before the meeting - and the meeting minutes afterwards with you. I'm asking for your feedback on the agenda and any comments that you have and will bring those comments into the meeting and raise the points you've made. Will this work? The planned topics for tomorrow's meeting are: * D-Bus 0.91 and PolicyKit/resmgr We just switched to D-Bus 0.91 and the question arises whether to continue to use resmgr or switch to PolicyKit. * Move to GNOME 2.16 The packagers have started already with the first packages, we want to discuss the timeframe for the move and the move of GNOME to /usr (from /opt/gnome). * SuSEconfig removal SuSEconfig is currently run after each package installation by YaST and is a huge bottleneck. Some scripts have already been removed and we have to discuss how to move on. * update messages general/conditional (e.g. bind) During update of packages they could notify users about changes via email and/or the SuSEplugger (until 10.0, this is not anymore in 10.1). Most of these are outdated and not really usefull anymore and should be removed. The question is how to handle situations like bind where config files get rewritten and the user should be informed if this fails. * Dropping UP Kernel on i386/x86-64 The proposal by the kernel team is to use only SMP kernels and no UP kernel. It's already this way on Xen - there is no Xen UP kernel. Advantages: One less kernel rpm. On 64bit there will be only two kernel rpms then, kernel-default and kernel-xen; and with some luck if paravirt ops works out as designed we can then later drop kernel-xen too and only ship a single 64bit kernel. 32bit could go down to two. Less QA. Less space on ftp servers. Less build time. Avoids a lot of problems with install kernel being different from final kernel. The i386 UP kernel e.g. doesn't support advanced APIC modes, which broke i386 installation of SLES10 on some systems. We've had quite a lot of bugs in this area over the years. Disadvantages: Will be slightly slower and bigger on UP systems. Most of the performance difference is fixed up by kraxel's LOCK prefix runtime patch. Memory usage will be up a bit on UP systems We would lose a few drivers which are BROKEN_ON_SMP. Usually these are long unmaintained drivers which are broken for other reasons anyways so it's not a big loss. Also we never had them in the SMP kernel and most modern systems run SMP kernels. There might be other bugs caused by this, but Fedora has done this before us and they didn't seem to have regretted it so far. * Linker Options and Optimizations We plan to use the recently developed linker optimizations for the GNU hashstyle and use the readonly relocations: LDFLAGS="-Wl,-O1 -Wl,--hash-style=both" (http://lwn.net/Articles/192082/ ) LDFLAGS="-Wl,-z relro" (see http://people.redhat.com/drepper/nonselsec.pdf) 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I really like this move. I am just concerned that there will not be enough time in the current schedule to complete the entire task.
I agree with this. I think the changes needed should be done at the time. I dislike the running of this script all the time.
I prefer the email notification. I would like to see the few situations where config files change that an email is sent to root.
I think this is a good move. Also I prefer the dropping of UP kernel. I like having things as close to the same as possible. I think the advantages out way the disadvantages. Thanks, - -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFE40qrVtBjDid73eYRAprDAJ46bLlHfX/JSDvacxSr8KV6OLZ8KwCfSCJG wizHHdAl8jkeu8qddmF//kw= =LAhV -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, Am Mittwoch, 16. August 2006 16:44 schrieb Andreas Jaeger:
Will this work?
It depends on some points: - you should give some more background information about the topics - I'll insert some questions regarding this below. - you should mail some days earlier the next time ;-))
What are the advantages and disadvantages of each?
Hmm, what's the reason for this? BTW: Will KDE be moved also?
What's the replacement for config files that are _generated_ by SuSEconfig? (as in: including /etc/sysconfig/foo is impossible for the respective application) -> You won't be able to do this in rpm postinstall scripts or alike ;-) Possible solutions: a) drop the sysconfig files for this applications (opinions about this depend from "good idea, they are simply annoying" up to "keep sysconfig, it's easy to use for basic configuration" depending on whom you ask ;-) b) keep the parts of SuSEconfig that generate config files based on /etc/sysconfig settings OK, that were the (at least for me) unclear parts. Let's continue with the other ones ;-)
IMHO: mail them to root - that's easy to implement and easy to use. Hint: KMail / Evolution should come with the local /var/spool/mail/$user mailbox preconfigured.
* Linker Options and Optimizations [see kernel, s/kernel development/packaging/]
Regards, Christian Boltz -- 1.-4.9.2006: Weinfest in Insheim Pig Slip, Hifi-Delity, AH-Band, Frank Petersen und die Deafen Goblins spielen bei der Landjugend. Mehr Infos: www.Landjugend-Insheim.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Aug 16, 2006 at 06:42:44PM +0200, Christian Boltz wrote:
Well, if you don't have the background information for a specific topic it might not make much sense to give a comment to that topic, right? And btw. there is not a requirement that you give an answer to all open questions in the universe. ;-) Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
Hello, Am Mittwoch, 16. August 2006 20:21 schrieb Robert Schiele:
It depends on the point of view ;-) I prefer to know about the changes in advance - that's much better than whining afterwards if something is broken. Don't get me wrong - there are topics that I won't comment (like compiler options or kernel packages) because I don't know much about them and am not really interested in, too. But when changes in the basesystem (like dropping SuSEconfig) are discussed, it's always good to know what will replace their functionality. A short summary (like in the kernel section of Andreas' mail) would really be useful.
And btw. there is not a requirement that you give an answer to all open questions in the universe. ;-)
42 *eg* Regards, Christian Boltz -- 1.-4.9.2006: Weinfest in Insheim Pig Slip, Hifi-Delity, AH-Band, Frank Petersen und die Deafen Goblins spielen bei der Landjugend. Mehr Infos: www.Landjugend-Insheim.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Wednesday 16 August 2006 18:42 schrieb Christian Boltz:
In general it is a request by the LSB/FHS group.
BTW: Will KDE be moved also?
KDE 3 will not be moved, because this would cause compatibility and update problems. But KDE 4 will be installed to /usr as well later.
c) use /etc/sysconfig direct from runlevel scripts or applications.
not needed, because YaST asks during installation to whom these root mails should get forwarded. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, Am Donnerstag, 17. August 2006 08:12 schrieb Adrian Schröter:
OK, that's a valid reason.
Good idea to do it this way ;-)
Hmm, this way several config files (KDM, Postfix, Apache...) will need to be rebuilt each time the application is started. Unless I miss something, I don't consider this a good idea ;-)
I think you missed my point ;-) Yes, the root mails are forwarded to a user. There's no problem with this. But it isn't obvious for beginners how to retreive these mails. (Advanced users know they have to read /var/spool/mail/username, beginners probably don't.) My proposal: KMail, evolution and Thunderbird [1] should come with the local mailbox account /var/spool/mail/username preconfigured so that system mails will be received "automatically". Regards, Christian Boltz [1] no need in mutt, poeple using it probably know about /var/spool/mail ;-) -- 1.-4.9.2006: Weinfest in Insheim Pig Slip, Hifi-Delity, AH-Band, Frank Petersen und die Deafen Goblins spielen bei der Landjugend. Mehr Infos: www.Landjugend-Insheim.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Christian Boltz <opensuse@cboltz.de> writes:
Please add this as a feature request on the wiki, 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 Donnerstag, 17. August 2006 13:57 schrieb Andreas Jaeger:
OK, it's on http://en.opensuse.org/Feature_Wishlist/Misc now. BTW: Thanks for the (probably not intentional) reminder to propose a better handling for the wishlists. IMHO it's just painful to use the wiki for this... Reasons: - the wiki can't be searched by solution (there are some items marked as solved, but still listed on the page) - if something is finally removed as "wontfix" from a package wishlist, chances are good that it reappears sooner or later (may happen with "done" also if it is removed before next stable release) - the package wishlists have a very bad usability - if you want to add a comment or a wish, you have to find your way in the (long) tables My suggestion is to create a "openSUSE Wishlist" product in bugzilla (with the current wishlists as components), maybe with a special input form to have the fields that are currently in the wishlist always filled. (Yes, I know that there was a "package wishlist" in bugzilla already in pre-openSUSE times. And I wonder why it was moved to the wiki.) Regards, Christian Boltz -- 1.-4.9.2006: Weinfest in Insheim Pig Slip, Hifi-Delity, AH-Band, Frank Petersen und die Deafen Goblins spielen bei der Landjugend. Mehr Infos: www.Landjugend-Insheim.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Christian Boltz <opensuse@cboltz.de> writes:
Yes, I know, we're looking into alternatives already, 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 Donnerstag, 17. August 2006 17:57 schrieb Andreas Jaeger:
I'm glad to hear this :-) I hope the search for alternatives will be done in the public - the community has to use it [1], so you should involve us before any decision is taken. Regards, Christian Boltz [1] I don't know about the SUSE internals, but I guess you don't need to add a wishlist entry if you want a package or feature ;-) -- 1.-4.9.2006: Weinfest in Insheim Pig Slip, Hifi-Delity, AH-Band, Frank Petersen und die Deafen Goblins spielen bei der Landjugend. Mehr Infos: www.Landjugend-Insheim.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Christian Boltz <opensuse@cboltz.de> writes:
You have to - we have our own tool for this called FATE: http://programm.froscon.de/attachments/41-SuseFeatureManagement_Froscon.pdf#... And most internal stuff goes through FATE. Sorry, I don't want another tool/method for adding features, instead just use one - and hope this works out for all of us. The question is how to "open" FATE in such a way that all of us can use it, it was not designed for such a large group... 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 Freitag, 18. August 2006 16:26 schrieb Andreas Jaeger:
Interesting presentation. At least I now know what that ominously FATE, mentioned in bugzilla comments from time to time, is ;-)
As far as I can see from the presentation, chances for this are good ;-) Let me try to summarize the differences compared to bugzilla - I hope this will help to understand the tool better: (please correct me if I'm wrong on some points) - a request can have multiple categories; categories can be (in bugzilla terms) a "product" or a "component", maybe (?) also other usage is possible [1] - it's XML based internally, including XQuery etc. [2] - it supports rich text (HTML-like) in comments [3] - it's possible to compare multiple revisions of a request - this implies that the request text can be changed (instead of just adding comments as in bugzilla) - two web interfaces (one with full, one with restricted view) and KDE client available In general, it looks like FATE mixes the best things of bugzilla and a wiki - sounds promising. (Is there a demo installation somewhere to test it?)
The question is how to "open" FATE in such a way that all of us can use it, it was not designed for such a large group...
Where do you see a problem? Server load? Permission handling? ...? Maybe you can provide read-only access as a first step... Regards, Christian Boltz [1] Sometimes this could be useful in bugzilla product / component also ;-) [2] There's no problem with this as long I don't have to write XSLT files for it *g* However, I'm not sure about the performance when compared with a database. [3] not sure if I really need this ;-) -- 1.-4.9.2006: Weinfest in Insheim Pig Slip, Hifi-Delity, AH-Band, Frank Petersen und die Deafen Goblins spielen bei der Landjugend. Mehr Infos: www.Landjugend-Insheim.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Christian Boltz <opensuse@cboltz.de> writes:
Correct.
I don't know :-(
Permission handling: We do not want our partners to see each others request for our enterprise products - and you shouldn't either see there's. I guess that everything coming in through openSUSE can be public.
Maybe you can provide read-only access as a first step...
Yes, would be an option. But it still means I need a way to flag specific features as public.
It's fast enough.
[3] not sure if I really need this ;-)
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
http://programm.froscon.de/attachments/41-SuseFeatureManagement_Froscon.pdf#... Interesting presentation. At least I now know what that ominously FATE,
just a note to say this page can't be viewed in seamonkey jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* jdd <jdd@dodin.org> [08-19-06 05:37]:
http://programm.froscon.de/attachments/41-SuseFeatureManagement_Froscon.pdf#...
just a note to say this page can't be viewed in seamonkey
Hummmm, show ok here. needs acroread (or perhaps xpdf) seamonkey-1.0.4-2.1 -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Patrick Shanahan a écrit :
I usually read pdf, but in this folder, most pdf won't read or crash seamonkey. I remember there was a similar thing for fosdem. not very important (I can download the files and see it locally) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* jdd <jdd@dodin.org> [08-19-06 13:24]:
direct seamonkey to use xpdf to read it. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, Am Samstag, 19. August 2006 10:22 schrieb Andreas Jaeger:
Sounds like "novellonly" group in bugzilla and "reporter can always access his reports". However, I'm a bit wondering why feature requests need to be top-secret ;-)
I guess that everything coming in through openSUSE can be public.
ACK.
Hmm, the question is if you want it to be "closed unless open" or "open unless closed". (I prefer "open unless closed" because it tends to have more open feature requests.) If I got the concept of partner.fate right, the easiest way seems to be to have an openSUSE group to "open" feature requests. (Needless to say that _everybody_ should be in the openSUSE group by default.) The only disadvantage is that this uses the "closed unless open" way to work which I don't really like ;-) Regards, Christian Boltz PS: The more I think about this, I ask myself why bugzilla and FATE are different applications. They have much in common, and the differences might be good features for each other. -> what about merging them to FATEzilla? ;-) -- 1.-4.9.2006: Weinfest in Insheim Pig Slip, Hifi-Delity, AH-Band, Frank Petersen und die Deafen Goblins spielen bei der Landjugend. Mehr Infos: www.Landjugend-Insheim.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Christian Boltz <opensuse@cboltz.de> writes:
Partners speak about their upcoming hardware that is not public yet or add business reasons which no other parter should see. These features come in way before a release - and before a public announcement.
I guess so as well.
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 Thursday 17 August 2006 17:47 schrieb Christian Boltz:
you would have the same with any other tool. It would be better to keep such entries and only add the reason why not to add it.
- the package wishlists have a very bad usability - if you want to add a comment or a wish, you have to find your way in the (long) tables
right, maybe we should rethink about the format ... Our other solution, which we use inhouse for our buisness products is FATE btw. You may want to play around with it and comment, if you think this is also usable for a community ... http://programm.froscon.de/attachments/41-SuseFeatureManagement_Froscon.pdf#... (we miss a FATE page in www.opensuse.org ... )
the wiki is way more flexibel here and you can also see all the other package wishes in the same are (so this on might become obsolete). -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 2006-08-18 09:24:50 +0200, Adrian Schröter wrote:
saved searches? darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Marcus Rueckert a écrit :
in fact there should be somewhere (probably not on the wiki) a large table with _all_ the know Linux packages (hudge, but freshmeat browse should give a hint :-) with the status of these packages relative to openSUSE: included (openSUSE version, on cd; on dvd, on line a little like distrowatch) not included for a reason (with the reason) on review (AI XXX) unknown the last category could be on a wiki page (unknown - that is unknown from the openSUSE packagers) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, Christian Boltz <opensuse@cboltz.de> [2006-08-17]:
You forgot Seamonkey. :) Regards, Bernhard -- "Der Computer ist die logische Weiterentwicklung des Menschen: Intelligenz ohne Moral." -- John Osborne --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Christian Boltz <opensuse@cboltz.de> writes:
I don't know everything and would like to have expert advice ;-)
- you should mail some days earlier the next time ;-))
Will try to ;-)
That's what we try to figure out in the meeting.
Requests by e.g. lsb.
BTW: Will KDE be moved also?
With the next major KDE update: Yes, we will.
We have to figure this out for each script. It might be done in the postinstall of the packages that need it - but only there. Not for unrelated stuff.
[...]
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
Em Qui, 2006-08-17 às 12:08 +0200, Andreas Jaeger escreveu:
IMHO that should be the desired action, since if you manage packages using "rug" or "smart" none call SuSEconfig at the end of the operations. So making the package call it on the %post to run only the needed scripts would be nice. -- % Mauricio Teixeira (netmask) % mteixeira{a}webset{d}net <> Maceio/AL/BR % http://mteixeira.webset.net <> http://pmping.sf.net --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, Mauricio Teixeira (netmask) schrieb:
Are you really sure? ;-) At least rug runs SuSEconfig after each transaction, and it's _painful_ compared to YaST because other than YaST, it doesn't show what it does, so there's no way to guess how long it will take. Concerning the alternative package managers like smart, there was just in this very moment a report about it: https://bugzilla.novell.com/show_bug.cgi?id=199925 At least SuSEconfig.automake should be called in the %post script of those few packages that really need it instead of each transaction. This would also solve the problem of alternative package managers not running SuSEconfig after each transaction. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Em Qui, 2006-08-17 às 13:04 +0200, Andreas Hanke escreveu:
At least rug runs SuSEconfig after each transaction, and it's _painful_ compared to YaST because other than YaST, it doesn't show what it does,
Well, I've never used rug, so I was not sure about it. Regarding smart, it's an old request to run SuSEconfig at the end, but looks like we'll wait for this discussion here to reach a decision so we would make ours on smart. :) And sure running the needed scripts on %post would do the trick, but it would require a lot of documentation so that the packagers would know if/when/how/why would they need to do that. -- % Mauricio Teixeira (netmask) % mteixeira{a}webset{d}net <> Maceio/AL/BR % http://mteixeira.webset.net <> http://pmping.sf.net --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi there, On Thu, 17 Aug 2006, 14:15:58 +0200, Mauricio Teixeira (netmask) wrote:
This would be a design error in the first place, I'd say, as rug knows (should know, at least...) about the _whole_ set of transactions, so it should run SuSEconfig just once, which is at the end of the whole set of transactions.
Dunno if this helps others, but apt-get knows about this since quite some time, and it works amazingly well - on i386 (ie. 32-bit) platforms at least. Unfortunately the x86_64 version has a pathname compiled into its shared library (this is on SL-10.0) "libapt-pkg-libc6.3-6.so.2.0.0", which stops running the System::Post:: script(s) (which will call SuSEconfig amongst others): strings -a /usr/lib64/libapt-pkg-libc6.3-6.so.2.0.0 | fgrep /usr/lib /usr/lib64/apt/methods /usr/lib/apt/scripts As you can see the scripts will be looked up in the architecture independent location "/usr/lib/apt" (which is correct FWIW), but they are installed under "/usr/lib64/apt/scripts" unfortunately. Creating a corresponding symbolic link cures that problem: ln -snf ../lib64/apt /usr/lib/apt
No, you don't want to run e.g. "ldconfig" after _each_ RPM you're installing... To be honest, I didn't like SuSEconfig when I first used SUSE Linux (came from Red Hat background...), but I'm not sure what the solution would be that fullfills the same job _and_ with the same efficiency... Cheers. l8er manfred --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, Manfred Hollstein schrieb:
That's just a misunderstanding, rug does the same thing as apt and YaST do (I define installing/updating/removing multiple packages at once a single transaction), but it's still too much and too slow.
No, you don't want to run e.g. "ldconfig" after _each_ RPM you're installing...
That's exactly what happens currently(!): Every package that contains a shared library runs ldconfig in %post and then, at the end of the transaction, the package manager runs it _again_ (ldconfig is not strictly speaking a SuSEconfig module, but run together with SuSEconfig). It's inefficient and it hides bugs (missing ldconfig calls) in the packages. The same for SuSEconfig.fonts: All font packages (should) run it in %post, but at the end of the transaction, the package manager runs it _again_. Maybe the SuSEconfig modules can be divided into different classes: A class of general-purpose modules where running them after every transaction is more efficient and another class of special-purpose modules where running them after installing the individual packages which need it is more efficient. This split could be based on the classes posted by AJ, but it's not exactly the same: I'm thinking of a split based on how often and when a SuSEconfig module is actually needed, not based on how it works internally. For example, nobody would ever make a SuSEconfig module around mkinitrd although rebuilding the initrd is a task which resembles that of certain SuSEconfig modules. At least some of the existing modules can surely be handled like mkinitrd, i.e., run as needed. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, 17 Aug 2006 14:31:31 +0200, Manfred Hollstein wrote:
Hmm, I don't remember having seen a bugzilla entry for this, otherwise I'm pretty shure I'd have fixed it. Care to file a bug so that I get reminded to fix this? Philipp --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Manfred Hollstein (manfred@die-hollsteins.de) [20060817 14:31]:
I've fixed this bug now. The fixed package will hopefully be in the next 10.2 alpha. I've also uploaded fixed packages for 10.0 and 10.1 to ftp.suse.com/pub/people/pth. You'll find them in 10.0-i386, 10.0-x86_64, 10.1-i386 and 10.1-x86_64. Philipp --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
"Mauricio Teixeira (netmask)" <netmask@webset.net> writes:
We already noticed that we have a lot of scripts that are not needed anymore - just historic garbage :-(. Those can be removed. Let's see which scripts we still need and what technical solution is needed. If in the end out of 20 scripts, we keep 2 - and the runtime for these is not anymore 20s on my machine but 1s, then I'm fine ;-) 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, Aug 16, 2006 at 04:44:59PM +0200, Andreas Jaeger wrote:
We'll see... ;-)
Not envolved enough to have a personal opinion about that.
I personally like to see as much as possible as soon as possible moved from /opt away into /usr. But since I am not aware of the GNOME specific compatibility problems that arise from that I could not say anything more specific about the GNOME switch.
Very much appreciated. If you see a specific script problematic to remove you don't have an appropriate solution for you might want to post it here, maybe someone else could provide a solution for this.
I personally liked the mail variant.
Do you have numbers for that?
performance difference is fixed up by kraxel's LOCK prefix runtime patch. Memory usage will be up a bit on UP systems We would lose a
Do you have numbers including the patch?
I suppose the most "famous" drivers with these problems are some of the binary-only drivers anyway.
caused by this, but Fedora has done this before us and they didn't seem to have regretted it so far.
If the numbers don't show a difference that is too hard then I'd definitely like to see that.
I think this is a very good idea because especially for large C++ applications I can often see the linker consuming _extremely_ much CPU time resolving hash conflicts, especially when templates are used in an extensive way.
LDFLAGS="-Wl,-z relro" (see http://people.redhat.com/drepper/nonselsec.pdf)
I currently can't see a disadvantage of using this one thus unless someone could actually see one I'd go the same way. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
Actually we made binutils enable "relro" by default in Factory yesterday or so. So all binaries get it now, unless explicitly using -z norelro. So far it seems not to have adverse effects. (The -z now option, also referenced above, does have performance impacts and will likely just be added to some specific binaries.) Ciao, Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday 16 August 2006 11:44 am, Andreas Jaeger wrote:
I believe that sending mail is still the appropriate action. As for the outdated messages, you can set environment variables (eg: SUSE_UPDATE_FROM=900, SUSE_UPDATE_TO=1020) so that %pre and %post scripts can determine whether a message should be sent. -- James Oakley jfunk@funktronics.ca --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
FYI, this is RFC for the SuSEconfig discussion written by a colleague. WE do not just want to remove it - we also have to figure out to replace it... Andreas SUSEconfig has around 4 classes of different scripts, the first two are the most common cases: a) /etc/sysconfig has two types of data. * data read by rc-scripts and used directly there * data used by SuSEconfig and spread over /etc/* or /var/* The second type is handled by one class of SuSEconfig scripts, called "CLASS-A". Solutions: - extend rc-scripts to do this - extend daemons to read /etc/sysconfig - ... b) directory index caches scripts that keep index files in several directories up to date. The underlying problem is that rpm can not trigger based on directory modification, but that's currently not in sight. In many cases SuSEconfig is just the cheap solution. A related problem is, that if you install 10 packages, you don't want to regenerate these indexes 10 times. Solutions: - call individually in each related package (the "install-info way") - error prone - many modifications to many packages (and over again for any change) - extend usage of these index files to update cache themselves - ... This type will be called CLASS-B below. (some of these have also been moved to cron.daily in the past) c) similar to b but generate other filetypes from installed files, usually hacks for special programs CLASS-C d) set a symlink according to installation CLASS-D (probably easiest for a postinstall solution) (modulename) (packagename) (class) SuSEconfig.automake (automake) CLASS-B SuSEconfig.cjk-latex (cjk-latex) CLASS-C SuSEconfig.desktop-file-utils (desktop-file-utils) CLASS-B SuSEconfig.fonts (fonts-config) CLASS-B (mostly) SuSEconfig.gdm (gdm) CLASS-A SuSEconfig.ghostscript-cjk (ghostscript-cjk) CLASS-A? SuSEconfig.gnome-vfs2 (gnome-vfs2) CLASS-B SuSEconfig.groff (groff) CLASS-A SuSEconfig.gtk2 (gtk2) CLASS-B SuSEconfig.guile (guile) CLASS-B SuSEconfig.icu (icu) CLASS-D SuSEconfig.isdn (i4l-base) CLASS-A SuSEconfig.ispell (ispell) CLASS-A/CLASS-D SuSEconfig.kde (kdebase3-NLD,kdebase3-SuSE) CLASS-A SuSEconfig.kdm3 (kdebase3-NLD,kdebase3-SuSE) CLASS-A SuSEconfig.libxml2 (libxml2) CLASS-B SuSEconfig.lyx-cjk (cjk-lyx) CLASS-B SuSEconfig.mailman (mailman) CLASS-A SuSEconfig.news (aaa_base) CLASS-A SuSEconfig.pango (pango) CLASS-B SuSEconfig.pbs (OpenPBS) CLASS-A SuSEconfig.perl (perl) CLASS-B SuSEconfig.permissions (permissions) CLASS-A (special ...) SuSEconfig.postfix (postfix) CLASS-A SuSEconfig.prelink (prelink) CLASS-B SuSEconfig.scim (scim) CLASS-A SuSEconfig.scpm (scpm) ?? (-> rcscript .. ?) SuSEconfig.scrollkeeper (scrollkeeper) CLASS-B SuSEconfig.sendmail (sendmail) CLASS-A SuSEconfig.susehelp (susehelp) CLASS-A(?) SuSEconfig.syslog-ng (syslog-ng) CLASS-A SuSEconfig.tetex (tetex) CLASS-B SuSEconfig.tuxpaint (tuxpaint) CLASS-C SuSEconfig.wdm (wdm) CLASS-A SuSEconfig.words (words) CLASS-A/CLASS-D SuSEconfig.xdm (xorg-x11) CLASS-A SuSEconfig.xjdic (xjdic-indices) CLASS-B SuSEconfig.xpdf (xpdf-tools) CLASS-B(?) 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 Donnerstag, 17. August 2006 14:06 schrieb Andreas Jaeger:
Perhaps you could also split from another point of view: Class E: scripts, which have to be run immediately after installing/updating a package, so that the software is usable Class F: scripts, which can be run later, too Class E scripts should remain in SuSEconfig (or any successor). Class F scripts could probably be done by cron, or when CPU is idle for x minutes. When changing scripts from SuSEconfg to cron jobs, please consider that the more things will be done by cron jobs, the more users will be frustrated, if the CPU/disk is going crazy. So doing the main work immediately after installing packages is still the best way, I think. -- 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 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I really like this move. I am just concerned that there will not be enough time in the current schedule to complete the entire task.
I agree with this. I think the changes needed should be done at the time. I dislike the running of this script all the time.
I prefer the email notification. I would like to see the few situations where config files change that an email is sent to root.
I think this is a good move. Also I prefer the dropping of UP kernel. I like having things as close to the same as possible. I think the advantages out way the disadvantages. Thanks, - -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFE40qrVtBjDid73eYRAprDAJ46bLlHfX/JSDvacxSr8KV6OLZ8KwCfSCJG wizHHdAl8jkeu8qddmF//kw= =LAhV -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, Am Mittwoch, 16. August 2006 16:44 schrieb Andreas Jaeger:
Will this work?
It depends on some points: - you should give some more background information about the topics - I'll insert some questions regarding this below. - you should mail some days earlier the next time ;-))
What are the advantages and disadvantages of each?
Hmm, what's the reason for this? BTW: Will KDE be moved also?
What's the replacement for config files that are _generated_ by SuSEconfig? (as in: including /etc/sysconfig/foo is impossible for the respective application) -> You won't be able to do this in rpm postinstall scripts or alike ;-) Possible solutions: a) drop the sysconfig files for this applications (opinions about this depend from "good idea, they are simply annoying" up to "keep sysconfig, it's easy to use for basic configuration" depending on whom you ask ;-) b) keep the parts of SuSEconfig that generate config files based on /etc/sysconfig settings OK, that were the (at least for me) unclear parts. Let's continue with the other ones ;-)
IMHO: mail them to root - that's easy to implement and easy to use. Hint: KMail / Evolution should come with the local /var/spool/mail/$user mailbox preconfigured.
* Linker Options and Optimizations [see kernel, s/kernel development/packaging/]
Regards, Christian Boltz -- 1.-4.9.2006: Weinfest in Insheim Pig Slip, Hifi-Delity, AH-Band, Frank Petersen und die Deafen Goblins spielen bei der Landjugend. Mehr Infos: www.Landjugend-Insheim.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Aug 16, 2006 at 06:42:44PM +0200, Christian Boltz wrote:
Well, if you don't have the background information for a specific topic it might not make much sense to give a comment to that topic, right? And btw. there is not a requirement that you give an answer to all open questions in the universe. ;-) Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
Hello, Am Mittwoch, 16. August 2006 20:21 schrieb Robert Schiele:
It depends on the point of view ;-) I prefer to know about the changes in advance - that's much better than whining afterwards if something is broken. Don't get me wrong - there are topics that I won't comment (like compiler options or kernel packages) because I don't know much about them and am not really interested in, too. But when changes in the basesystem (like dropping SuSEconfig) are discussed, it's always good to know what will replace their functionality. A short summary (like in the kernel section of Andreas' mail) would really be useful.
And btw. there is not a requirement that you give an answer to all open questions in the universe. ;-)
42 *eg* Regards, Christian Boltz -- 1.-4.9.2006: Weinfest in Insheim Pig Slip, Hifi-Delity, AH-Band, Frank Petersen und die Deafen Goblins spielen bei der Landjugend. Mehr Infos: www.Landjugend-Insheim.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Wednesday 16 August 2006 18:42 schrieb Christian Boltz:
In general it is a request by the LSB/FHS group.
BTW: Will KDE be moved also?
KDE 3 will not be moved, because this would cause compatibility and update problems. But KDE 4 will be installed to /usr as well later.
c) use /etc/sysconfig direct from runlevel scripts or applications.
not needed, because YaST asks during installation to whom these root mails should get forwarded. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, Am Donnerstag, 17. August 2006 08:12 schrieb Adrian Schröter:
OK, that's a valid reason.
Good idea to do it this way ;-)
Hmm, this way several config files (KDM, Postfix, Apache...) will need to be rebuilt each time the application is started. Unless I miss something, I don't consider this a good idea ;-)
I think you missed my point ;-) Yes, the root mails are forwarded to a user. There's no problem with this. But it isn't obvious for beginners how to retreive these mails. (Advanced users know they have to read /var/spool/mail/username, beginners probably don't.) My proposal: KMail, evolution and Thunderbird [1] should come with the local mailbox account /var/spool/mail/username preconfigured so that system mails will be received "automatically". Regards, Christian Boltz [1] no need in mutt, poeple using it probably know about /var/spool/mail ;-) -- 1.-4.9.2006: Weinfest in Insheim Pig Slip, Hifi-Delity, AH-Band, Frank Petersen und die Deafen Goblins spielen bei der Landjugend. Mehr Infos: www.Landjugend-Insheim.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (18)
-
Adrian Schröter -
Andreas Hanke -
Andreas Jaeger -
Bernhard Walle -
Boyd Lynn Gerber -
Christian Boltz -
Druid -
James Oakley -
jdd -
Manfred Hollstein -
Marcel Hilzinger -
Marcus Meissner -
Marcus Rueckert -
Mauricio Teixeira (netmask) -
Patrick Shanahan -
Philipp Thomas -
Philipp Thomas -
Robert Schiele