Bug 506209

Created attachment 348069 [details]
deprecate -t and others

I really think you are 'solving a problem' that does not exist here.  The -t series has been stable, substantially unchanged except for a semantic change forced in by tar and quickly addressed, and reliable for a decade.

The thrust of your mailing list post was as I read it at the time, was to permit short-circuiting -- usually a bad idea, and prone to generating hard (if not impossible to reproduce) errors, if adopted.  The purported savings are not discussed with hard metrics, and rankly, will not be usable once a problem appears, as debugging from a known state is needful.  As it was (and is) a bad idea, it did not draw comment from rpm list 'regulars'.

I suggest that the patch is starting down a poorly considered path, and should be rejected

(In reply to comment #2)
> I really think you are 'solving a problem' that does not exist here.  The -t
> series has been stable, substantially unchanged except for a semantic change
> forced in by tar and quickly addressed, and reliable for a decade.

So then use -t.  We can remove the message about it being deprecated.
 
> The thrust of your mailing list post was as I read it at the time, was to
> permit short-circuiting -- usually a bad idea, and prone to generating hard (if
> not impossible to reproduce) errors, if adopted.  

The thrust of my post is to enable you to build *.src.rpm like a spec file without requiring rpm -i (which you can already do for two options, -bc and -ba). The side effect is you can now use --short-circuit on *.src.rpm.  This has little to do with the patch, since the option predates me.

> The purported savings are not
> discussed with hard metrics, 

My most common use case:

Case 1 (today):

1) yumdonwloader --source kernel 
2) rpm -i kernel*.src.rpm 
3) cd ~/rpmbuild/SPECS/ 
4) ls kernel*
5) rpmbuild -bp kernel-2.6.spec
6) cd ../BUILD/kernel-2.6.18

Case 2 (patch):

1) yumdownloader --source kernel
2) rpmbuild -bp kernel*.src.rpm
3) cd ~/rpmbuild/BUILD/kernel-2.6.18

I can come up with additional hard metrics if desired.

> and rankly, will not be usable once a problem
> appears, as debugging from a known state is needful.

This could be used to justify not developing any new feature ever.

> As it was (and is) a bad
> idea, it did not draw comment from rpm list 'regulars'.

It's a good idea because:

1) save user time (outlined above)
2) prune code paths and clean the design, thus saving development and 
   maintance time.

Lots of ideas have a set of good merits, and a set of consequences and this idea is no different.  This concept is not new either.  For years a very small number of people have suggested similar things as an "enhancement" of rpm, while looking at the whole problem solely from how it effects them solely.  They do not look at the much bigger picture, and the real world problems such features can cause such as what Russ is suggesting above.

Usually the conversation goes along these lines:

1) Person is frustrated and wishes they could have failed rpm builds continue from where they left off.

2) They offer up suggestions or even patches to allow this to happen, either with lack of understanding of the reasons why it works the way it does now, or with complete disregard for those reasons.

3) Their idea/patch is rejected and they're told why the current behaviour is the way it is now, and that it is intended to work this way.  They're generally also told the problems that would be created if their suggestion were accepted, and that those problems are hard to diagnose and lead to unpredictable builds.

4) The person is upset their idea is rejected and argues back that it is a desired feature and should be implemented, completely ignoring all of the facts and rationale they've been given about why it is not implemented that way, and the reasons why it wont be accepted.

5) A back and forth flamewar/debate erupts on the mailing list, web forum, bug threat where this discussion is occuring, where the reporter refuses to understand or even listen to the reasons why things work the way they do now, and in many cases demands that the behaviour be changed.

6) Goto step 4 and repeat 2-1000 times until people get bored and move on.


Would this idea save someone time?  Maybe.  Is it a good idea?  No.  Why?  Because it would cause _other_ people to _lose_ lots of time trying to troubleshoot obscure hard to diagnose bugs and inconsistencies that arise from using the "feature".  On top of that, the "feature" can be used for malicious purposes as well.  Not that someone couldn't create rpms with malicious intent already anyway, but there is no reason to provide features that would make it easier to do so either.

Read through the archives of rpm-list to find out why these type of features are bad ideas and should (and most likely will) be rejected.

Tip: When attaching diff/patch files to bug reports, set the mimetype properly so they can be viewed in a web browser when someone clicks on them.  It's currently set to application/octet-stream which means if you click on it the web browser will want to download it instead.  Very inconvenient.

(In reply to comment #5)
> Tip: When attaching diff/patch files to bug reports, set the mimetype properly
> so they can be viewed in a web browser when someone clicks on them.  It's
> currently set to application/octet-stream which means if you click on it the
> web browser will want to download it instead.  Very inconvenient.  

done

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.