--- Comment #46 from Alec Leamas <leamas.alec(a)gmail.com> 2014-02-06 16:12:22 CET
(In reply to comment #45)
(In reply to comment #43)
> (In reply to comment #42)
> > (In reply to comment #41)
> > > No, %global will not work, the use here requires lazy evaluation.
> > Wrong, you are using %name before it's defined.
> Yes, that's the current usage and the reason %define is used instead of
> %global. It's a deliberate decision form my side.
Why? IMO, what you are doing is bad coding.
We have important things to discuss.
%define vs %global is IMHO not on that
list. I have updated the spec in place, hopefully ending this discussion. To be
honest, it didn't clutter things as I thought it would.
> > Are the reasons behind the requirement to increment the NVR
each time you
> > change something really so difficult to comprehed?
> Hey, is this personal?
Not yet, but to be honest, you are gradually provoking it.
May be you don't notice that not incrementing the NVR unneccessarily
If it's important for you it's no problem for me to
update the NVR even if it's
not required by the GL. I have no interest to provoke anyone.
> Finally, how do you plan to handle the case of 3rd parties
> > /etc/yum.repos.d/*repo files themselves?
> > Note: Any remote repository, at any time can do so, which at minium will break
> > a user's installation.
> For the case there already is a repo file installed when installing
> dropbox-repo refer to
> (near bottom).
> If one tries to install a package with a repo file after dropbox-repo is
> insrtalled, there will be a conflict. Isn't this as it should?
In Fedora, conflicts are not supposed to happen.
> User can always edit the repo file. After all, it's a configuration file.
A file marked %config will not conflict, but are you sure an upstream added
/etc/yum.repos.d/*repo be marked %config?
As I repeatly said, it's all out of your control, so you must take maximum
precautions for your package to work smoothly. ATM, I don't have any idea how
to achieve this.
As I have said earlier, it's possible to block any repo file changes done
during installation of e. g., dropbox using triggers in dropbox-repo. I don't
feel like this should be necessary in this case, but it could be done. The only
drawback is really added complexity.
If I did this, would that be satisfying?
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.