[opensuse-factory] RFC: Topics for 2007-04-19 dist meeting
In tomorrow's meeting, we'd like to discuss the following topics. Note these are just brief remarks, if you do not understand what I mean, ask me. Please give me your input - and if you have stuff that we should discuss, please tell us as well. * log entries in .changes file Just a simple "Update to version x.y" is not valid in the packages changelog but happens far too often. Goal: present the changes done to packages to users in a good way and use that for e.g. Release Notes. * Autofs5 instead of autofs4? It was suggested to move from autofs4 to autofs5. * Smaller systems - what can be done? There are many requests for smaller systems. The minimal install is a first step. The BASE project in the build service has cleaned up many dependencies and spec files so that systems might have a smaller footprint. Is there anything else that can be done? * Updating openSUSE: What options do users have for updating from one release to the next one? Which of these will we support? Some current options: - Boot from CD - zypper update - System Update * Update of Printing * NM enabling scripts followup - ntp * Moving languages out of packages followup: The idea is to add to spec file of packages a new rpm macro so that subpackages are created and then related subpackages are repacked for each language in our build system. This way we would get e.g. basesystem-$lang and gnome-$lang packages and those can then be installed. Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Op Wednesday 18 April 2007 20:10:05 schreef Andreas Jaeger:
* log entries in .changes file
Just a simple "Update to version x.y" is not valid in the packages changelog but happens far too often. Goal: present the changes done to packages to users in a good way and use that for e.g. Release Notes.
I can't be in the meeting tomorrow: - How to differentiate between updates to the spec file and the package/project? Or is this not important for the end user? As an example, just recently I did an mass update to the gnome related project (due to the prefix change). At the end this is not important to the end user, but for other packagers it is! However, at the same time I splitted the package into language dependend parts and that's important for the end user. Should there perhaps be 2 changelogs? A project changelog and a spec file changelog? I must admit I'm on side that a package version is sufficient to mention in the spec file, as that all there is that changed. But now that the changelog is presented on the web it is indeed interesting to provide the project changelog for the end user. But in this case it might be sufficient to provide a link to the (official/native) project changelog that is most likely on the web in the rpm changelog... -- Richard Bos We are borrowing the world of our children, It is not inherited from our parents. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Richard Bos <ml@radoeka.nl> writes:
Op Wednesday 18 April 2007 20:10:05 schreef Andreas Jaeger:
* log entries in .changes file
Just a simple "Update to version x.y" is not valid in the packages changelog but happens far too often. Goal: present the changes done to packages to users in a good way and use that for e.g. Release Notes.
I can't be in the meeting tomorrow: - How to differentiate between updates to the spec file and the package/project? Or is this not important for the end user? As an example, just recently I did an mass update to the gnome related project (due to the prefix change). At the end this is not important to the end user, but for other packagers it is! However, at the same time I splitted the package into language dependend parts and that's important for the end user.
Should there perhaps be 2 changelogs? A project changelog and a spec file changelog?
I must admit I'm on side that a package version is sufficient to mention in the spec file, as that all there is that changed. But now that the changelog is presented on the web it is indeed interesting to provide the project changelog for the end user. But in this case it might be sufficient to provide a link to the (official/native) project changelog that is most likely on the web in the rpm changelog...
Yes, well analyzed - these are the challenges and questions, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Hello, on Mittwoch, 18. April 2007, Andreas Jaeger wrote:
* log entries in .changes file
Just a simple "Update to version x.y" is not valid in the packages changelog but happens far too often.
Goal: present the changes done to packages to users in a good way and use that for e.g. Release Notes.
Do you really want to include the full changelog in the specfile? IMHO this would bee too much. (What about including NEWS instead of ChangeLog?)
* Updating openSUSE:
What options do users have for updating from one release to the next one? Which of these will we support? Some current options: - Boot from CD - zypper update - System Update
If it isn't too difficult, I would like to have a supported way to upgrade a running system. Please offer both zypper (for command-line fans) and YaST2 System Update (for more mouse-orientated users).
* Moving languages out of packages followup:
The idea is to add to spec file of packages a new rpm macro so that subpackages are created and then related subpackages are repacked for each language in our build system. This way we would get e.g. basesystem-$lang and gnome-$lang packages and those can then be installed.
Good idea, I don't understand most of the languages anyway. But please make sure the package overhead isn't larger than the files it contains... In case of very small $lang packages, don't split off the languages. It might be a good idea to add all language provides to the main package in this case for easier dependency solving ("_each_ package requires the $lang package the user wants"). Regards, Christian Boltz -- If Microsoft is the solution, I want my problems back. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Christian Boltz <opensuse@cboltz.de> [Apr 19. 2007 01:13]:
* Updating openSUSE:
What options do users have for updating from one release to the next one? Which of these will we support? Some current options: - Boot from CD - zypper update - System Update
If it isn't too difficult, I would like to have a supported way to upgrade a running system. Please offer both zypper (for command-line fans) and YaST2 System Update (for more mouse-orientated users).
A lot of developers here do this, so its not a technical problem per se. However, the QA and testing effort is quite huge and getting it 'fool proof' might be a huge task. Until now, we didn't get sufficient customer request for this to justify the effort. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Klaus Kaempf escribió:
A lot of developers here do this, so its not a technical problem per se.
I have been upgrading my factory copy with zypper since early alphas and seems it can manage upgrades preyy much fine except for 1. it is slow ( well, that's a general problem) 2. it emits "scary"(for users) errors and then seems to try with --nodeps and continue anyway. 3. it emits equally "scary" "invalid object" messages (wth means in this context..dunno ;) ) 4. Y and N dialogs are still messed up horrible. 5. it failed to upgrade on the libbz2 split ( as well smart, yast do anyway..;) )
However, the QA and testing effort is quite huge and getting it 'fool proof' might be a huge task.
yes, it is probably very, very hard to get right.
Until now, we didn't get sufficient customer request for this to justify the effort.
I would like to see a) upgrade with zypper b) upgrade with CD fully supported.
"Cristian Rodriguez R." <judas_iscariote@shorewall.net> writes:
Klaus Kaempf escribió:
A lot of developers here do this, so its not a technical problem per se.
I have been upgrading my factory copy with zypper since early alphas and seems it can manage upgrades preyy much fine except for
1. it is slow ( well, that's a general problem)
2. it emits "scary"(for users) errors and then seems to try with --nodeps and continue anyway.
Please file a bugreport.
3. it emits equally "scary" "invalid object" messages (wth means in this context..dunno ;) )
Please file a bugreport.
4. Y and N dialogs are still messed up horrible.
Please file a bugreport.
5. it failed to upgrade on the libbz2 split ( as well smart, yast do anyway..;) )
Yeah, I think that was a bug elsewhere :-( Please report any problems with zypper, it should really become a good tool that does not scare anyone! Thanks!
However, the QA and testing effort is quite huge and getting it 'fool proof' might be a huge task.
yes, it is probably very, very hard to get right.
Until now, we didn't get sufficient customer request for this to justify the effort.
I would like to see a) upgrade with zypper b) upgrade with CD fully supported.
Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger escribió:
2. it emits "scary"(for users) errors and then seems to try with --nodeps and continue anyway.
Please file a bugreport.
filled long way ago, noticed in https://bugzilla.novell.com/show_bug.cgi?id=216042
3. it emits equally "scary" "invalid object" messages (wth means in this context..dunno ;) )
Please file a bugreport.
idem filled 2006-10-27 https://bugzilla.novell.com/show_bug.cgi?id=216042
4. Y and N dialogs are still messed up horrible.
Please file a bugreport.
already filled, dont have the bug report number handly atm though.
Please report any problems with zypper,
doh.:) that's what im doing all the time :-)
it should really become a good
it is already good but slow and have some glitches and bad error messages, but it fully functional. ;-)
tool that does not scare anyone!
it dont scare me :-) but some users has asked me "WTF is this", hence we have a problem ;-)
* Cristian Rodriguez R. <judas_iscariote@shorewall.net> [Apr 19. 2007 11:23]:
it should really become a good
it is already good but slow and have some glitches and bad error messages, but it fully functional. ;-)
Speed is being worked on. See zypp-devel@opensuse.org ;-) Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Here're the minutes from the meeting. * log entries in .changes file Just a simple "Update to version x.y" is not valid but happens far too often. .NEWS file for major changes? Goal: present the changes done to packages to users in a good way We have not found any appropriate solution. We will continue with the current practice: - packages need to have valid changes entries - a version update should include the highlight of the changes and not just "Update to version x.y" * Autofs5 instead of autofs4? autofs5 is a complete rewrite, moving autofs from kernel to userland. It complies with other technologies, e.g. automounter from Sun, and therefore solves many open feature requests. Existing setup will continue to work. We decided to move forward with the switch. * Smaller systems - what can be done? Goal: A system with 128 MB of space. Challenges are especially: * Languages and localization * documentation - > some packages have documentation split up already * theming -> some packages will be split up so that only one theme is in a package. For languages we discussed previously already the following and will implement this now: The idea is to add to spec file of packages a new rpm macro so that subpackages are created and then related subpackages are repacked for each language in our build system. This way we would get e.g. basesystem-$lang and gnome-$lang packages and those can then be installed. To be continued next time. * Updating openSUSE: What options do we have - what will we advocate? - Boot from CD? - zypper update? - System Update? "System Update" is more about bringing the system in a consistent state. It did not work for us with our SLE service packs. Many developers and the community like to have an easy way to update their system to the latest and greatest version of the distribution - without rebooting. Currently there's no algorithm in place that handles different repositories correctly, just consider what should happen in the case of kernel and kmp package update with different repositories: * Update new kmp but keep old kernel * Update kernel and keep old kmp * Update kmp and kernel We need to define as well which repository is upstream, e.g. for moving from 10.2 to 10.3. Officially supported is currently only the system update from the installation system (after booting from CD). Update from a running system would need extra QA (this is currently not supported and not tested). Users understand that this does not work from 10.2 to 10.3 but not if they update daily or from e.g. Alpha2 to Alpha3. But both scenario are the same challenge. The underlying problem is package splits, package renames and package drops. This might need further policies which would lead to e.g. two perl versions installed in parallel for the transition. The challenge is not the leaf package but the core system. Note: Patterns are not updated with a zypper update. To achieve updating in a running system, we would need to enforce better policies for package splits, renames and drops and need to fix zypper to handle all this properly. This would still be an expert option since it might need user interaction for some choices. AI: aj to discuss further in smaller round whether what needs to be done. * TeXLive switch We have TeXLive now in the distribution but packages still use the old teTeX packages for building. Every packager should change the requires of their packages so that we can soon obsolete the old teTeX packages. We also have to get packages like cjk-latex, jadetex and xmltex working with the new TeXLive system. AI: send email to opensuse-packaging to inform packager what needs to be done for their packages. Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger <aj@suse.de> writes:
* Autofs5 instead of autofs4?
autofs5 is a complete rewrite,
moving autofs from kernel to userland.
Uhm, I cannot remember having said that ;-) autofs5 of course keeps the two component structure: User space daemon and kernel module. The Version 5 is related only to the user space daemon, the autofs4 kernel module is still required.
It complies with other technologies, e.g. automounter from Sun, and therefore solves many open feature requests. Existing setup will continue to work.
Default setup will work out of the box. I forgot to mention that current Suse quirks (separating maptype and map-name by space instead of colon) which do not comply with the official configuration syntax of master maps will not work. But this is minor and will be documented. Matthias --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Matthias Koenig <mkoenig@suse.de> writes:
Andreas Jaeger <aj@suse.de> writes:
* Autofs5 instead of autofs4?
autofs5 is a complete rewrite,
moving autofs from kernel to userland.
Uhm, I cannot remember having said that ;-)
That's what I understood - which means I did not understand you completely ;-(
autofs5 of course keeps the two component structure: User space daemon and kernel module. The Version 5 is related only to the user space daemon, the autofs4 kernel module is still required.
Thanks for the clarification.
It complies with other technologies, e.g. automounter from Sun, and therefore solves many open feature requests. Existing setup will continue to work.
Default setup will work out of the box. I forgot to mention that current Suse quirks (separating maptype and map-name by space instead of colon) which do not comply with the official configuration syntax of master maps will not work. But this is minor and will be documented.
Hope that this will not cause problems, let's go ahead, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
Challenges are especially: * Languages and localization
think at a small enhancement: langage is not as much a goal than keyboard. I'm french. I read english very well, but using QWERTY layout on AZERTY keyboard is always a problem (specially with punctuation characters). So having localized keyboard should be a premium, up to the rescue system. jdd -- http://www.dodin.net Lucien Dodin, inventeur http://lucien.dodin.net/index.shtml --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
jdd <jdd@dodin.org> writes:
Andreas Jaeger wrote:
Challenges are especially: * Languages and localization
think at a small enhancement: langage is not as much a goal than keyboard.
I'm french. I read english very well, but using QWERTY layout on AZERTY keyboard is always a problem (specially with punctuation characters).
So having localized keyboard should be a premium, up to the rescue system.
What are you missing *today*? If you change at the linuxrc boot the language, your keyboard is setup correctly - isn't it? Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
jdd <jdd@dodin.org> writes:
Andreas Jaeger wrote:
Challenges are especially: * Languages and localization think at a small enhancement: langage is not as much a goal than keyboard.
I'm french. I read english very well, but using QWERTY layout on AZERTY keyboard is always a problem (specially with punctuation characters).
So having localized keyboard should be a premium, up to the rescue system.
What are you missing *today*? If you change at the linuxrc boot the language, your keyboard is setup correctly - isn't it?
Andreas
sure, but if there is a question about localization, I only suggest localized keyboard is the most important, much more than langage (and the rescue system have no kind of localization) jdd -- http://www.dodin.net Cécile, esthéticienne à Montpellier (à domicile) http://gourmandises.orangeblog.fr/ --------------------------------------------------------------------- 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 Andreas Jaeger schreef:
jdd <jdd@dodin.org> writes:
Andreas Jaeger wrote:
Challenges are especially: * Languages and localization think at a small enhancement: langage is not as much a goal than keyboard.
I'm french. I read english very well, but using QWERTY layout on AZERTY keyboard is always a problem (specially with punctuation characters).
So having localized keyboard should be a premium, up to the rescue system.
What are you missing *today*? If you change at the linuxrc boot the language, your keyboard is setup correctly - isn't it?
As I recal correct one can choose the keybord language at set-up.......(seperate from OS lang..)
Andreas
- -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.2-34-default x86_64 Huidige gebruiker: monkey9@tribal-sfn2 Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 "release 45.2" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGKPoUX5/X5X6LpDgRAsB7AKCsnCTxNCPiHyaSUtvnLI395wZ6lgCglnHe vKxBkrSyOL+Ut1W+R6c+FEk= =ZfX/ -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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 Klaus Kaempf schreef:
* Christian Boltz <opensuse@cboltz.de> [Apr 19. 2007 01:13]:
* Updating openSUSE:
What options do users have for updating from one release to the next one? Which of these will we support? Some current options: - Boot from CD - zypper update - System Update If it isn't too difficult, I would like to have a supported way to upgrade a running system. Please offer both zypper (for command-line fans) and YaST2 System Update (for more mouse-orientated users).
I must say that i very convieniently upgraded the system with yast on both 32 and 64 Bit platforms, from 102B1 upto 'retail'. No problem at all...(if one uses the factory installs and no 'packagers paradise' updates..(no offense meanth to anybody;-) The factory installs are stable as hell on the machines i have and am using. With a fully 'costumized' system, i have noticed that they break, when nessesary pkgs are not yet in the repos. The nessary knowledge for 'new' users will be to have their /home on a seperate partition, which can be mounted, if wanted, to have back all their custom config. (this is the far greatest advantage against MSW, because of the difference of importance: System?, or User? To me it is obvious that the user is the most important, because he/she is the one who uses the System. To MS the system is, so the user has to install everything all over again, which can be 'horror' in some cases, and this will prevent people from upgrading: the fear of loosing all they have, or the uncertainty to have forgotten to back-up something they need afterwards.... I think, most important, is to take away this fear for upgrading, by simplifying the way to 'list' all pkgs and deps, installed on a system, and insert this list into an installer, such as Yast fi, so the 'custom' users-system, can be established, if the user wants, when all repos are updated. (versions and deps can be solved the usual way) Who knows *all* 'obsolete', or 'replaced' pkgs anyway? So I think this advantage must be sort of 'flagpole' for the better use of Linux, because it is by far the better philosophy...
A lot of developers here do this, so its not a technical problem per se.
However, the QA and testing effort is quite huge and getting it 'fool proof' might be a huge task.
Until now, we didn't get sufficient customer request for this to justify the effort.
Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
- -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.2-34-default x86_64 Huidige gebruiker: monkey9@tribal-sfn2 Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 "release 45.2" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGJ0HDX5/X5X6LpDgRAr5aAKC1lvduNThuxo4l7CufZs8JXopZKwCfUHJg upLC9OIwJwB45V/O1JKonZE= =PNb1 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, on Donnerstag, 19. April 2007, Klaus Kaempf wrote:
* Christian Boltz <opensuse@cboltz.de> [Apr 19. 2007 01:13]:
If it isn't too difficult, I would like to have a supported way to upgrade a running system. Please offer both zypper (for command-line fans) and YaST2 System Update (for more mouse-orientated users).
A lot of developers here do this, so its not a technical problem per se.
However, the QA and testing effort is quite huge and getting it 'fool proof' might be a huge task.
Yes, understandable. However, I would happily test it instead of having to wait for every beta to install - which means at least 2 hours "downtime" on my full-blown system... (yes, maybe I should uninstall some stuff.)
Until now, we didn't get sufficient customer request for this to justify the effort.
Wrong answer ;-) It happened more than once that someone tried to update his system with "YaST2 System Update" which resulted in wrong YOU-sources (from the old system), so everybody was warned not to use this YaST module. IIRC, there's even a SDB article about it which states that you should never upgrade a running system, but always boot the install CD to upgrade the system. And now you are wondering that this is rarely used and/or requested... Regards, Christian Boltz -- Designpreise sind wie Modenschauen: Was da beklatscht wird, ist interessant, Neu, aufregend und definitiv nicht tragbar im Alltag. [Ratti in suse-linux] --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Andreas Jaeger escribió:
* log entries in .changes file
Just a simple "Update to version x.y" is not valid in the packages changelog but happens far too often.
Goal: present the changes done to packages to users in a good way and use that for e.g. Release Notes.
1. The average user does not read package changelogs at all, probably they only read "patches" changelog if at all. 2. software provides NEWS and Changelog either included in the package or on the internet by their own. so it is absolutely pointeless to duplicate effort already done. 3. we provides **packages** of certain software, so the package changelog should include changes to the package **itself**. as stated previously there are counteless ways to retrieve software changes.(some poeple is even subscribed to announce lists of several software they use) 4. I have been told this is proposed to make autobuild people 's life easier,I wonder if autobuild people does not have a internet connection or a terminal to look at the NEWS file, the package can contain a link to the changelog. 5. Thsi unnecesarilly clutter changelog files with information that users **wont read**. 6. this cause unnecesarry work for packagers with no gain to users. In short, I would like to know the real rationale beahind this as I currently can see a single reason to do what is proposed.
"Cristian Rodriguez R." <judas_iscariote@shorewall.net> writes:
Andreas Jaeger escribió:
* log entries in .changes file
Just a simple "Update to version x.y" is not valid in the packages changelog but happens far too often.
Goal: present the changes done to packages to users in a good way and use that for e.g. Release Notes.
1. The average user does not read package changelogs at all, probably they only read "patches" changelog if at all.
2. software provides NEWS and Changelog either included in the package or on the internet by their own. so it is absolutely pointeless to duplicate effort already done.
3. we provides **packages** of certain software, so the package changelog should include changes to the package **itself**. as stated previously there are counteless ways to retrieve software changes.(some poeple is even subscribed to announce lists of several software they use)
4. I have been told this is proposed to make autobuild people 's life easier,I wonder if autobuild people does not have a internet connection or a terminal to look at the NEWS file, the package can contain a link to the changelog.
5. Thsi unnecesarilly clutter changelog files with information that users **wont read**.
6. this cause unnecesarry work for packagers with no gain to users.
In short, I would like to know the real rationale beahind this as I currently can see a single reason to do what is proposed.
I'm under the impression that end users want to know in an easy way why the version update happened - and not only that it happened. We currently copy some of that information also around, e.g. add it to some announcements in a distilled way. I would like to see this improved, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger escribió:
I'm under the impression that end users want to know in an easy way why the version update happened - and not only that it happened.
1. for patches this is already done in the patch changelog or in the "suse security announce "newsletter" " 2. if you are thinking about an overall "opensuse proyect changelog" ..well. that can be done asking the mantainers for meaniful. short, revelant and concise changelog **ONCE** just after the feature and version freeze starts, providing this way good information to users without all the permanent hassle for packagers that IMHO makes very lilte sense.
* Cristian Rodriguez R. <judas_iscariote@shorewall.net> [Apr 19. 2007 10:55]:
Andreas Jaeger escribió:
I'm under the impression that end users want to know in an easy way why the version update happened - and not only that it happened.
1. for patches this is already done in the patch changelog or in the "suse security announce "newsletter" "
2. if you are thinking about an overall "opensuse proyect changelog" ..well. that can be done asking the mantainers for meaniful. short, revelant and concise changelog **ONCE** just after the feature and version freeze starts, providing this way good information to users without all the permanent hassle for packagers that IMHO makes very lilte sense.
There was also the idea of an RSS feed accompanying the update channel with human readable information when Novell started the customer center last year. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu 19 Apr 2007 06:10:05 NZST +1200, Andreas Jaeger wrote:
In tomorrow's meeting, we'd like to discuss the following topics. Note these are just brief remarks, if you do not understand what I mean, ask me. Please give me your input - and if you have stuff that we should discuss, please tell us as well.
* Smaller systems - what can be done?
The smallest hard disk in the shop is 40GB. Whether a base installs puts 200MB or 700MB on that disk is not something I care about. The problem is elsewhere. For a company I needed to organise automatic production installation of Linux on a mini-small PC used for control and monitoring purposes. Resources are limited, except for oodles of blanknesss on spinning metal. Specifically, there's 128MB RAM. I'd look a fool if I went to management to say I'd like to install opensuse instead of debian, would they pay for double the memory. The problem is the installer memory footprint, not the disk space. No I can NOT enable swap!! * Home environment, 1 fast machine, 1 old box used as X11 terminal with xdmcp login to the fast one. Now the user on slow has a USB stick. Plugging that into slowbox is pointless. Plugging it into fastbox might work - but depending on who logged in first and who knows what else, *all* USB devices plugged into fastbox are either all owned by slowuser or all owned by fastuser. Can this situation be improved? Would "you only need one new computer and a few old cheap ones for your family's computing needs" be a selling point? * USB, and pretty much all hotplug, device mount options suck hamsters with straws. In a galactically big way. That is, there's no way to change them. Not even with a degree in computer science (ok so hacking the source(TM) should do it). This is unsatisfactory. No wait, THIS SUCKS. Can this be improved? * I find that I need to share files with family members all the time. Dito in return. If someone forgets to explicitly set group ownership and permissions on a file (daddy, what's that anyway?), the others can't read it. Ok it's a basic *ix problem for the computer scientists. However, family doesn't care, they Just Want It To Work(TM). Are there solutions? This case must be pretty common. No I don't count "stick it on a stick, because it has M$oft semantics ie no owners or permissions" as a solution. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Volker Kuhlmann wrote:
* USB, and pretty much all hotplug, device mount options suck hamsters with straws. In a galactically big way. That is, there's no way to change them.
Huh? With the hal based mount users can do that with just a few mouse clicks.
* I find that I need to share files with family members all the time. Dito in return. If someone forgets to explicitly set group ownership and permissions on a file (daddy, what's that anyway?), the others can't read it. Ok it's a basic *ix problem for the computer scientists. However, family doesn't care, they Just Want It To Work(TM). Are there solutions? This case must be pretty common. No I don't count "stick it on a stick, because it has M$oft semantics ie no owners or permissions" as a solution.
SUSE Linux uses a default umask of 0022 and creates home directories with mode 0755. So it does just work (TM). cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Apr 20, 2007 at 10:53:50AM +0200, Ludwig Nussel wrote:
Volker Kuhlmann wrote:
* USB, and pretty much all hotplug, device mount options suck hamsters with straws. In a galactically big way. That is, there's no way to change them.
Huh? With the hal based mount users can do that with just a few mouse clicks.
I think the problem that annoys most system administrators here is not using some fancy tools but understanding (and thus having control over) what really happens. Unfortunately the documentation situation with hal and related tools is pretty bad, although this is not a specific problem of openSUSE. The problem here is similar to the Windows registry problem. The reason why people many people don't like the Windows registry system is that they are frightened by seeing a large amount of information most of which they don't understand. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
On Fri 20 Apr 2007 20:53:50 NZST +1200, Ludwig Nussel wrote:
SUSE Linux uses a default umask of 0022 and creates home directories with mode 0755. So it does just work (TM).
No, I do not view no access control as solution either. What I had in mind was more like any files copied to or created in directory X would be accessible by all users belonging to group Y. Btw the desktop icons properties trick doesn't change the uid and therefore doesn't help if <whatsit> decided to mount it as user joe when it's my stick and I'm ben. The problem with the ambiguous uid also arises when switching desktops, ie when further users create gui logins on consoles 8, 9... Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 20 April 2007 10:26:29 Volker Kuhlmann wrote:
* USB, and pretty much all hotplug, device mount options suck hamsters with straws. In a galactically big way. That is, there's no way to change them. Not even with a degree in computer science (ok so hacking the source(TM) should do it). This is unsatisfactory. No wait, THIS SUCKS. Can this be improved?
right click in the icon of the device and select "properties..." there you can change mount path, and other stuff. Also, even if you can change the mount options, stuff like the mount path is not really worth to change, as you always have /dev/disk/by-id and /dev/disk/by-uuid to identify a device if you want to mount it yourself (from a backup script, for example ) Duncan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri 20 Apr 2007 21:55:46 NZST +1200, Duncan Mac-Vicar Prett wrote:
right click in the icon of the device and select "properties..." there you can change mount path, and other stuff.
Thanks, didn't know that. And it remembers devices. Can't change gid though. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (12)
-
Andreas Jaeger -
Christian Boltz -
Cristian Rodriguez R. -
Duncan Mac-Vicar Prett -
jdd -
Klaus Kaempf -
Ludwig Nussel -
M9. -
Matthias Koenig -
Richard Bos -
Robert Schiele -
Volker Kuhlmann