Re: policy on changes in or introduction of new dependencies
On Fri, Feb 24, 2017 at 04:24:16PM +0100, Dominik 'Rathann' Mierzejewski 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(a)greysector.net> 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?
I question how useful that is going to be in practice. Realistically the
RPM changelog is going to say little more than
"Added new dependancy libfoo.so"
which isn't really adding any value IMHO. Explaining why a dependancy was
added is useful, but that needs packagers to potentally understand the
upstream app decision in significant detail, and such an explanation is
often not simple enough to explain in a useful level of detail in an
RPM changelog. Unless you want long paragraphs of text in the RPM changelog
which IMHO would not be appropriate.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|