Re: redhat-lsb-desktop versus transition to current libpng
Tom Callaway writes: > On 08/01/2012 10:03 AM, Tom Lane wrote: >> What this means, IMO, is that we need to split out libpng12 as a >> separate package. The current hack that I'm using (bundling 1.2 and 1.5 >> into a single SRPM) was never meant to be more than a very short-term >> stopgap; I'm sure it violates all sorts of packaging guidelines. > Rather than working around the review process, just go ahead and make > the package, upload it somewhere, open a review ticket, and I'll review > it after lunch today. I'm familiar with that package, so it should be a > very quick review for me to complete, and the branching request should > be able to be processed today. Thanks for offering! Review request is in bug #845110 regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-lsb-desktop versus transition to current libpng
On 08/01/2012 04:48 PM, Nicola Soranzo wrote: bcfg2-server I dont think it's necessary for it to depend on redhat-lsb-desktop anymore since that package has move to using unit files instead.. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-lsb-desktop versus transition to current libpng
On 08/01/2012 10:21 AM, Richard Hughes wrote: On 1 August 2012 10:47, Rahul Sundaram wrote: >Fedora is not LSB compatible. Is it? Why do we even care about this at >all? I think I can speak for most of the core GNOME desktop developers and state that we don't care about LSB one little bit. Is not lsb as outdated as the rest of those so called standards? Btw should not this package be called fedora-lsb-desktop or system-lsb-desktop... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-lsb-desktop versus transition to current libpng
Il giorno mer, 01/08/2012 alle 09.51 -0400, Adam Jackson ha scritto: > > Fedora is not LSB compatible. Is it? Why do we even care about this at > > all? > > It is if you install redhat-lsb. > > The only intrinsic reason to care about LSB support is binary > compatibility; Fedora broadly doesn't, but that doesn't mean it's not a > useful end. Personally I've definitely had occasion to need older > builds of things like boost and openssl on newer Fedora releases. > > repoquery is also telling me there are things in Fedora that _do_ > require redhat-lsb, at least in F16. I can't speak to the particulars > there, you'd need to look into that per-package. In rawhide, the packages requiring redhat-lsb are: bcfg2-server rear tomcat6 HTH, Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-lsb-desktop versus transition to current libpng
On 08/01/2012 09:45 PM, Bill Nottingham wrote: > > I can see assorted ways we could theoretically handle a desire to remove > libpng 1.2 from the distribution, but merely dropping the req from > redhat-lsb is the obviously wrong answer. Right. I was obviously not suggesting it but perhaps dropping the LSB package itself would be a appropriate move Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-lsb-desktop versus transition to current libpng
Rahul Sundaram (methe...@gmail.com) said: > On 08/01/2012 01:06 PM, Adam Williamson wrote: > > > Well, that's really it. The format of LSB is a bit odd to a lay reader, > > but AFAICT, it really does mean: to be technically in compliance with > > LSB-desktop, you need to ship a libpng12.so.0 which provides the listed > > functions. End of story. I don't see a workaround. > > Fedora is not LSB compatible. Is it? Why do we even care about this at > all? If we are providing a redhat-lsb package that provides the requirements specified in the LSB, it should be correct. I can see assorted ways we could theoretically handle a desire to remove libpng 1.2 from the distribution, but merely dropping the req from redhat-lsb is the obviously wrong answer. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-lsb-desktop versus transition to current libpng
On 08/01/2012 10:03 AM, Tom Lane wrote: > What this means, IMO, is that we need to split out libpng12 as a > separate package. The current hack that I'm using (bundling 1.2 and 1.5 > into a single SRPM) was never meant to be more than a very short-term > stopgap; I'm sure it violates all sorts of packaging guidelines. > > Is there any way we can fast-track that? I see little value in going > through the normal package review pushups, when this is absolutely > nothing except a backwards-compatibility package --- it ought to be > exactly like the F16 libpng package. And I'd like to get it done > before the F18 branch. Rather than working around the review process, just go ahead and make the package, upload it somewhere, open a review ticket, and I'll review it after lunch today. I'm familiar with that package, so it should be a very quick review for me to complete, and the branching request should be able to be processed today. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-lsb-desktop versus transition to current libpng
Adam Williamson writes: > On Wed, 2012-08-01 at 00:21 -0700, Adam Williamson wrote: >> A very quick search returns this: >> http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Desktop-generic/LSB-Desktop-generic/libpng.html Thanks. The links I was given previously didn't lead me to that. > Well, that's really it. The format of LSB is a bit odd to a lay reader, > but AFAICT, it really does mean: to be technically in compliance with > LSB-desktop, you need to ship a libpng12.so.0 which provides the listed > functions. End of story. I don't see a workaround. Yeah, looks like it. (I think redhat-lsb.spec is pretty broken in that it onlu appears to be trying to force a particular soname version for libpng, when the spec clearly demands a particular version for each of these libraries. But that's not very relevant right now.) What this means, IMO, is that we need to split out libpng12 as a separate package. The current hack that I'm using (bundling 1.2 and 1.5 into a single SRPM) was never meant to be more than a very short-term stopgap; I'm sure it violates all sorts of packaging guidelines. Is there any way we can fast-track that? I see little value in going through the normal package review pushups, when this is absolutely nothing except a backwards-compatibility package --- it ought to be exactly like the F16 libpng package. And I'd like to get it done before the F18 branch. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-lsb-desktop versus transition to current libpng
On 8/1/12 5:47 AM, Rahul Sundaram wrote: On 08/01/2012 01:06 PM, Adam Williamson wrote: Well, that's really it. The format of LSB is a bit odd to a lay reader, but AFAICT, it really does mean: to be technically in compliance with LSB-desktop, you need to ship a libpng12.so.0 which provides the listed functions. End of story. I don't see a workaround. Fedora is not LSB compatible. Is it? Why do we even care about this at all? It is if you install redhat-lsb. The only intrinsic reason to care about LSB support is binary compatibility; Fedora broadly doesn't, but that doesn't mean it's not a useful end. Personally I've definitely had occasion to need older builds of things like boost and openssl on newer Fedora releases. repoquery is also telling me there are things in Fedora that _do_ require redhat-lsb, at least in F16. I can't speak to the particulars there, you'd need to look into that per-package. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-lsb-desktop versus transition to current libpng
On 1 August 2012 10:47, Rahul Sundaram wrote: > Fedora is not LSB compatible. Is it? Why do we even care about this at > all? I think I can speak for most of the core GNOME desktop developers and state that we don't care about LSB one little bit. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-lsb-desktop versus transition to current libpng
On 08/01/2012 01:06 PM, Adam Williamson wrote: > Well, that's really it. The format of LSB is a bit odd to a lay reader, > but AFAICT, it really does mean: to be technically in compliance with > LSB-desktop, you need to ship a libpng12.so.0 which provides the listed > functions. End of story. I don't see a workaround. Fedora is not LSB compatible. Is it? Why do we even care about this at all? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-lsb-desktop versus transition to current libpng
On Wed, 2012-08-01 at 00:21 -0700, Adam Williamson wrote:
> On Wed, 2012-08-01 at 02:17 -0400, Tom Lane wrote:
> > I have been working for the better part of a year on moving Fedora off
> > of libpng's obsolete 1.2.x release series and onto the current 1.5.x
> > series. We are practically there now, and I had hoped to drop libpng
> > 1.2 from the distribution before the F18 branch. However, I find that
> > redhat-lsb-desktop still has a dependency on 1.2, and it's not even
> > because that package contains any PNG-using code; rather, there's a
> > manually inserted version-specific dependency in the specfile:
> >
> > %ifarch %{ix86}
> > Requires: libpng12.so.0
> > %endif
> > %ifarch x86_64
> > Requires: libpng12.so.0()(64bit)
> > %endif
> >
> > This is unlike that specfile's treatment of any other library
> > it requires. I have been told, at
> > https://bugzilla.redhat.com/show_bug.cgi?id=835777#c8
> > that the LSB standard requires libpng 1.2, but without any supporting
> > evidence. I looked at the underlying ISO documents and don't see any
> > requirement for libpng at all, let alone 1.2 in particular. I am
> > doubtful that every other Linux distro is maintaining this long-obsolete
> > libpng version, too.
> >
> > I would like to know how to proceed here. "You should keep libpng 1.2
> > around indefinitely, on the basis of no evidence" is not an answer
> > I intend to accept.
>
> A very quick search returns this:
>
> http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Desktop-generic/LSB-Desktop-generic/libpng.html
>
> in the 'desktop' section of LSB 4.1. I'm looking at it more closely now.
Well, that's really it. The format of LSB is a bit odd to a lay reader,
but AFAICT, it really does mean: to be technically in compliance with
LSB-desktop, you need to ship a libpng12.so.0 which provides the listed
functions. End of story. I don't see a workaround.
See
http://lists.linuxfoundation.org/pipermail/lsb-infrastructure/2012-June/004006.html
for e.g., for confirmation that it does mean what it seems to mean - that
seems like a 'real world' (and relatively recent) case where someone says, yup,
you need to ship a library called libpng12.so.0 with the right symbols in it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-lsb-desktop versus transition to current libpng
On Wed, 2012-08-01 at 02:17 -0400, Tom Lane wrote:
> I have been working for the better part of a year on moving Fedora off
> of libpng's obsolete 1.2.x release series and onto the current 1.5.x
> series. We are practically there now, and I had hoped to drop libpng
> 1.2 from the distribution before the F18 branch. However, I find that
> redhat-lsb-desktop still has a dependency on 1.2, and it's not even
> because that package contains any PNG-using code; rather, there's a
> manually inserted version-specific dependency in the specfile:
>
> %ifarch %{ix86}
> Requires: libpng12.so.0
> %endif
> %ifarch x86_64
> Requires: libpng12.so.0()(64bit)
> %endif
>
> This is unlike that specfile's treatment of any other library
> it requires. I have been told, at
> https://bugzilla.redhat.com/show_bug.cgi?id=835777#c8
> that the LSB standard requires libpng 1.2, but without any supporting
> evidence. I looked at the underlying ISO documents and don't see any
> requirement for libpng at all, let alone 1.2 in particular. I am
> doubtful that every other Linux distro is maintaining this long-obsolete
> libpng version, too.
>
> I would like to know how to proceed here. "You should keep libpng 1.2
> around indefinitely, on the basis of no evidence" is not an answer
> I intend to accept.
A very quick search returns this:
http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Desktop-generic/LSB-Desktop-generic/libpng.html
in the 'desktop' section of LSB 4.1. I'm looking at it more closely now.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
redhat-lsb-desktop versus transition to current libpng
I have been working for the better part of a year on moving Fedora off
of libpng's obsolete 1.2.x release series and onto the current 1.5.x
series. We are practically there now, and I had hoped to drop libpng
1.2 from the distribution before the F18 branch. However, I find that
redhat-lsb-desktop still has a dependency on 1.2, and it's not even
because that package contains any PNG-using code; rather, there's a
manually inserted version-specific dependency in the specfile:
%ifarch %{ix86}
Requires: libpng12.so.0
%endif
%ifarch x86_64
Requires: libpng12.so.0()(64bit)
%endif
This is unlike that specfile's treatment of any other library
it requires. I have been told, at
https://bugzilla.redhat.com/show_bug.cgi?id=835777#c8
that the LSB standard requires libpng 1.2, but without any supporting
evidence. I looked at the underlying ISO documents and don't see any
requirement for libpng at all, let alone 1.2 in particular. I am
doubtful that every other Linux distro is maintaining this long-obsolete
libpng version, too.
I would like to know how to proceed here. "You should keep libpng 1.2
around indefinitely, on the basis of no evidence" is not an answer
I intend to accept.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
