Bug#650601: libpng1.6 transistin (Was: Processed: fvwm: diff for NMU version 1:2.6.5.ds-4.1)
Am Dienstag, den 26.01.2016, 18:07 +0100 schrieb Emilio Pozuelo
Monfort:
> On 26/01/16 17:54, Gianfranco Costamagna wrote:
> > Hi Emilio!
> >
> >
> > > Can send another summary with your proposed plan here? Currently
> > > libpng12-dev
> > > provides libpng-dev but libpng16-dev doesn't. Are you going to
> > > switch that? Or
> > > do you plan to build a libpng-dev package from src:libpng1.6?
> >
> >
> > sure, the only reason that libpng-dev wasn't provided has been to
> > avoid people building accidentally
> > with libpng16 when uploading on experimental.
> >
> > IIRC the plan is to upload on unstable with the Provides: libpng-
> > dev line enabled
> > (it is already there, just commented),
> > and the change for the udeb file conflict (ongoing test right now).
> >
> > I think libpng12-dev will stop providing the libpng-dev at the same
> > time, but I'm not sure
>
> Either that needs to happen, or a real libpng-dev package needs to be
> built.
> Otherwise if we have libpng12-dev and libpng16-dev providing libpng-
> dev, things
> won't be deterministic.
> >
(My*) plan'd be to upload (1) libpng12 WITHOUT providing libpng-dev and
(2) libpng16 WITH providing it.
I'm not sure whats better: if that should happen at the very same time,
or if we should delay (2) until e.g the -12 package arrived at all
archs, to ensure that there will be no point of time where libpng-dev
is provided by two packages or solve any races by delaying the start of
the binnmus until we can ensure that all archs are getting the right
one.
A real libpng-dev package would be actually my* favorite, but this
requires going through NEW and I fear that that would destroy the
momentum we experience now to push this forward. Also, a real libpng-
dev Package could still be introduced later.
--
tobi
* Nobuhiro / Anibal should give the definitive direction how the want
to manage their package...
Reply to: