Re: policy on changes in or introduction of new dependencies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 24 February 2017 at 10:24, Dominik 'Rathann' Mierzejewski
<dominik@xxxxxxxxxxxxxx> wrote:
> On Friday, 24 February 2017 at 15:31, Daniel P. Berrange wrote:
>> On Fri, Feb 24, 2017 at 08:48:43AM -0500, Stephen John Smoogen wrote:
>> > On 23 February 2017 at 12:24, Dominik 'Rathann' Mierzejewski
>> > <dominik@xxxxxxxxxxxxxx> wrote:
>> > > On Thursday, 23 February 2017 at 14:23, Neal Gompa wrote:
>> >
>> > > I have nothing against delivering latest and greatest software to our
>> > > users and this proposal is not against that goal, either. However,
>> > > package maintainers are not supposed to simply take what upstream
>> > > releases and pass it on to the users without considering the impact.
>> >
>> > I think that may be the differing of opinions in this discussion as I
>> > don't think there is a definitive answer. Some packagers believe that
>> > whatever upstream requires to get the software is what happens, other
>> > packagers believe that it isn't. Many packagers just want the XYZ
>> > package to be there so they can build the thing they really care about
>> > so if the upstream needed ten new dependencies.. we add 10 new
>> > dependencies.
>
> And that's fine. Just don't make me jump through hoops to find out why.
> One sentence in the changelog or a pointer to upstream release notes is
> all I'm asking for. That and a little bit of consideration if such an
> update is really necessary in a stable release. Surely that's not much
> to ask. Or is it?
>
>> Upstream may not allow packagers to have any viable choices. If upstream
>> has added a new dependancy, there's no guarantee it is optional. So if the
>> new version is required in Fedora, then often there's no choice but to
>> accept the new dependancy. The alternative is to be stuck on the old
>> (possibly insecure) version forever, or fork the code, neither of which
>> are really acceptable options. Even if the dependancy is optional, disabling
>> it may cause Fedora to loose functionality vs the previously packaged
>> version, so it is in effect mandatory.
>>
>> Any rules about adding new dependencies in Fedora will quickly come up
>> against these hard realities, when dealing with new upstream versions.
>
> You both sound as if you're thinking I'm totally against introducing new
> dependencies.

No. I didn't take that to be your view at all. I am going more with
the fact that you ran into a wall, and then you decided to smash your
head into the wall 3 times without asking "why is there this wall?
what am I missing"

>
> I'm not. I'd just like to be informed when they appear. I'm convinced
> this information would be useful not only to me, but also to others.
> Hence my proposal to include justification (a pointer to upstream release
> notes is fine as one) for them.

Mostly to me it is that what you are going to see is:

===
No f'ing clue why, but upstream wants /bin/foo now.
===

Because that fits the spirit of the law at 2am when someone is fixing
some package. At which point you start adding in, packager needs to
give a reasoned explanation of why upstream wants it and we need
someone to audit that those changes are put in place (because they
won't be) and what the consequences of them not being there is to be.


> Regards,
> Dominik
> --
> Fedora http://fedoraproject.org/wiki/User:Rathann
> RPMFusion http://rpmfusion.org
> "Faith manages."
>         -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx



-- 
Stephen J Smoogen.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux