[opensuse-packaging] Proposal: Any "rm" in .spec %install must be commented
Hallo. I have just notified, that many people "fix" (i. e. break) their packages to pass QA checks by removing required files instead of fixing them, i. e. removing .desktop files instead of installing icon or fixing Categories, removing gconf schemas instead of correct installation. So I propose: Each removal in %install phase must be correctly commented (i. e. why these files are obsolete or why they are installed by mistake), otherwise package will not be checked-in. Please discuss on opensuse-packaging@opensuse.org See also https://bugzilla.novell.com/show_bug.cgi?id=254868 -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, On Mar 15 11:45 Stanislav Brabec wrote (shortened):
So I propose: Each removal in %install phase must be correctly commented
I suggest even more: Everything in the spec file where it is not totally obvious what it does and why it is done must be commented so that an external person understands what it does and why it is done. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Johannes Meixner wrote:
Hello,
On Mar 15 11:45 Stanislav Brabec wrote (shortened):
So I propose: Each removal in %install phase must be correctly commented
Please explain to me: which maintainer is having so much time?
I suggest even more: Everything in the spec file where it is not totally obvious what it does and why it is done must be commented so that an external person understands what it does and why it is done.
Yes, and please add a short and a longer abstract of all included documentation in the specfile too. And comment out, why you didn't add a FAQ too, if there is none included. Don't forget to mention: Please explain in long comments why your %name differs from the main project name. Regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: Klaus.Singvogel@SuSE.de 90409 Nuernberg Phone: +49 (0) 911 740530 Germany GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Thu, 15 Mar 2007, Klaus Singvogel wrote:
On Mar 15 11:45 Stanislav Brabec wrote (shortened):
So I propose: Each removal in %install phase must be correctly commented
Please explain to me: which maintainer is having so much time?
That's part of maintaining a package. If there's no time for writing a short comment for _why_ something is done the way it's done, then it very probable that the maintainer has too many packages.
I suggest even more: Everything in the spec file where it is not totally obvious what it does and why it is done must be commented so that an external person understands what it does and why it is done.
Yes, and please add a short and a longer abstract of all included documentation in the specfile too. And comment out, why you didn't add a FAQ too, if there is none included.
Don't forget to mention: Please explain in long comments why your %name differs from the main project name.
Actually there's no need at all to be sarcastic about this. Comments are one of the most important things, especially about unusual happenings. My code often contains much more comments than code at core parts. Code isn't different from .spec files in that regard. So, _if_ there's a good reason why your %name differs from the main project name, I fully would expect a comment explaining that reason, if it's not totally obvious to anyone reading the spec file. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, On Mar 15 14:35 Klaus Singvogel wrote (shortened):
Please explain to me: which maintainer is having so much time?
I do not have the time to write no comments! Reason: When I work some time later again on the package I might perhaps not remember every detail why I did what and then my comments save my time. By the way 1: It is the same idea as with the poor hunter who cannot afford to have a cheap gun. By the way 2: How I "like" it when others change my spec files without a meaningful comment in the spec file what was done and why because it wastes my time when I must find out from a meaningless one line comment in the changes file what actually had happened (therefore I carefully watch the autobuld check-in mails). By the way 3: Perhaps I should buy a solid gun? ;-) Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex PS: To avoid misunderstandings: Klaus never changed my spec files. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Johannes Meixner wrote:
I do not have the time to write no comments!
Reason: When I work some time later again on the package I might perhaps not remember every detail why I did what and then my comments save my time.
So, you're telling us, that because someone might not remember (or understand) an obvious removal, any packager needs to comment in future any removal, even the obvious ones? Come on... It's not just about remembering, it's even about understanding. So, is this rule introduction "any removal needs a mandatory comment in future" an advantage or a hindrance? I think no need of such an rule is the better way, because then there is even no rule to hide important comments through overloading the specfile with non-important ones. I think every packager should still be able to decide on his own if it is necessary to have a comment for an "rm" or not. Programing obvious things without a need to comment is sometimes an advantage. There should be no such automatic testing. Regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: Klaus.Singvogel@SuSE.de 90409 Nuernberg Phone: +49 (0) 911 740530 Germany GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Thu, 15 Mar 2007, Klaus Singvogel wrote:
So, you're telling us, that because someone might not remember (or understand) an obvious removal, any packager needs to comment in future any removal, even the obvious ones? Come on...
When it's obvious it needs no comment (just that, as already said here, obviousness is a difficult measure).
So, is this rule introduction "any removal needs a mandatory comment in future" an advantage or a hindrance?
It would be a hindrance, because it's too absolute. I'm not in favor of such rule.
I think every packager should still be able to decide on his own if it is necessary to have a comment for an "rm" or not.
I think it wouldn't hurt to have reviewers (the checkin team) also being able to demand comments. They would apply common sense, and be done with it.
Programing obvious things without a need to comment is sometimes an advantage.
There should be no such automatic testing.
I agree, there should neither be atomatic metric measurement, or even hard policies for comments. Humans need to look over it and decide if it's "not enough" or "enough" comments, mostly from the guts based on experience. Everything else will only cause uproar, and useless comments being written for the sake of fulfilling the policy. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Thu, 15 Mar 2007, Michael Matz wrote:
When it's obvious it needs no comment (just that, as already said here, obviousness is a difficult measure).
I agree that commenting everything is inappropriate and I also don't think that making comments mandatory is practicible, but good comments can prevent re-introduction of already fixed bugs. This is not academic stuff, such things did already happen. Example: NetworkManager was compiled without libnotify support in the past. This looks very much like an unintentionally forgotten feature (=bug) and has therefore been added again, but removing it was intentional because the notification popups were considered useless. A short comment, added from the beginning on, could have prevented this. Another similarly strange habit is turning spec file commands into comments without adding a real comment in the same place. For example, something like: #%patch -p1 In such a case it is totally unclear whether the patch should be applied or not. Maybe the patch is unwanted, so it should be removed completely, otherwise someone who doesn't know what it is will add it back sooner or later. Or maybe the patch is old and does not apply any more, but is still wanted and needs to be redone. This is also a real world case, it already happened with a wrong patch in the cairo package. The patch came back and it had to be discussed *again* why it is wrong. Everything could be so much easier by just writing: #This fixes bug <X>, but is disabled because it introduces bug <Y> #%patch -p1 #This does not apply any more and needs to be updated #%patch -p1 #This is disabled until bug <whatever> is fixed #%patch -p1 Or reversed: #This is a bad workaround, remove when bug <whatever> is fixed properly %patch -p1 Andreas Hanke -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mar 15, 07 17:22:18 +0100, andreas.hanke@gmx-topmail.de wrote:
Hi,
On Thu, 15 Mar 2007, Michael Matz wrote:
When it's obvious it needs no comment (just that, as already said here, obviousness is a difficult measure).
I agree that commenting everything is inappropriate and I also don't think that making comments mandatory is practicible, but good comments can prevent re-introduction of already fixed bugs.
Good point. Mandatory comments are counter productive. If comments are mandatory, they will be more often at the bullshit end of the spectrum than not. With a high noise level around it, even the good comments become useless. So -- let us fight against those comments, that repeat just the obvious. cheers, Jw. -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de wide open suse_/ _---|____________\/ \ | 0911 74053-508 (tm)__/ (____/ /\ (/) | __________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi,
With a high noise level around it, even the good comments become useless. So -- let us fight against those comments, that repeat just the obvious.
But please don't exaggerate and continue adding good comments ;-) Yet another real-world example: https://bugzilla.novell.com/show_bug.cgi?id=238090 Useless and harmful/buggy .desktop file that must be removed, but without a comment, I'm pretty sure it would sooner or later come back when someone removes the removal. Andreas Hanke -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Thu, 2007-03-15 at 18:17 +0100, Juergen Weigert wrote:
Good point. Mandatory comments are counter productive.
If comments are mandatory, they will be more often at the bullshit end of the spectrum than not. With a high noise level around it, even the good comments become useless. So -- let us fight against those comments, that repeat just the obvious.
To me, this whole discussion highlights the necessity of having a revision control system underlying a build system, at least for things like spec files. If the spec file itself doesn't have a comment, or has a confusing one, you would hope that the commit message does. Failing that, you at least know who made the change and when, so you can confront them. :) Plus you'll be able to narrow down when the problem was introduced and revert only that single part. Joe --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 2007-03-15 13:39:55 -0400, Joe Shaw wrote:
On Thu, 2007-03-15 at 18:17 +0100, Juergen Weigert wrote:
Good point. Mandatory comments are counter productive.
If comments are mandatory, they will be more often at the bullshit end of the spectrum than not. With a high noise level around it, even the good comments become useless. So -- let us fight against those comments, that repeat just the obvious.
To me, this whole discussion highlights the necessity of having a revision control system underlying a build system, at least for things like spec files.
If the spec file itself doesn't have a comment, or has a confusing one, you would hope that the commit message does. Failing that, you at least know who made the change and when, so you can confront them. :) Plus you'll be able to narrow down when the problem was introduced and revert only that single part.
the rpm changelog/changes file is meant for stuff like that ... but you often cant track changes entries to lines. thats where a local comment comes into play. you would, maybe even should, do the same with vcs controlled file. last but not least both, our internal system and the buildservice save all revisions of a package. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mar 15, 07 13:39:55 -0400, Joe Shaw wrote:
Hi,
On Thu, 2007-03-15 at 18:17 +0100, Juergen Weigert wrote:
Good point. Mandatory comments are counter productive.
If comments are mandatory, they will be more often at the bullshit end of the spectrum than not. With a high noise level around it, even the good comments become useless. So -- let us fight against those comments, that repeat just the obvious.
To me, this whole discussion highlights the necessity of having a revision control system underlying a build system, at least for things like spec files.
The revision control system that we have under autobuild is an essential feature. It presents us with all the who, when, what history information needed to track down issues. My point is: Mechanisms to ensure good quality comments are all nontrivial.
If the spec file itself doesn't have a comment, or has a confusing one, you would hope that the commit message does. Failing that, you at least know who made the change and when, so you can confront them. :) Plus you'll be able to narrow down when the problem was introduced and revert only that single part.
Correct. And we would not want to do without these mechanisms. Anyway, I do not see, what the benefits of additional commit log messages could be. Increased quantity of mandatory comment fields usually degrades quality. cheers, Jw. -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de wide open suse_/ _---|____________\/ \ | 0911 74053-508 (tm)__/ (____/ /\ (/) | __________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mar 15, 07 14:21:22 +0100, Johannes Meixner wrote:
Hello,
On Mar 15 11:45 Stanislav Brabec wrote (shortened):
So I propose: Each removal in %install phase must be correctly commented
I suggest even more: Everything in the spec file where it is not totally obvious what it does and why it is done must be commented so that an external person understands what it does and why it is done.
The concept of 'totally obvious' is an illusion. Especially while writing code, a writer's perception of obviousness is distorted. I use this as a rule of thumb: Whenever I read my own code a second time, and have to think about a line for more than a split second, I put a comment next to it with the results of my analysis. After some iterations, such comments tend to become pretty useful, and they come at no extra cost. cheers, Jw. -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de wide open suse_/ _---|____________\/ \ | 0911 74053-508 (tm)__/ (____/ /\ (/) | __________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, On Mar 15 14:58 Juergen Weigert wrote (shortened):
The concept of 'totally obvious' is an illusion.
You got the idea because:
I use this as a rule of thumb: Whenever I read my own code a second time, and have to think about a line for more than a split second, I put a comment next to it with the results of my analysis.
I use a bit different rule of thumb: Whenever I write whatever kind of code and have to think about it for more than a few seconds, I put a meaningful comment next to it about what I had in mind (usually just a hint to point me into the right direction when I read the code later again). For example: NOT: # remove icon rm icon.png BUT: # there is a system default icon rm icon.png Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, 15 Mar 2007, Stanislav Brabec wrote:
Hallo.
I have just notified, that many people "fix" (i. e. break) their packages to pass QA checks by removing required files instead of fixing them, i. e. removing .desktop files instead of installing icon or fixing Categories, removing gconf schemas instead of correct installation.
So I propose:
Each removal in %install phase must be correctly commented (i. e. why these files are obsolete or why they are installed by mistake), otherwise package will not be checked-in.
If they "fix" or "break" their package what does it help to add a comment?
It looks like you are proposing that package maintainers have a clue ;)
I also don't see why removals in %install are somehow special -- either
everything non-obvious to the autobuild people doing the check-in should
be rejected without comments clarifying it or nothing. If you'd count
check-in as a sort of first-level QA.
Richard.
--
Richard Guenther
On Mar 15, 07 14:53:50 +0100, Richard Guenther wrote:
On Thu, 15 Mar 2007, Stanislav Brabec wrote:
Hallo.
I have just notified, that many people "fix" (i. e. break) their packages to pass QA checks by removing required files instead of fixing them, i. e. removing .desktop files instead of installing icon or fixing Categories, removing gconf schemas instead of correct installation.
If they "fix" or "break" their package what does it help to add a comment? It looks like you are proposing that package maintainers have a clue ;)
No. Especially cluelessness needs documentation. Example: "# I don't care about this gconf stuff. Remove seems to help." This is a very useful comment. It pinpoints the actual problem that the maintainer has. cheers, Jw. -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de wide open suse_/ _---|____________\/ \ | 0911 74053-508 (tm)__/ (____/ /\ (/) | __________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Thursday 15 March 2007 schrieb Juergen Weigert:
On Mar 15, 07 14:53:50 +0100, Richard Guenther wrote:
On Thu, 15 Mar 2007, Stanislav Brabec wrote:
Hallo.
I have just notified, that many people "fix" (i. e. break) their packages to pass QA checks by removing required files instead of fixing them, i. e. removing .desktop files instead of installing icon or fixing Categories, removing gconf schemas instead of correct installation.
If they "fix" or "break" their package what does it help to add a comment? It looks like you are proposing that package maintainers have a clue ;)
No. Especially cluelessness needs documentation. Example: "# I don't care about this gconf stuff. Remove seems to help."
This is a very useful comment. It pinpoints the actual problem that the maintainer has.
Yeah, what good is this comment then? Unless of course the build team sees itself in a position that it has to be too much time, so it wants to verify the clueness of all packager comments. I doubt it. Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Thu, 15 Mar 2007, Stephan Kulow wrote:
No. Especially cluelessness needs documentation. Example: "# I don't care about this gconf stuff. Remove seems to help."
This is a very useful comment. It pinpoints the actual problem that the maintainer has.
Yeah, what good is this comment then?
It could for instance remind the very same packager, that there once was an issue with gconf, which he might revise later. Sort of a # FIXME: needs proper solution comment. Such a thing is highly usefull. It also documents to other people that the maintainer was in a hurry or didn't care enough at that time to investigate a full solution. These are all good reasons to include a quick hack. But then you have to _write_ that it was a quick hack, so you yourself know that it only was a quick hack, instead of a solution, so that you don't try to find out a year from now what the solutioness was in that hack (i.e. you forgot that it was a hack only).
Unless of course the build team sees itself in a position that it has to be too much time, so it wants to verify the clueness of all packager comments. I doubt it.
I don't see what the build team has to do with that. Are you really making the case for not writing comments? I can't believe that. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Thursday 15 March 2007 schrieb Michael Matz:
I don't see what the build team has to do with that. Are you really making the case for not writing comments? I can't believe that.
There are things on earth harder to believe - say Matz before 9 on a thursday :) I'm not speaking against comments but against having a policy to reject packages without comments. Because rm calls are no special than sed calls or grep -v calls or _anything_ hacky. But as others said: what is hacky lies in the eye of the reader/writer, so I don't want to see that in a policy. "Packagers should have a clue what they're doing or document they have none" is as good as it gets for me :) Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, 15 Mar 2007, Stephan Kulow wrote:
"Packagers should have a clue what they're doing or document they have none" is as good as it gets for me :)
Well - if we need such a policy there's something wrong. Can you spot
the mistake? ;)
Richard.
--
Richard Guenther
Hi, On Thu, 15 Mar 2007, Richard Guenther wrote:
On Thu, 15 Mar 2007, Stephan Kulow wrote:
"Packagers should have a clue what they're doing or document they have none" is as good as it gets for me :)
Well - if we need such a policy there's something wrong. Can you spot the mistake? ;)
That's only because you and coolo shortened the whole discussion to "packagers should have a clue", which is reductio ad absurdum. First: there are multiple level of cluelessness (one of them, which you freely but unfoundedly included in "clueless" is "have no time right now to solve it properly, because the deadline is approaching") second: not everything magic was done because of cluelessness, third: others might want to understand the stuff. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Thu, 15 Mar 2007, Stephan Kulow wrote:
I don't see what the build team has to do with that. Are you really making the case for not writing comments? I can't believe that. There are things on earth harder to believe - say Matz before 9 on a thursday :)
What exactly does that have to do in this thread?
I'm not speaking against comments but against having a policy to reject packages without comments.
That would be a too hard policy, I agree. Especially I wouldn't agree to only reject packages which don't comment 'rm' commands in %install sections, that's rather arbitrary. But I'm sympathetic to a policy where the checkin team would reject a package for needing comments. But the checkin team already can reject packages, so there's no need for such extra policy.
Because rm calls are no special than sed calls or grep -v calls or _anything_ hacky. But as others said: what is hacky lies in the eye of the reader/writer, so I don't want to see that in a policy.
"Packagers should have a clue what they're doing or document they have none" is as good as it gets for me :)
See above. If the checkin team would look over .spec files and sees questionable practices, it should require a comment from the maintainer, even if that maintainer completely knows what he's doing (or thinks so). That is sort of a policy too, but the detailed rules (when and where to require comments) would lie at the shoulders of the checkin team. That uncertainty would push maintainers somewhat to actually write sensible comments more often, which IMO is a good thing. So, instead of policy, we should encourage the checkin team to actively reject package changes with a too high magic-to-comment ratio. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Juergen Weigert píše v Čt 15. 03. 2007 v 15:08 +0100:
On Mar 15, 07 14:53:50 +0100, Richard Guenther wrote:
On Thu, 15 Mar 2007, Stanislav Brabec wrote:
Hallo.
I have just notified, that many people "fix" (i. e. break) their packages to pass QA checks by removing required files instead of fixing them, i. e. removing .desktop files instead of installing icon or fixing Categories, removing gconf schemas instead of correct installation.
If they "fix" or "break" their package what does it help to add a comment? It looks like you are proposing that package maintainers have a clue ;)
No. Especially cluelessness needs documentation. Example: "# I don't care about this gconf stuff. Remove seems to help."
This is a very useful comment. It pinpoints the actual problem that the maintainer has.
Exactly. In most packages, %install is used to install and add files somewhere. Removals here means very non-standard operation, which means "I don't want this file, installed by upstream". It is either bug work-around (removal of obsolete scrollkeeper cache file), tools work-around (obsolete libtool and .a files) or deliberate feature stripping (e. g. removing broken files). If it is not any of them, it's most probably bug. Exactly the same would be very welcome, if one deliberately packages .la or .so files to the main package or so. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Stanislav Brabec wrote: [...]
In most packages, %install is used to install and add files somewhere. Removals here means very non-standard operation, which means "I don't want this file, installed by upstream". It is either bug work-around (removal of obsolete scrollkeeper cache file), tools work-around (obsolete libtool and .a files) or deliberate feature stripping (e. g. removing broken files).
If it is not any of them, it's most probably bug.
So, is it a bug of a package to remove uncompressed manpages, because upstream installs uncompressed as well as compressed manpages into the system? I can give you several more examples in packages, which you call "most probably a bug": e.g. installation of KDE .desktop files, which is done by macro in our distribution, but not from upstream. Sure, we can comment those. But it's just about removing of unneccessary files. Regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: Klaus.Singvogel@SuSE.de 90409 Nuernberg Phone: +49 (0) 911 740530 Germany GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Klaus Singvogel píše v Čt 15. 03. 2007 v 16:49 +0100:
So, is it a bug of a package to remove uncompressed manpages, because upstream installs uncompressed as well as compressed manpages into the system?
No, it is only something non obvious. If anybody else takes the package, one must dig deeper to find reason, why it happens.
I can give you several more examples in packages, which you call "most probably a bug": e.g. installation of KDE .desktop files, which is done by macro in our distribution, but not from upstream.
It is a tool work-around - we do this differently. But I guess we can agree, that all non-obvious removals should be commented, for both readability by other persons and preventing packaging bugs. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, On Mar 15 15:08 Juergen Weigert wrote (shortened):
"# I don't care about this gconf stuff. Remove seems to help."
A perfect example of a meaningful comment! It describes the idea behind - i.e. why it was done - even if it is only because of being clueless. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (10)
-
andreas.hanke＠gmx-topmail.de -
Joe Shaw -
Johannes Meixner -
Juergen Weigert -
Klaus Singvogel -
Marcus Rueckert -
Michael Matz -
Richard Guenther -
Stanislav Brabec -
Stephan Kulow